GNOME Bugzilla – Bug 611313
Window dragging from menubars/toolbars
Last modified: 2014-08-14 20:23:35 UTC
So one thing that I was interested in doing as part of client-side-decorations was to make it so you can drag windows around from some of the 'chrome'-like regions of the window, which are typically things like menubars and toolbars. At the moment when button press events pass down to the GtkWindow and it determines that it's in the inner part of the window then it goes into drag mode, but now it's clear that this is not a great idea. Some apps handle button press events but still return FALSE (xchat-gnome, Evolution, WebKitGTK+) and going into window dragging mode creates problems. So now I'm thinking of going a different direction with it, and attached to this bug is a first patch which implements support for this feature (via a style property) for menubars right now. This does not depend upon c-s-d.
Created attachment 154862 [details] [review] Proposed patch for menubars This patch implements the proposed feature for menubars. I'll implement another patch separately for toolbars.
Maybe the style property should be on GtkWindow though, because it seems stupid to have to specify this for menubars and toolbars separately in the theme.
Add "See Also" bug: https://bugzilla.gnome.org/show_bug.cgi?id=500437
Created attachment 155231 [details] [review] Updated patch
Looks ok in principle to me. Are you going to do the toolbar part too ?
I have not tested the patch, but from experience with Chrome, I suspect this is going to cause problems with KDE 4.4 and its aero-snap (move window to top of screen to maximize, move away to unmaximize). Specifically, KWin unmaximizes a window as soon as it enters move mode (gtk_window_begin_move_drag), but this isn't a problem for KDE, because KWin windows don't enter move mode until you move the mouse or hold the mouse down for a few seconds on the titlebar. See https://bugs.kde.org/show_bug.cgi?id=228819 and https://bugs.kde.org/show_bug.cgi?id=222100
It kind of seems like a KWin issue doesn't it? compiz, and I think possibly metacity and mutter, have some kind of 'gravity' feature where if the window is maximized then you have to drag it a certain distance before it will unmaximize. Chromium works just fine with that. Either way, it's using _NET_WM_MOVERESIZE so KWin should be able to figure it out I think.
I guess what I mean is, why doesn't KWin behave the same way if an application invokes _NET_WM_MOVERESIZE?
I don't know. All I know is that Chrome does something similar to what you're doing here (calling gtk_window_begin_move_drag when you click on the titlebar), and it has this bug.
One thing I'll point out is the we should respect drag-threshold here. Ie don't start moving immediately, but only after moving a certain distance with the button held.
Created attachment 155605 [details] [review] Add toolbar support
I think you should move the style property to GtkWidget, probably, since I could see us adding this to the empty areas of status bars as well...
Created attachment 155612 [details] [review] Move style property into GtkWidget
Or the empty areas of GtkNotebook.
Small complaints: - There is a narrow band (1 pixel or so) on the left side between wm frame and first toolbutton/menuitem where I can drag the window, which I find mildly annoying - What I find much more unexpected is that I get to drag the window by clicking on separators in the toolbar
Cody, we should wrap this up and get it committed.
*** Bug 621522 has been marked as a duplicate of this bug. ***
Created attachment 164634 [details] [review] Properly disregards mouse events over GtkSeparatorToolItems The attached patch addresses the second complaint in the 15th comment -- that the window can be dragged by separators.
Committed the first patch together with a variation of the second (use an input-only event window for separators, and only eat button events if the separator is drawn (ie not just empty space).
Is there any chance this could be applied to the gtk-2-24 branch too? I've been using it for a couple of months now and haven't found any problems so far. I asked about this on launchpad to be included in Ubuntu (see https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1332721 ) and they pointed me back in this direction.... I can raise a new gnome bug report if that is the best thing to do?