After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 500437 - Grab and Move a Window from Unused MenuBar and ToolBar Area.
Grab and Move a Window from Unused MenuBar and ToolBar Area.
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-11-29 15:49 UTC by wes
Modified: 2010-08-10 02:27 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
Add requested functionality (2.72 KB, patch)
2008-01-24 18:57 UTC, Mikkel Kamstrup Erlandsen
none Details | Review

Description wes 2007-11-29 15:49:47 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:
Comment 1 Vincent Untz 2008-01-07 23:07:23 UTC
I guess that's a metacity thing.
Comment 2 Havoc Pennington 2008-01-07 23:40:38 UTC
This would be done in GTK.
Comment 3 wes 2008-01-08 01:03:26 UTC
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
Comment 4 Mathias Hasselmann (IRC: tbf) 2008-01-12 23:13:57 UTC
(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...
Comment 5 Havoc Pennington 2008-01-12 23:35:20 UTC
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...

Comment 6 Mathias Hasselmann (IRC: tbf) 2008-01-13 09:17:41 UTC
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
Comment 7 Mikkel Kamstrup Erlandsen 2008-01-24 18:57:32 UTC
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...
Comment 8 Jan Niklas Hasse (Account disabled) 2008-02-22 22:52:18 UTC
>  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.
Comment 9 wes 2008-08-28 16:43:01 UTC
Just wondering if there is anything we can do to help this get implemented instead of just being a patch?
Comment 10 Matthias Clasen 2008-08-28 17:03:27 UTC
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.
Comment 11 wes 2008-08-28 18:41:24 UTC
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.



Comment 12 Christian Dywan 2008-10-20 14:31:18 UTC
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?
Comment 13 Anton Kerezov 2008-12-23 20:27:34 UTC
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.
Comment 14 wes 2010-03-05 16:25:15 UTC
Appears as though this feature is finally implemented.

https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/532421
Comment 15 Matthias Clasen 2010-03-07 20:55:37 UTC
That is a useless reference. This one is useful: bug 611313