GNOME Bugzilla – Bug 772654
"window-state-event" signal does not fire when the "above" state is changed from the Window Manager
Last modified: 2018-05-02 17:35:32 UTC
Hi, I'm writing a program that uses GTK+ on Ubuntu 16.04 x64, with Unity as the desktop manager running on top of X11. I want to track the GDK_WINDOW_STATE_ABOVE window state, therefore my main window is subscribed to the "window-state-event" signal. The signal callback is correctly called when I change most of the window states with the window manager, for example: iconify, maximize... however the callback is not called when I change the "above" state with the "always on top" option of the window. I wrote a test program in pure X11 where I display the window state when the PropertyNotify event is received. The test program shows that everything works fine regarding the "above" state: I correctly receive the PropertyNotify event, and the "_NET_WM_STATE_ABOVE" property is present or missing as expected according to the "always on top" menu item check box state of the window. Maybe some kind of binding is missing with X11?
Created attachment 337288 [details] [review] gdk x11: add missing "above" window state change notification When a program wants to track the "above" state of its top window, it can connect to the "window-state-event" signal. The problem is that the signal is not fired when the "above" state is changed from the Window Manager, for example by selecting a menu item called "always on top" in the title bar. To fix this, add a presence check of "_NET_WM_STATE_ABOVE" atom in order to trigger a "window-state-event" signal when that state changes, and also to ensure gdk_window_get_state() returns the right information regarding that state.
Review of attachment 337288 [details] [review]: This seems incomplete. You will need to update gtkwindow.c:gtk_window_state_event to deal with 'above'. Also, why only 'above', and not other fringe states, such as 'below' ?
(In reply to Matthias Clasen from comment #2) > Review of attachment 337288 [details] [review] [review]: > This seems incomplete. You will need to update > gtkwindow.c:gtk_window_state_event to deal with 'above'. Hi Matthias, thank you for looking at my patch. I wrote a test program to display information when the "window-state-event" signal is fired. After applying the patch, I observed that the behavior of the signal finally complies with the documentation: the signal is correctly sent when the "above" state changes as I change the "Always on top" option from my window manager. You can find the test program there: http://mess.psydk.org/window-state-event-test.zip Would you please explain to me what kind of problem you have in mind that could happen with the "window-state-event" after applying the patch, please? This way I could add a test case in my test program and attempt to complete the patch. > Also, why only 'above', and not other fringe states, such as 'below' ? The bug I encountered while writing my application is related to "Always on top". I am not familiar with other fringe states. Do you think there are bugs with other fringe states? When this "Always on top" event bug is fixed, maybe I could learn a bit more about such states, like the "below" you are talking about. Hopefully I will find a way to test that, as my current window manager only propose the "Always on top" option (maybe there are window managers that propose more options?). If I ever find a way to test those fringe states and find new bugs, I will open new bug reports. Best Regards,
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Tested on Ubuntu 17.10 with GTK+ 3.22, with a Wayland session and a X11 session. The bug is still present. I cannot change the status of this ticket to REOPENED.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/682.