Wayland: Window::hide doesn't hide the window #4225
Comments
|
There are now a few branches using different styles to try and achieve this:
If I try to narrow things down I think I get this:
If I could solve for 3, then I think everything I need follows on - for example creating multiple windows from different threads. I see there are several similar issues, but none address the threaded case. |
|
I've tried your example and I think that this is a winit/wayland bug. I'm running this against Gnome with Wayland, and out of the box the show/hide menu items in the tray menu don't do anything. If I unset Do you observe the same? |
|
I'm not actually able to get this running with xwayland: |
ogoffart
added
bug
ogoffart
changed the title
ogoffart
changed the title
|
For what it's worth, this seems to also be a bug in winit, so likely the issue isn't slint at all. (I also had the same issue in egui). I'm now using the same style of "app thread run, window app close" as the LSP and with the latest git pull it seems to work pretty well for my purposes... (this branch of example) It should be noted that the issue seems to be quite specific, after trying a few things using winit multi-window. That is, if there is one last window and the main thread for it is still running it will not close, but all other windows will do so fine. Looks related to a drop change in winit actually. |
|
Appears not to be an issue with winit v0.29.10 (from git) multiwindow now. Update: Looks like the only real way to do what I want is to actually drop the windows. Same as is done in winit example tbh, that drops the windows also, even the last one. If I have some time, maybe I can submit a slint example of this. Clarification: actual |
|
Ahh, that explains it! I was trying your example last week and I saw the same effect, that hide() didn't just do anything at all. Explains it, when it's not working under Wayland. Looks like at the least we need to document this :( |
|
Found rust-windowing/winit#2388 (the reporter looks familiar :-) ) This means we'll have to keep the winit Window in a RefCell and destroy it and re-create it all the time the user wants it to have it hidden. |
|
Agreed |
Ha.. I don't know who that is.
Will this not result in unexpected side-effects? I've not used |
This will be about destroying the winit::Window, not not the Slint component. |
Yes, that's a problem. We'd have to save/restore that manually. My feeling is that if we work around this, we should limit the workaround to wayland. The downside though is that that means the code path will receive a lot less testing, as hiding a window is probably not that common. |
I can assure you that this is a critical feature for asusctl/rog-control-center so it will receive continuous testing. |
|
Ah, I wish I hadn't spent hours trying to figure out what I was doing wrong, haha 😅 I'll try using drop like fluke mentioned... Also, hey @flukejones , nice to see you in yet another place! |
|
@ryanabx my rog-control-center demonstrate it well. |
On Wayland hiding a window requires destroying the surface, which means destroying the winit window as well as the underlying graphics surface. The latter is tricky as we have to keep the renderer around, as our WindowAdapter trait's `renderer()` function returns a `&dyn Renderer` and that also has to work without a window (to obtain text metrics). Fixes #4225
On Wayland hiding a window requires destroying the surface, which means destroying the winit window as well as the underlying graphics surface. The latter is tricky as we have to keep the renderer around, as our WindowAdapter trait's `renderer()` function returns a `&dyn Renderer` and that also has to work without a window (to obtain text metrics). Fixes #4225
On Wayland hiding a window requires destroying the surface, which means destroying the winit window as well as the underlying graphics surface. The latter is tricky as we have to keep the renderer around, as our WindowAdapter trait's `renderer()` function returns a `&dyn Renderer` and that also has to work without a window (to obtain text metrics). Fixes #4225
On Wayland hiding a window requires destroying the surface, which means destroying the winit window as well as the underlying graphics surface. The latter is tricky as we have to keep the renderer around, as our WindowAdapter trait's `renderer()` function returns a `&dyn Renderer` and that also has to work without a window (to obtain text metrics). Fixes #4225
On Wayland hiding a window requires destroying the surface, which means destroying the winit window as well as the underlying graphics surface. The latter is tricky as we have to keep the renderer around, as our WindowAdapter trait's `renderer()` function returns a `&dyn Renderer` and that also has to work without a window (to obtain text metrics). Fixes #4225 Co-Authored-By: Olivier Goffart <[email protected]>
On Wayland hiding a window requires destroying the surface, which means destroying the winit window as well as the underlying graphics surface. The latter is tricky as we have to keep the renderer around, as our WindowAdapter trait's `renderer()` function returns a `&dyn Renderer` and that also has to work without a window (to obtain text metrics). Fixes #4225 Co-Authored-By: Olivier Goffart <[email protected]>
On Linux, using Wayland (Gnome). Issue seems universal across desktops. I have not tried xorg as I don't have any requirement for it for the last few years.
To illustrate the issue I created a minimal example here which is a heavily cut down version of what I have working using egui. Of note however is that if I update egui at all I then have the same issue where if I try to keep the app running as a background process but close the main window, the window is just frozen.
The issue may be in winit but I think maybe we can confirm first?
(click on the tray icon to open app window then try close the window).
The text was updated successfully, but these errors were encountered: