GNOME Bugzilla – Bug 706323
HeaderBar window menus
Last modified: 2013-09-17 19:39:41 UTC
HeaderBars have a simple window menu with Minimize, Maximize and Close. They should be identical to the standard window menus you get with a titlebar.
Some of those actions may not easily doable client-side. Move - gdk_window_begin_move_drag Resize - gdk_window_begin_resize_drag Always on Top - gtk_window_set_keep_above Always on Visible Workspace - gtk_window_stick Only on this Workspace - gtk_window_unstick Move to Workspace Up - missing api Move to Workspace Down - missing api Move to Workspace n - missing api
(In reply to comment #1) > Some of those actions may not easily doable client-side. ... Hmm, OK. Well let's see. I'm not too concerned about move and resize; any of the others would be nice to have.
There's also a few new ones we should consider: Move to monitor left/right/up/down Move to presentation screen
The complication with all of these is that they have state that we need to get to the client-side: am I on the last/first workspace ? is there a monitor to the right ? is there a presentation display ?
Since we are already too close to 3.10 to make all those new APIs, perhaps we should add the options that we can, and postpone the rest to the next cycle? Always On Top is a very useful feature and it would be unfortunate if it disappears for a whole cycle...
these apis are internal between gdk and gtk. I wouldn't hesitate to add them
I've now implemented all except for move and resize. Curiously, these turn out to be the harder, since the apis we have don't quite seem to work here.
oh, and none of this works on wayland - we don't have always-on-top, or sticky, or workspaces implemented there.
(In reply to comment #8) > oh, and none of this works on wayland - we don't have always-on-top, or sticky, > or workspaces implemented there. Do we have bugs filed for those?
Another RFE for tradition functionality that's missing: double-click (or click an optional UI element) to Toggle Shade. I know this isn’t a UI priority, but it has been available via the Tweak Tool, and I find it a really handy way to work with the need to get windows temporarily out of the way instead of minimizing. With window shade, the spacial identity of a window is retained. (And so it plays nicely with the overview mode, which is awesome.)
Created attachment 253090 [details] [review] gtk/gtkwindow.c: Fix on non-X11 Hi, I'm sorry to say this, but the patch 7e4bcf91 ("Add workspace handling to the window menu") would break the build of gtk/gtkwindow.c on non-X11 platforms. I have here a simple patch to address this. With blessings, thank you!
Sorry, the commit should be 7e4bcf91. Sorry for the noise.
Review of attachment 253090 [details] [review]: oh, sorry about that
Review of attachment 253090 [details] [review]: Hi, Thanks. The patch (attachment 253090 [details] [review]) was pushed as c8cad491. With blessings.
(In reply to comment #9) > (In reply to comment #8) > > oh, and none of this works on wayland - we don't have always-on-top, or sticky, > > or workspaces implemented there. > > Do we have bugs filed for those? No, we don't. Implementing these will require defining/extending a xdg_shell interface to replace the basic wl_shell one.
I'll consider this bug done for now.