Package: zoitechat Version: 2.19.1-1 Followup-For: Bug #1150267 X-Debbugs-Cc: [email protected]
One final technical observation from my testing, in case it is useful for the upstream investigation. I captured the Wayland protocol traffic with `WAYLAND_DEBUG=1` while reproducing the tray hide/restore behaviour. The trace shows repeated `xdg_toplevel.configure` negotiations, together with repeated changes to the client's `xdg_toplevel.set_min_size()` hints while the main window is being created/restored and while the connected channels and UI are changing. The resulting geometry is not simply a maximized window: in the affected cases the restored window can become close to the available screen size while still behaving as a normal, non-maximized window. Its resulting geometry is also not consistent between restores. This seems relevant because ZoiteChat's `mg_configure_cb()` handles the main-window geometry from GTK configure events. When geometry saving is enabled and the window is neither maximized nor fullscreen, it obtains the current position and size using `gtk_window_get_position()` and `gtk_window_get_size()` and stores them in `hex_gui_win_left/top/width/height`. GTK documents that `gtk_window_get_size()` returns the current negotiated window size and that, depending on the windowing system and window-manager constraints, it may differ from a size previously requested by the application. GTK also recommends obtaining the size in response to a size-change notification such as `configure-event` to avoid potential race conditions. I therefore think the interaction between ZoiteChat's geometry save/restore logic, GTK window sizing, and the Wayland configure sequence is worth investigating in the tray hide/restore path. I am not claiming this identifies the root cause; this is simply the part of the application/window-system interaction that appears most relevant from the captured behaviour. Thanks!
