GNOME Bugzilla – Bug 500437
Grab and Move a Window from Unused MenuBar and ToolBar Area.
Last modified: 2010-08-10 02:27:55 UTC
This idea is to make grabbing windows easier as well as improving the asthetics of the desktop. In addition to grabbing/moving windows via the metacity title bar we should also be able to grab the unused space in the menubar and toolbars. If this can be implemented we could have functional themes that look like this mockup: http://guentherbeyer.de/wp-content/uploads/2007/11/ubuntu_804_theme_test_03.png http://guentherbeyer.de/wp-content/uploads/2007/11/ubuntu_804_theme_test_04_2.png http://img88.imageshack.us/img88/2537/screenshotpv8.jpg Other information:
I guess that's a metacity thing.
This would be done in GTK.
I'd be happy to halp anyway I can in getting this implemented. It would really open up possiblities for themes. Here's another example: http://www.gnome-look.org/CONTENT/content-pre1/73163-1.jpg
(In reply to comment #2) > This would be done in GTK. > Can you elaborate how GTK could do this? In best case the decorations are drawn onto a X11 window, that's the parent of the menubar's toplevel window, but those decorations also could be drawn onto completely unrelated windows. Consider the freedom composited environment have. Also there are no rules, that menubars have to be directly attached to some vbox, that's the GtkWindow's child...
I thought the feature was basically that GtkMenubar/GtkToolbar would do a gdk_window_begin_move()/begin_resize() if you clicked on the empty part of the widget. I don't know if it's feasible in GTK, but I do know that the WM has no idea which part of a window is the menubar or toolbar, let alone which part is unused menubar or toolbar...
Oh... Oh... It was late and I was misreading this bug report... Distracted by the screenshots... I saw the screenshots, sepecially the second one[1] and thought it was requested, that GTK+ would draw over its window's decoration, when painting menu, tool and status bars! Created bug 509105 for that idea. (In reply to comment #5) > I thought the feature was basically that GtkMenubar/GtkToolbar would do a > gdk_window_begin_move()/begin_resize() if you clicked on the empty part of the > widget. I don't know if it's feasible in GTK, but I do know that the WM has no > idea which part of a window is the menubar or toolbar, let alone which part is > unused menubar or toolbar... Guess _NET_WM_MOVERESIZE [2] was designed for that job. [1] http://guentherbeyer.de/wp-content/uploads/2007/11/ubuntu_804_theme_test_04_2.png [2] http://standards.freedesktop.org/wm-spec/latest/ar01s04.html#id2526932
Created attachment 103655 [details] [review] Add requested functionality Here's a quick shot at a patch for this request. It seems to work fine and is actually quite nice to use in practice. There are several issues we should think about though. 1) How about right clicking to bring up the window menu? Will users expect this? 2) Apps using custom menu bars will seem broken in this regard (Firefox 2) 3) Assuming a theme like in the screenshots, apps without menubars might confuse the users, by not being distinct from the cases where you can drag on the menubar 4) We probably want to make it a property whether or not to do it, or make a more genral switch to make widgets begin_move_drag if they do not handle their button-press events. About the patch: The only thing that concerns me about the code changes is the small change in gtkmenushell.c that makes it return FALSE when no menu item is selected. This function used to always return TRUE no matter what. This might break stuff...
> 1) How about right clicking to bring up the window menu? Will users expect > this? I wouldn't expect that for most themes because normally title bar and menu bar look completely different. > 2) Apps using custom menu bars will seem broken in this regard (Firefox 2) I think if after this will be implemented in GTK+, firefox will imitate it sooner or later.
Just wondering if there is anything we can do to help this get implemented instead of just being a patch?
I'm at least somewhat opposed to this. I don't think it makes the desktop more usable if every little bit of whitespace on the desktop does something when clicked on... It is like the random lets-listen-to-scrollwheel things we have in the desktop, it doesn't really help.
Maybe it can just be limited to the menubar? And can be turned on or off somewhere? This theme seems to be very popular. http://www.gnome-look.org/CONTENT/content-pre2/86717-2.jpg This patch would really enhance this theme as well as other like it.
For me a motivation to be able to move windows via menubars and toolbars would certainly be themes with non-expanding window decorations (think Haiku style), so that a short window title means that you cannot move the window over its whole width. However as much as I like those themes, I'm not sure the proposed implementation is quite right. It is hard to discover and users may unexpectedly move the window. For instance, the patch allows you to move a window by finding the small gap between the first menuitem and the window border - that at least shouldn't be possible. As for the wider space between the last item and the end - that makes some sense, but is still unclear, for example, should dragging the throbber also move the window (which would require the application to allow for that in the first place) or not?
Mr. Dywan I think that people will certainly like to move their windows by the menubar if the theme suggest it and will not be angry if that had happened in other standart themes (although it is very rare). These themes like: http://gnome-look.org/content/preview.php?preview=2&id=87134&file1=87134-1.jpg&file2=87134-2.jpg&file3=&name=New+Wave are getting more and more popular because of their greater usability compared to others. A way to fix inproper move in the old-school themes I suggest using some property that can be turned on or of in the gtkrc file like 'gtk-enable-animations = 1' -> 'gtk-enable-menubar-move = 1'. Thus this feature will be only available in the theme that really need it.
Appears as though this feature is finally implemented. https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/532421
That is a useless reference. This one is useful: bug 611313