GNOME Bugzilla – Bug 311653
Panel forgets the sticky flag
Last modified: 2005-08-02 17:02:46 UTC
Distribution/Version: FC rawhide 1. Create a drawer of launchers on your panel 2. Add something in it 3. Click the drawer to open, and then close it. Notice how the panel in question has disappeared from all workspaces EXCEPT the one you're currently in. Tested in Devil's Pie.
Confirmed: gnome-panel-2.11.5-0.1gpw, metacity-2.11.1-0.1gpw, libgtk+2.0_0-2.7.3-0.1gpw The devilspie was to add the stick flag back. That partly works; panel is again visible, but other windows maximize under the panel. Seeing gnome-panel this is not a gnome-panel bug.. hrm.
Seeing gnome-panel _ChangeLog_ this is not a gnome-panel bug Reporter uses 2.11.4 btw.
Let me guess...the code uses gtk_window_present, somewhere, right? /me is pretty sure it's the stupid _net_active_window crap again (though, thankfully, we've almost got things back to being sane)
s/,//1
Created attachment 49804 [details] [review] Fixes the bug, likely introduces others This gtk_window_present caused it. Only attaching the patch to easily show which gtk_window_present it was. Gnome-panel still has gtk_window_present all over the place.
Matthias: So, the net_active_window workaround in gtk+ of moving the window to the current desktop with gtk_window_present() was incomplete as it doesn't take into account sticky windows. Is it okay to just go ahead and nuke gdk_x11_window_move_to_current_desktop()? (For reference, I've reverted the _NET_ACTIVE_WINDOW changes in metacity and released a new 2.10 and 2.11 tarball...)
Elijah, can you just remove the gdk_x11_window_move_to_current_desktop() call for now, leaving the gdk_x11 function in place ? Out of curiosity, why has move_to_current_desktop() the side effect of removing sticky ? That sounds like a bug.
Sure, I'll remove the call to it in gtk_window_present_with_time(). If a window's desktop is set to 0xffffffff then it's considered sticky (in the workspace sense, not the viewport one) and the WM keeps it on all workspaces. gdk_x11_window_move_to_current_desktop() doesn't check what the window's workspace was (0xffffffff if it's sticky) and changes it to the current workspace (some nonnegative number) resulting in it no longer being sticky. (Note that the EWMH stuff about _NET_WM_STATE_STICKY is for viewport-stickiness, not workspace-stickiness) I don't know whether to consider this a bug or not--why would moving a window to a given workspace make any sense if the window was sticky before and remained sticky after? Anyway: 2005-07-26 Elijah Newren <newren@gmail.com> Revert part of patch from #166379; don't have gtk_window_present() change a window's desktop, but rather leave it up to the WM. (#311653) * gtk/gtkwindow.c (gtk_window_present_with_time): Don't change a window's workspace
Yes, I forgot about that sticky vs on-all-desktops thing. We should probably document that gdk_x11_window_move_to_current_desktop makes a window non-sticky.
Or alternatively, if you think thats more natural, you could make it a no-op if the window is sticky (and document that)
*** Bug 311896 has been marked as a duplicate of this bug. ***
*** Bug 312391 has been marked as a duplicate of this bug. ***