I'm encountering the same issue.

I've rebased #3323 onto v0.6.1, so you can use it with all the latest updates.

I am seeing the same issue on linux with desktop feature and dx 0.6.1. I am using rustc 1.83.0.

@jeancf, have you tried the fix?

I am happy to try the fix but I don't know how to do it.

Thanks. I would not have figured it on my own.

The fix indeed closes and restarts the app after a rebuild. The annoying bit is that when it restarts, the app steals the focus from the editor that needs to be clicked to continue typing. This can quickly become irritiating.

Also, after manually closing the app window, pressing o does not reopen it, but I am not sure this fix was meant to address that as well.

Can confirm this bug also on NixOS 24.11. Can also confirm that @Andrew15-5's patch fixes the issue. I can also confirm that the app does steal focus when reloaded on my system too, unfortunately. It seems intrinsic problem to re-opening the window.

Here are my thoughts on potential solutions in ascending order of jank:

1. Somehow modifying the existing re-loading functionality to use the same window. I'm not sure if that's feasible, but it seems like it probably can be done given that it's rendering to a dedicated webkitgtk process (if I understand rightly).
   • So maybe if the backend process can be killed, and relaunched without interrupting the webkitgtk process, then IPC can be re-established with the new backend?
2. Change window metadata when it launches to have it not take focus / force it to move to a more appropriate location on screen.
3. Recommending configs for the Desktop Environment layer (e.g., KDE Window Rules (if the system in question uses KDE).

In the meantime, merging this is certainly much better than nothing. The workflow is barely usable otherwise -- and truthfully, the problem of the window of the app you're prototyping stealing focus between iterations is a common one across many toolkits and ecosystems.

I guess what I'm saying is, if 1. would take e.g. several months to ship, it's probably best to at least merge this for now so that Linux users can develop with dx without too much trouble. :P

The app focus issue is honestly the norm, because that's how the windowing system works: you open a new window, it becomes focused. I maybe thought of this once or twice before.

I investigated this for Linux, and there is no way to prevent the focus, unless the app itself can somehow do this:

id=$(xprop -root _NET_ACTIVE_WINDOW | awk '{print $5}') && ./app & disown && pid=$!; while ! wmctrl -lp | grep "$pid"; do :; done && wmctrl -iR "$id"

And AFAIK there is no better way than just wrapping these commands in Command.

Since https://github.com/jkelleyrtp/ipbp exists, I'm petty sure there is no way to just re-load stuff in-place, since the desktop is literally a single binary.

force it to move to a more appropriate location on screen.

By default, Dioxus already maintains the same window position on rebuilds, but there is some issue with it: #2318.

Also, after manually closing the app window, pressing o does not reopen it, but I am not sure this fix was meant to address that as well.

This is because currently it tries to find the app from the hashmap and then open it. But, IIUC, the app is being automatically removed from the hashmap because it's being closed and therefore being dropped in dx. So this is most likely just an oversight.

I don't know how to properly fix it, because I don't see an immediate way to get the AppHandle etc., so instead I just run the re-build action, which in turn opens the built app. Since the rebuilt is a no-op in this case, it takes a tiny bit of additional time to open the app. Here is the fix for this on top of the current fix: https://github.com/Andrew15-5/dioxus/tree/fix-open-button.

@Andrew15-5 The shell script solution you suggest isn't really one I'd champion, as it doesn't work on Wayland. Wayland protocols for more sophisticated automation are still being developed, and X11 is being dropped by the ecosystem -- so while it might be a temporary fix to have some hook for a script the user can put in, hardcoding in an X11-specific solution seems like a no-go IMO.

This seems out-of-scope for this issue, tho.

Right, I forgot to mention that I only found the solution for the X11, and any tool that can help with that isn't even mandatory, so I'm pretty sure the dev must install them separately. You probably can check the windowing system and run the correct command.

If this can be done for other OSes, then I think this is worth adding. Since there are a lot of unevenness between different OSes as is, I don't think adding this just for X11-based OSes would be that bad. Because better DX even for some group of people (not super small) is better than bad DX for everyone.

I also remember this being annoying, so I would probably use this. And since I already have the patch, I can slap it on top of any version and use it, even if just for myself.

Just fixed this in #3608

The new system adds a bit of entropy to each .exe name in development that allows us to write multiple variants of the exe in the same build dir while the app is running.

How many generated binaries can be present in the directory at the same time? For the same program. If only 2 then it's fine, but if more, then this is unnecessary bloating as the bare-bones debug binary is over 150 MiB (and 2 of them is already over 300 MiB).

Only two binaries - we write the new one with the entropy and then clean up the old one

Nice!