GNOME Bugzilla – Bug 353076
Mac-style MenuBar for GTK (with patch)
Last modified: 2011-12-28 14:29:09 UTC
Hi all! I made a patch to display mac-style menubar for all gtk applications. A complete HOWTO is here => http://ubuntuforums.org/showthread.php?t=241868 Testing environment: Xgl 20060815, compiz 0.0.13.37_0ubuntu4 Applications that work: abiword, azureus, eclipse, epiphany, evince, gaim, gimp, gmpc, gvim, nautilus, terminal, thunar, vmware, ... Applications that don't work: - bluefish: two menubars overlap - acrobat reader 7: original menubar space is kept, crash after opening pdf - xara xtreme: original menubar space is kept
Created attachment 71694 [details] [review] mac-style menubar patch
Comment on attachment 71694 [details] [review] mac-style menubar patch The Patch, 2006/8/27
Created attachment 71696 [details] [review] Updated patch - Re-organize code - (docking) Reduce menubar's toplevel height to minimal when it's hidden
Created attachment 71697 [details] [review] Updated Patch Fix a docking bug (re-set STRUT when menubar is hidden)
Created attachment 71698 [details] [review] Updated Patch Fix a docking bug (re-set STRUT when menubar is hidden)
*** Bug 342083 has been marked as a duplicate of this bug. ***
Created attachment 71709 [details] [review] Updated Patch - Remove GTK_MENUBAR_KEEP_DOCKING option; Always use docking now (confirmed working with both of blackbox and compiz) - Use fixed menubar toplevel size even after the menubar is hidden (when main window lose focus), because compiz has problem handling frequent dock shrinking/expanding, and it flickers badly.
Created attachment 71821 [details] [review] Updated Patch - Make the menubar toplevel sticky explicitly - Tested ok with latest xfwm4-svn r22927 (4.4)
This is a really cool stuff, but I think FDO should create the standard for desktop menubar, this can allow KDE and GNOME or other DE or WM share this menubar space, the menu bar should give the desktop manager a handle to insert the global menu to this menubar. I really hope this can occure soon, keep going on guys, I will be your tester.
The menubar is managed by individual windows (like KDE's), it needs no special support from desktop or WM. However, two problems do exist: 1.Sicne no desktop provide a menubar (like Finder), it looks weird when you minimize or close all windows. 2.Some apps make different menubars for different windows. And this causes usability issues, for instance, in gaim's chat window you cannot see the "Quit" menu item, and you can't resize opened images when gimp's toolbox is focused...
I just confirmed that any wxgtk-based apps keep the original menubar space after the menubar itself is moved outside to toplevel. (wxgtk 2.6.3)
Created attachment 72753 [details] [review] Updated Patch Make the title label look better :) http://flickr.com/photos/aqd/242955991/
This would be an awesome inclusion in to Gnome. Since you only use only give focus to on window at a time, it makes little sense to have a menu bar in each window. You get more screen real-estate to boot! Devs, please include this as an option. Thanks.
Bearcat. The gnome dev team is not going to add this as option. They only do options that don´t make gnome look like OS9/OSX. Your only way to add it is as a 3rd-party applet.
Why can't gnome look like OS/X??
I compliment you on your initiative to do this work. Since you are trying to achieve the Mac OS X style, I would note that they also have applets along the top panel, which leans me to the following suggestion: In order to increase enthusiasm for what is quite an invasive patch, I would encourage you to also contribute (or find someone to team up with who can write) a GNOME applet that allows the GTK menu you have extracted to be embedded into a top edge panel. That way the change would be minimally invasive and makes better use of screen real estate - and not be in direct conflict with the top edge panel that is already on by default in distros like Fedora and Ubuntu. (You commented to me in #gnome that you weren't interested in GNOME, just GTK, but if you want to win support for your patch you might want to consider that appeasing the GNOME community, whose desktop depends on GTK, is a good idea) Good luck! AfC
AqD. I can't fully explain why. But I suspect that the reason gnome can't look like OSX is that the guys developping it don't want to accept that we want gnome to look like OSX (hey, even Apple is Windozeing they own OSX), I suspect that all of this happens because M$ has been doing underhanded tricks to make everyone feel that they like the Windoze look&feel, so far they have been succeding steadily at this and there's nothing to stop them. And Andrew, you'll need lots of luck for your quest. Cnvincing the gnome guys about accepting this feature is going to be harder than landing in the sun without burning to a crisp.
Note that Juan does not speak for the GNOME project. (Neither do I!) I do think it's a little unlikely change, but not because of any conspiracy theory - For GNOME we are already using the top of the screen for something else, which would have to be moved elsewhere; so you'd need to propose an entire desktop setup. (Or maybe it could be wedged in, but wouldn't that be confusing?) - It would be very odd unless all of the user's apps were adapted, not just the GTK+ ones. (Yes, I know KDE has some option like this already, but GTK+ + KDE is only *most* of the Linux desktop, not all of it.) - Screens are getting bigger all the time - moving something to the edge of the screen is less compelling if that edge of the screen takes a lot of travel to get to. But anyways, if you want to approach it on the GNOME desktop side, this isn't the right forum. First get a coherent plan as to how the whole desktop works with such a menu (web page with mockups) then bring it up on usability@gnome.org. On the GTK+ API side, I'd suggest that if you can also solve the problem of getting a Mac-OS style menubar for GTK+ on OS X, patches are much, much more likely to be accepted. I haven't investigated either that problem or your solution, but a reparenting approach is, I think, unlikely to work. You might have to go higher level with GtkUIManager and require some application cooperation.
Hi! It could be provide as an option for users. People who use GNOME desktop just don't need to turn on it, or they'd have to use adjust the setup. PS: I don't have a mac, and I will never get one because it lacks a DC client ;)
AqD as you said the desktop does not provide a menu. Thus what should happen is a default menu is displayed which should be the normal gnome menu (for launching applications). And whoever said it, I agree that there should be a notification area on it like on the macs. In essence, if this is loaded it should replace the typical top menu bar which has the notification area, and the menu.
the patch lacks support for Xinerama and dual-screen set-ups (it does not replicate the menu on all the screens). the usage of environment variables is weird, at best; XSettings should be better suited for this task, if you wish to keep this feature on X. foregoing GNOME support is also not a good idea. on a style note: the patch is totally inconsistent with any code style kept in GTK+; it should at least be cleaned up. on a more general note (as owen mentione): mac-style top menus are also a pain on large monitors, like the 30" apple tft display - you literally have to move the pointer for half a meter to use the menu. and screens are getting bigger, so I think that even apple is going to reconsider their UI choice. I agree with what owen said: adding support for the mac-style menu bar should be done on the quarz backend, for platform consistency's sake, but the support on other platforms (X, win32 and directfb) should be carefully evaluated before actually implementing it.
You're comment about the wide monitor is interesting. With easy keyboard access like alt-e for edit does anyone really use a mouse to access those keys anymore?
And in laptops display area won't be any bigger. This would be great as GNOME panel applet. Everyone who wants it could have it, and other could ignore this option.
The menubar doesn't need to show up in all screens. The only reason I make it a dock (and sticky) is to reserve the space, avoiding overlap with maximized windows and desktop icons. In fact it should hide itself from all non-current screens in a multi-head environment unless the main window is sticky. PS: the hotkeys like Alt+F somehow don't work with the mac menubar.
Created attachment 73995 [details] [review] Updated Patch - Keep menubar visible when the main window is being moved or popup window is shown (fixed a gtk problem!) - Change default inactive opacity to 0.75
Created attachment 74156 [details] [review] Updated Patch Fixed a bug when working with my xfce menubar applet: http://ubuntuforums.org/showpost.php?p=1586951
GNOME Panel Applet has been done, see http://ubuntuforums.org/showpost.php?p=1593123 if you want to try :)
Created attachment 74340 [details] [review] Updated Patch - fix problem under beryl/compiz - the environment variable GTK_MENUBAR_NO_MAC can be used to specified excluded programs. The default value is "gnome-panel acroread" (separated by space). Set to 1 or 0 to completely disable or enable the mac menubar.
I'd LOVE to have this as an option in GNOME. Currently the patch is being developed outside of the GNOME/Gtk+ team, and it shows; there's less quality control, and bugs pop up (no offense to the creator, you are doing a wonderful job but you need the blessing from the GNOME team about this). If this were in GNOME (via an applet) I'd be more, MORE than pleased.
Hi! There have been a gnome panel applet for some time, and xfce panel plugin too.
Created attachment 75491 [details] [review] Updated Patch There will probably be no more need for change in the patch. For gnome and xfce applets, see HOWTO there http://ubuntuforums.org/showthread.php?t=241868 I have made these for many weeks and they've been heavily tested. If you guys decide not to add it officially, please let me know clearly so I can stop wasting time here (since most of you have objections to this patch), and find other place to announce to gain more attentions.
please consider this patch as an interim solution for mac osX compatibility.
(In reply to comment #30) > Hi! There have been a gnome panel applet for some time, and xfce panel plugin > too. Yes I know, and it works great-- but bugs remain. - As suggested on the Ubuntu forums, when no window is active, it should show the Nautilus menubar (well, it should show *something*); - Some fix should be devised for the fact that the patch does not work with Firefox (obviously since Firefox is not gtk+). I have no idea how much work it would be to take this into account, but I think it's a must before this can be considered a viable patch for many people (including myself); - As also noted in the Ubuntuforums: when you first install the patch, and get the menubar *without* using the panel applet, there are lots of bugs. For instance, you can't unminimise a window, and the menubar of the first-opened window remains active, even when you load another window. This is fixed once you start using the panel applet; - And a minor cosmetic bug: the panel applet does not cooperate with panel transparency. Esp. in combination with the active-window-icon-panel-applet-thingie this is just a *great* feature for GNOME. Seriously, I *really* appreciate your hard work, AqD, this is one of those things GNOME *must* have as far as I'm concerned.
> - As suggested on the Ubuntu forums, when no window is active, it should show > the Nautilus menubar (well, it should show *something*); The non-active window problem could also be caused by a dialog box opened from a normal window. It'd not be good whether to show something or not. The only real solution is for gtk to provide an application-wide menubar and a desktop menubar. So far I have no idea how to implement this without changing API... (it may be possible to use a custom desktop menubar and a set of rules to combine multi-window app's menubars, to emulate the behavior under os/x) > > - Some fix should be devised for the fact that the patch does not work with > Firefox (obviously since Firefox is not gtk+). I have no idea how much work it > would be to take this into account, but I think it's a must before this can be > considered a viable patch for many people (including myself); XUL cannot create a dock window, so a patch into the internal code would be required. But I've been using my own hacked version of epiphany for many months... It'd be better if someone else picks this up. > > - As also noted in the Ubuntuforums: when you first install the patch, and get > the menubar *without* using the panel applet, there are lots of bugs. For > instance, you can't unminimise a window, and the menubar of the first-opened > window remains active, even when you load another window. This is fixed once > you start using the panel applet; The applet is *required* since I removed the standalone menubar code several weeks ago. Supporting the standalone menubar is too much trouble and it just can't work well with some half-complete WMs such as beryl/compiz. > > - And a minor cosmetic bug: the panel applet does not cooperate with panel > transparency. No it cannot. It may also have problems with the panel's background, depending on the theme you choose. The menubar is still the original menubar in GTK - its drawing/style is not modified, and I don't think it's good to do so from the patch. However, it may be possible not to draw the menubar's background - I'll try this later. > > Esp. in combination with the active-window-icon-panel-applet-thingie this is > just a *great* feature for GNOME. Seriously, I *really* appreciate your hard > work, AqD, this is one of those things GNOME *must* have as far as I'm > concerned. > Thanks :)
Go for it!! All I can really offer at this point is encouragement. If it works for 80% of the apps out there, that's good enough for me. If it catches on, the other 20% will work it out eventually. If I knew how to code properly, and knew anything about the relationship between Apps, WMs, DEs, GTK+ and X, I'd jump in and do my bit. I'll be watching this one closely. If the Gnome guys don't want it, then fork it, and fork them too.
(In reply to comment #0) > Hi all! > > I made a patch to display mac-style menubar for all gtk applications. A > complete HOWTO is here => http://ubuntuforums.org/showthread.php?t=241868 > > Testing environment: Xgl 20060815, compiz 0.0.13.37_0ubuntu4 > Applications that work: abiword, azureus, eclipse, epiphany, evince, gaim, > gimp, gmpc, gvim, nautilus, terminal, thunar, vmware, ... > Applications that don't work: > - bluefish: two menubars overlap > - acrobat reader 7: original menubar space is kept, crash after opening pdf > - xara xtreme: original menubar space is kept > While I haven't really looked into this patch too deeply, what I think might be a better approach would be somehow turning the menubar applet into a menu server, and letting GTK try to communicate with this menu server, falling back to an in-window menu if contacting and communicating with the menu server fails. This would allow a few cool things -- everything from allowing this to work in the KDE panel nicely to allowing good GNUstep integration with GTK apps. Any thoughts on how hard it would be to create a DBus protocol for this, and make the menu use it? I think it'd definitely be more code, but could work so much better, and be a much cleaner solution.
I've tried out the Gnome mac menu applet on Feisty. The only thing, amongst things others have said, is that for me this applet does not appear to follow Fitt's law (which I believe is the basis for a having a menu at the top). Currently, there seems like there's a 1 pixel barrier between the top of the menu and the top of the screen, which means you have to move your mouse down a bit after throwing it to reach the menu. This might just be a peculiarity of my system and theme though...
Also, a bit of a strange thing: the Gnome fast-user-switch-applet that you can install from Ubuntu's repos doesn't seem to work anymore with either the patched GTK or the Mac menu bar applet; I'm not sure which one causes the problem. It just shows up as white "|"'s on the gnome panel.
I'm willing to refactor this or rewrite from scratch, are there any suggestions that I could consider to maximize the chance of success?
*** Bug 82732 has been marked as a duplicate of this bug. ***
I have posted a very simple poll about this patch on OSNews [1]. At the time of writing, a total of 579 votes have been cast, with 468 (80%) in favour, and 111 (20%) against. Obviously, this poll is statistically not very strong, since it only takes into account OSNews readers-- OSNews readers willing to vote, even. The comments' section is a very interesting read. A lot of points have been raised, both in favour as well as against. Do with it as you please. http://www.osnews.com/story.php/17932/Should-GNOME-Get-a-Global-Application-Menubar/
Work on global menubar support in GTK+ would be much more interesting to me if it were directed at making GTK+ applications integrate better in the OS X desktop.
The mac-menu doesn't follow Fitt's Law because it's always about 22 pixels high. Setting the panel to 22px negates that. Of course, this is only a workaround. Another thing; most of the applications will have to be patched to follow the mac behaviour closer. Currently the mac-menu currently the mac-menu creates a first menu entry with the application's name, bold. But that entry does not allow access to the usual menu, it just 'decorative'. Other than that; I've been using this patch for about four weeks, and it works great. Of course, there are still some flaws, but I think they can be worked around. The man-menu doesn't follow(In reply to comment #37) > I've tried out the Gnome mac menu applet on Feisty. The only thing, amongst > things others have said, is that for me this applet does not appear to follow > Fitt's law (which I believe is the basis for a having a menu at the top). > Currently, there seems like there's a 1 pixel barrier between the top of the > menu and the top of the screen, which means you have to move your mouse down a > bit after throwing it to reach the menu. > > This might just be a peculiarity of my system and theme though... >
I think the application menu is an application thing and should be inside the application window. This mac-style approach is just wrong and illogical imho. Moreover it looks unsuitable if there aren't maximized windows, if the application doesn't have a menu bar or if it has a complex structure with multiple bars. Just my two cents.
Hello Manuel, please take a look at http://federkiel.wordpress.com/2007/06/24/the-lisabar-or-why-apple-got-it-right/ for some arguments in favor of a Lisa-type interface. In short: - no distinction between MDI and SDI - Document-centric user interface - saved screen estate - Fitt's Rule Of course you might disagree. ;)
I think everyone's in agreement that an application is likely to have a single, main menu-bar, so it should probably be abstracted in some kind of GtkMainMenuBar class or something like that. That way, having a global menu-bar wouldn't require such invasive hacks and it could easily be made configurable. This has already been done in Maemo/Hildon, and on Poky ( http://pokylinux.org/ ).
Yes, I agree. GtkApplication is currently being introduced as a replacement for GtkApp. Maybe some small changes could be introduced: + add GtkGlobalMenuBar to GtkApplication + depreciate the direct use of GtkMenuBar. Additionally there has to be a little bit of logic; display GtkGlobalMenubBar in the application main windows if there is no handler for a global menubar, display it in the handler if the handler is active. Emmanuel; I'm not sure if this kind of things should be handled in the backends. It would be much more proper if it's solved through the architecture of GTK+. Just as QT allows such kind of things.
It seems most users and developers agree, that this feature is usefull, so, why this bug is still UNCONFIRMED ?
I'm behind this patch 100%, it shouldn't be made default until the smaller issues are fixed but it should make it into gtk 2.12/2.14
I'm also behind this patch 100%. Is this the right place to push for it? Is there any other forum, list or community where this support can be expressed? Any way to contact GNOME developers directly?
Ubuntu Wiki entry: https://wiki.ubuntu.com/global_menu Ubuntu forums entry: http://ubuntuforums.org/showthread.php?t=241868 Thanks in advance!
*** Bug 499889 has been marked as a duplicate of this bug. ***
testers needed questions: * does it currently work against trunk? * has it been tested on a range of themes including the gnome default (or any historically default theme)? * does the menu resemble identically the appearance of other panel menu's (e.g. Places/System) in all tested themes? * is there a GConf key to turn it on/off, and has a patch been written to tie this into the new gnome control center appearance configuration, which also applies to trunk? critical usability questions: * does the menu respond when the cursor is above the menu item but at the very top of the screen, with all tested themes? * Are all of the menu accelerators still functional (e.g. alt+e)
Is anybody working on the menu server and dbus protocol now? Does gtk already have a dbus dependency? I think it's better to write a menu server, and then make patches to gtk. (In reply to comment #36) > (In reply to comment #0) > > Hi all! > > > > I made a patch to display mac-style menubar for all gtk applications. A > > complete HOWTO is here => http://ubuntuforums.org/showthread.php?t=241868 > > > > Testing environment: Xgl 20060815, compiz 0.0.13.37_0ubuntu4 > > Applications that work: abiword, azureus, eclipse, epiphany, evince, gaim, > > gimp, gmpc, gvim, nautilus, terminal, thunar, vmware, ... > > Applications that don't work: > > - bluefish: two menubars overlap > > - acrobat reader 7: original menubar space is kept, crash after opening pdf > > - xara xtreme: original menubar space is kept > > > > While I haven't really looked into this patch too deeply, what I think might be > a better approach would be somehow turning the menubar applet into a menu > server, and letting GTK try to communicate with this menu server, falling back > to an in-window menu if contacting and communicating with the menu server > fails. This would allow a few cool things -- everything from allowing this to > work in the KDE panel nicely to allowing good GNUstep integration with GTK > apps. > > Any thoughts on how hard it would be to create a DBus protocol for this, and > make the menu use it? I think it'd definitely be more code, but could work so > much better, and be a much cleaner solution. >
Karl, feel like writing your testing questions as a GHOP task? See: http://code.google.com/p/google-highly-open-participation-gnome/wiki/HowToWriteAGoodTask
Are you suggesting I submit it bearded one :)
Trying to not take more stuff that I can't chew. You know.. ;) BTW, Welcome pigeon. (http://mces.blogspot.com/2005/08/pigeons.html)
http://code.google.com/p/google-highly-open-participation-gnome/issues/detail?id=75 added :) Thanks fellow pigeon :)
I am working on the global menu project now. http://code.google.com/p/gnome2-globalmenu/ The 0.2.1 branch already solve most of the problems in the test case. However the patch code it self is still a hacking, since it introduced too many high level structures in a low level entity. In the _0.3 branch of svn, I have almost finished rewritting gtk2-aqd patch with GdkWindows stuff. The new patch works almost like an GtkHandleBox. But I still need help to finish it. Here are my ideas: Instead of overriding gtk_widget_map as AqD did in the old patch, I overrided these functions: Code: gtk_widget_realize, gtk_widget_unrealize, gtk_widget_size_request, gtk_widget_size_allocate, gtk_menu_shell_insert, gtk_widget_map, gtk_widget_unmap as well as having associated 3 GdkWindows with a menubar: Code: container_window, float_window, with a title "GTK MENUBAR2" widget->window, inside the application container_window contains the menuitems, while itself is a child of float_window/widget->window This is no more than an imitation of how GtkHandleBox is working. so I personally consider the new patch closer to a gtk acceptable patch. By setting a variable Code: GtkMenuBarPrivate->globalized the menubar can float out or go back into the application window. For the applet server, I am trying to avoid socket_steal, by replacing it with Code: gdk_window_foreign_new gdk_window_reparent The reason is (1) I still cannot find out how to have GtkMenuBar both inherited form GtkMenuShell and GtkPlug. (2) Fortunately, (seemingly) we only need the size reallocation part of the GTK XEmbed protocol, via a X's ConfigureEvent. (3) After studying the source code, GtkSocket will potentially do some unwilling work for our window. Most badly, it prefers to destroy the window when the socket is destoryed, which cause the client applications with my new gtk2-aqd patch dies. This is the unfinished part. I am still thinking about creating a MenuBarServer toplevel window for gtk2-aqd applications to detect whether a MenuBarServer is running and decide whether to float their menubars. It will be even better if the client can tell the server it created a new menubar. Also, I have another completely different idea for global menu: (1) rename the widget class GtkMenuBar to _GtkMenuBar, (2) define new widget class GtkMenuBar, which: has a GtkPlug as its child, and a _GtkMenuBar as GtkPlug's child. (3) implement every method of _GtkMenuBar in GtkMenuBar and pass the calling to _GtkMenuBar's method. (4) when realizing GtkMenuBar, check if a global menu server is running. If running, ask for a new GtkSocket's native windowId, then connect to it. If either fails, just leave the plug unplugged. The only difficult part is (4), 'ask for a new GtkSocket's native window id'. How to ask? How to get the response? How to do interprocess communication in X? How to deal with possibly competition? What will happen if an application have many menu bars? I can not solve the problems yet. If anyone of you have any ideas, PLEASE LET ME KNOW. Thank you.
If this could be a standard option, it would make Gnome integration with GnuStep that much easier: Personally I'd like to see Gnome fully integrated with the GnuStep framework, but for that, a solution for the menu like this is needed. I think the Etoille project is working on something similar. It could mean easier porting of OSX apps, which would work in Gnome, and allow for an easy way to install/remove consumer apps without repositories. It could also help projects like The Gimp, which doesn't know what to do with its menus; They want all the windows and palettes to be free-floating without a containing window like in Windows, but they have nowhere to stick the menus, so each window and tool palette gets one. A bad solution. A GnuStep version could have one place at the top to put them. Fitts' Law.
Created attachment 102005 [details] [review] New Approach of Patching I am working on the global menu project. This is a new patch, it still has some issues, but I think I should post it here now. It associates 1 menubar with 3 GdkWindow: widget->window, priv->float_window, priv->container_window. All the children widgets are placed in container_window. When a menubar is attached to the global menu server(I call it globalize), container_window is reparented to float_window, and the menu server takes float_window as a foreign window. When a menubar is detached from the global menu server(I call it unglobalize), container_window is reparented to widget->window. I developed a protocol based on XClientMessage for commmunicating between menu client and menu server. The coding is almost according to the specification I wrote at http://code.google.com/p/gnome2-globalmenu/wiki/GlobalMenuBarSpecification When a menu server quits in a normal way, all the menubars are moved back to the original window(I call them master window) on the fly. When a menu server starts, all the menubar are globalized when they receive the notification. Only the first menubar of a window is made global. svn is at http://gnome2-globalmenu.googlecode.com/svn/branches/_0.3/ the patch's name is still gtk2-aqd, though it has become completely different for the old one.
Gnome2-globalmenu 0.3 is ready. Completely new patch/code for gtkmenubar. Reconstructed menu server. New features: * + Stupid Menu Bar Scrolling * - No Window icon * + Skinning(partially working) * + New Protocol: Connectionless, Asynchronous(Should update the Specification) * + True Server/Client Architecture * + Stablility * + Menu server auto detection * + Auto Guessing whether the menubar is a global one instead of hard coded window names. http://gnome2-globalmenu.googlecode.com/svn/branches/0.3/
I'm not used to downloading source code. Can you please let me know what exactly should I download to test this patch? Is there any FTP access? If not, how do I download directories via HTTP?
There are some packages for fedora, ubuntu, and gentoo (installation guide as well) on http://gnome2-globalmenu.googlecode.com/
I've been playing with this a bit. I removed the Menu bar applet and replaced it with the Main menu applet (put it in the left corner) and the Global Menu applet. I've started most apps Ubuntu installs by default and here's what I've seen: Some apps take all space to the left of the menubar, effectively hiding the Main menu applet. Here are some that do so: Calculator Disk Usage Analyzer Dictionary Bluetooth analyzer Manage Print Jobs AisleRiot Solitaire Four in a row Gnometris Fspot Gthumb Totem Apps that don't use a menubar (Tomboy, Screenshot) leave the Global menu space blank. Since there's no displaying of the application title anywhere besides the window's title bar, this makes the Global menu bar look weird. The GIMP shows the menu only when clicking on the Toolbar window. This is confusing. Firefox, Thunderbird (any XUL app?) and OpenOffice.org don't work. (I'm sure you already know.) Abiword does fine. My main impression is that it feels as Gnome apps were not designed to be document-centric (which is exactly the case...) This is a shame but it would take more than a Global menu bar to "translate" the current Gnome user interaction philosophy. However, I'd like to encourage you to keep the good work. Maybe if we get more people to try this applet they'll push for a more document-centric design. As a side note, it seems that the current build breaks the software index (because of the patched libgtk packages installed) and Update Manager complains accordingly.
Hi, thank you for trying and the comments. GIMP issue is very weird, it sometimes occur, sometimes don't. As a solution for the blank top panel, I suggest you to keep panel-menu-bar at the left, and put the global-menu-applet right next to it. Then even if the active window has no menu bar, the panel doesn't look mor weird as the default one. here is a screen shot.
Created attachment 102562 [details] Suggested gnome-panel layout Suggested gnome-panel layout
This has got my vote as an option for a future Gnome. I love Gnome, but the conservatism is sometimes too much.
Probably AqD is not interested in developing GlobalMenu... That's funny. Such enthusiasm, and now silence.
I don't see it any funny. It is a serious problem to every the programmer who only take such coding as fun and who have to make a living via other activities. Human mind is far away from freedom. We are miserable tiny living objects, controlled and dominated by those businesses, by our indistinguishable social roles. It sad but true that at some point of our life, some(or most) of us will have to given up our hobbies, give up our creative works, for either a short or a long period, even for ever. AqD has disappeared for a long time. Mac menu (with applet) was not in a good maintained status for a few months before I took it over. I still can manage sometime to produce ideas and codes. sooner or later, however I may also disappear, and nobody (even myself) can tell if it is for ever or just for a few months/years.
Some development is going on this project: http://code.google.com/p/gnome2-globalmenu/
Almost one month old.
actually 0.4-devel branch seems quite active http://code.google.com/p/gnome2-globalmenu/source/browse
Jakub, The tone of your comments here, and on other bugs, are not appropriate. Please refer to [1], in particular the sections about 'assume people mean well'. [1] http://live.gnome.org/CodeOfConduct
Created attachment 106312 [details] [review] Newest Patch(working with libgnomenu) This patch is a true 'patch' a workaround. I've successfully finished the Global Menu bar widget(GnomenuMenuBar, a subclass of GtkMenuBar), in a library 'libgnomenu'. This patch will detect if GNOMENU_TYPE_MENU_BAR is already initialized(usually done via env GTK_MODULES=libgnomenu). If so, gtk_menu_bar_get_type() will return GNOMENU_TYPE_MENU_BAR instead. This patch shall be considered as a workaround for non-global-menu applications to take advantage(if it is an advantage) of a globla menu bar. It doesn't contain any code for global menu.
WOW! Is that it? First glance says its awesome, very very simple, mostly additions etc... One concern I have is this; @@ -215,6 +257,7 @@ GTK_PARAM_READWRITE)); g_type_class_add_private (gobject_class, sizeof (GtkMenuBarPrivate)); + } I don't see the need for a new blank line :)
The patch is produced by an 'svn diff'. sorry for that ... the blank line must be a typo.
A couple of other points that could have better formatting/explanation; What's up with the comment? libgnomenu = g_module_open("libgnomenu", 0/*G_MODULE_BIND_LOCAL*/); this looks messy and more difficult to read if () { if () { . . } else . } else . this is similar to above, you should brace the if statement when the else has one, just for tidiness. if(!(*type)) /*gnomenu_menu_bar not registerd yet*/ consider; if(!(*type)) { /*gnomenu_menu_bar not registered yet*/
Created attachment 106529 [details] [review] Shall hack gtk_menu_bar_class_init instead of else where The former patch don't work smooth, it don't work with several apps. This time It gets even more concise by hacking gtk_menu_bar_class_init, shadowing all the class member functions with gnomenu_menu_bar's.
Thank you for revising my code! I've updated the patch. I hope it is better now. (In reply to comment #78) > A couple of other points that could have better formatting/explanation; > > What's up with the comment? > libgnomenu = g_module_open("libgnomenu", 0/*G_MODULE_BIND_LOCAL*/); > > this looks messy and more difficult to read > if () { > if () { > . > . > } else > . > } else > . > > this is similar to above, you should brace the if statement when the else has > one, just for tidiness. > if(!(*type)) /*gnomenu_menu_bar not registerd yet*/ > > consider; > if(!(*type)) { /*gnomenu_menu_bar not registered yet*/ >
Hi. I wonder if any of you are interested in a RPC/IPC based menu system. If i am going to write one, shall I make it based on XClientMessage or D-Bus? Which one has more probability to get accepted by GTK mainstream?
I'm not a developer but IMO eventually accepted could be the more modern solution :> .
I vote +1 for this one!
@Ali: If whole community would vote on this, we'll have a big mess in here :P .
Yeah let me provide a link to discuss on this. http://code.google.com/p/gnome2-globalmenu/issues/detail?id=80 http://code.google.com/p/gnome2-globalmenu/issues/detail?id=81 But i think I've set up my mind. A XClientMessage solution is enough. dbus dependency is not nessesary. Perhaps it will also help to merge native mac menu bar on osx.
I'd LOVE to have this as an option in GNOME and many other people too. But nobody from the gnome-development-team have post a comment on this. Post a comment here against or pro the patch/feature but don't ignore your user's meaning. I could understand that the guys developing gnome don't want that gnome look like OSX or is a clone of OSX, but that is not the thing that we discuses here. We only won't 1 nice feature fro OSX integrated into Gnome. Apple takes the whole linux kernel into OSX so why we can't take some nice features from OSX. I found this in the gnome "Usability Principles" "So, design your application to show only useful and relevant information and interface elements." http://developer.gnome.org/projects/gup/hig/2.0/diff-from-1.0/principles-simplicity.html That is exactly what this feature does. just my two cents Ralf
I just need to correct some of your facts here (even though I'm among those interested by this patch): 1) gnome devs *did* comment here. Karl, Behdad, Emmanuelle (and maybe others) are developers. 2) apple do not incorporate linux as their kernel, they use some form of BSD. Read up on wikipedia. 3) your rule taken out from the HIG (and trust me, I'm a HIG fan) does not apply. The individual applications are properly designed. You're talking about the global desktop metaphor here. And it is not as simple as that. There is good and bad in both approaches.
> Apple takes the whole linux kernel into OSX so why we can't take some nice features from OSX. That made me laugh ^^ . -- Of course, GNOME can implement some useful features, but implementing everything can cause GNOME to be OpenOSX or OpenWindows, what we should prevent. "We can do it better(tm)." However, globalmenu is very comfortable.
*** Bug 521931 has been marked as a duplicate of this bug. ***
I remember some times ago people suggested to put the global menu on DBus. and I did it. Now entire menu widget tree of any GTK application can be exposed on DBus; any modification on the tree are broadcast to others with DBus signals. By this way there are only two spots to patch on GTK: One is Bug 553204; for menu shell to emit a signal when children are inserted, just as other GtkContainers do with 'add' signal. The other is the true global menu patch: to load libgnomenugtk.so, and call global menu whenever a menubar is attached or removed from a window.
Global Menu finally gets rid of any source code patch to GTK. The technique is to change the GObjectClass VTable for GtkMenuShell GtkMenuItem GtkMenuBar when global menu library (libgnomenugtk) is loaded as GTK_MODULES. because gtk_module_init (loaded by GTK_MODULES) is always invoked before any of the classes or their sub classes are ref()ed, dynamically changing the VTable for them affects the applicatoin throughover its entire life. If any people on this bug are still interested I welcome you to test the new GlobalMenu at trunk http://gnome2-globalmenu.googlecode.com/svn/trunk A Vala 0.3.5+ compiler is required to build from svn, but building from released tarballs at download location doesn't require vala. GTK no longer requires(assuming it ever required) this enhancement because this enhancement is no long a GTK thing. Should this be considered as the solution of the BUG?
FYI: Global Menu released a 0.7.2 last week (Jan 10th or around). source code available at: gnome2-globalmenu.googlecode.com/svn/tags/v0.7.2 tarballs available at gnome2-globalmenu.googlecode.com/downloades/ Installation: http://code.google.com/p/gnome2-globalmenu/wiki/Installation Release Notes since 0.7.0 http://code.google.com/p/gnome2-globalmenu/wiki/ReleaseNotes --------------- gnome-globalmenu 0.7.2 svn checkout http://gnome2-globalmenu.googlecode.com/svn/tags/v0.7.2 Downloads: http://code.google.com/p/gnome2-globalmenu/downloads/list?can=2&q=0.7.2 * Experimental XFCE Plugin; edit ~/.config/xfce4/xinitrc(and chmod +x) to enable the GTK Plugin #!/bin/sh export GTK_MODULES=globalmenu-gnome . /etc/xdg/xfce4/xinitrc * Removed explicit GIO dependency; the gtk plugin module compiles and works with GTK 2.10. * Updated to vala 0.5.5; pre-0.5.5 vala no longer compiles the svn source; * Improved documentation * Code refactoring, improved speed, bigger memory foot print (6-8 MiB RSS) * es_ES translation * ru_RU translation * Fixed issues when AWN is the active window * Fixed Several leaks in the GTK plugin module * Fixed the wrong size allocation of icon in menu items. gnome-globalmenu 0.7.1 svn checkout http://gnome2-globalmenu.googlecode.com/svn/tags/v0.7.1 Downloads: http://code.google.com/p/gnome2-globalmenu/downloads/list?can=2&q=0.7.1 * Bug fixes * Enable/Disable Global Menu via GtkSettings? and the applet. o loading globalmenu-gnome via GTK_MODULES is no longer supported. o suid applications now also respect global menu. (security!) * Disable RGBA by default due to stability issues. * it_IT, fr_FR, zh_CN Translations gnome-globalmenu 0.7 (alpha) * svn1845 All children in PanelApplet? and subclass of GnomenuMenuBar? changed to 'local' by default. No need of GTK_MENUBAR_NO_MAC(still supported) for gnome-panel, user swither, unit tests, and most panel related applications. * svn1833 Added window list and window title to switcher. * svn1830 Theming issue * svn1823 Switcher * svn1816 Awareness of gnome_settings_daemon/gtk-modules. o Unloading is yet unstable. perhaps bugs of GTK/gsd. o No need to use GTK_MODULES=globalmenu-gnome. (still supported) * svn1796 gconf configuration for the applet * svn1795 register the gtk module in gnome-settings-daemon's gconf key * svn1762 all parameters of libglobalmenu-gnome are combined to GLOBALMENU_GNOME_ARGS o --verbose o --disable o --log-file="filename" * svn1725 o 0.7-devel branch starts * svn1723 o RGBA support for Gnomenu.Menu * svn1711 o grab F10(or what ever in GtkSettings?) * svn1696 o + alpha: the core is ready. please test the stability.
Hi.. I am an ordinary ubuntu user.. I registered here just to vote for this feature to be included in gnome. But I couldn't find a button or something else to cast my vote, hence the comment. I really like this feature. I hope it will be usable very soon. Keep up the good work! Thank you!
(In reply to comment #93) > Hi.. I am an ordinary ubuntu user.. I registered here just to vote for this > feature to be included in gnome. But I couldn't find a button or something else > to cast my vote, hence the comment. I really like this feature. I hope it will > be usable very soon. Keep up the good work! Thank you! This page should explain why: http://live.gnome.org/BugzillaHelp Nevertheless, I vote for this bug too :-)
Great product! Keep up the good work, this wouldd be a great addition to the default gnome interface. I think, however, that there needs to be more support for web browsers (specifically Firefox and Opera) because for me all they displayed was the page I was on, and didn't refresh itself unless I clicked on it, and had no options (file, edit, view, etc.) Otherwise, GREAT!
I'd just like to say that I love the GNOME Global Menu Applet, and I think it'd make a great product for inclusion in the default GNOME environment. Especially if it could be toggled on-off by a switch. To Bryce: It doesn't work with Firefox or Opera because it only works with GTK applications. Firefox looks like a native GNOME app, but it's actually built using XUL, and I don't know what Opera uses. I'd love it if it worked with Firefox ... of course, Epiphany's kinda grown on me, too! And I already preferred Abiword to OpenOffice.
I vote for this applet, but, it would be nice to have XUL support for it.
I would love to see this. What is the current state?
Current state is no progress, and no progress planned...
Oh, Canonical is working hard on this for Unity, though I don't have any details. Getting upstream is another issue... ;-)
https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationMenu Would be great to see the patch accepted to GTK+
GtkApplication is now in master, a new solution could be developed against this new class
I vote for this feature. As gnome3 no longer shows active applications in status bar/panel, there is plenty of free space available there so moving menu there saves some screen resources and makes room for more content.
This is a usability bug, you can't use the alt+letter hotkeys in dialog windows belonging to the main window this applet manage. I mean if there is an information or an error dialog and that dialog has 3 buttons one of them has the letter 'e' as alt hotkey i hit alt and then e on my keyboard, the applet steals the focus and opens the edit menu instead. As an example the System monitor. 0. Enable the applet 1. Open system monitor 2. Hit down arrow to select a process 3. Hit alt+p to hotkey de End Process button 4. The Confirmation dialog opens. 5. Hit alt+e to select the confirmation End Process button 6. The Edit menu opens Alt+e is the hotkey for the Edit menu and also for the button inside the confirmation dialog, you can of course use the key arrows to select the proper button, but still. Proposed solutions: Detect dialogs and disable the menus alt+keys or be less agressive about who has focus.
GTK+ master has all the infrastructure needed for application menus and global menubars, including a working OS X implementation. It is up to desktop environments to use it.