A very, very long time ago I personally advocated the inclusion of a certain feature into GNOME. We set up a poll at OSAlert, which resulted in a very, very resounding “yes!” from the OSAlert community – many of which are GNOME users. The feature in question was the global application menubar, which allowed the GNOME desktop to have a menu bar atop the screen similar to that of Mac OS X. The poll is long gone, the debate thread in the Bugzilla has died out, and no decision has yet been made. I wanted to know where this feature stands, and how much the developers have improved it, and I was in for a surprise.
Back in the day when the patch was first released, it required a hacked Gtk+, which made the patch a little daunting for many people. It was also rather buggy at times, and you couldn’t really rely on it too much. Well, I am happy to inform you all that that has really, really changed. The patch has become more than a patch – it’s a simple panel applet now. And it no longer requires a hacked Gtk+. They also have a fancy website now.
The panel applet, once installed, can be added to any GNOME panel as you would any other applet. Once it’s in there, right click on it, open its preferences window, and activate it. That’s it. THey even have a nice repository at Launchpad, so installation is a breeze. Add the PPA to your sources.list, install the relevant package, et voila. The current package has an error in it, so some users may need to run the linked commands to make it work properly. The next packaged build should solve this.
Once installed, it works beautifully. They’ve added several convenient options to configure the applet, so you can tweak it to your needs. For the rest, it works exactly as you would expect: the menubars in your windows disappear, and are placed in your GNOME panel of choice in Mac OS X fashion. The only downside is that it doesn’t work for non-Gtk+ applications such as Firefox or OpenOffice.org. Qt+ applications are also not supported, but there have been talks in the KDE community to standardise their upcoming global menubar implementation on the Gtk+ one, making it all cross-platform.
I’m totally addicted again. I prefer a global menubar, and I know a lot of you agree with me that it’s a better solution. It is strictly a matter of taste though, so the fact that it’s implemented as a panel applet is just perfect. It can be included in GNOME, as an optional applet, and those who prefer it can use it.
I would like to, once again, urge the GNOME team to finally accept this applet into the default GNOME distribution (by lack of a better word). This is a feature requested by quite a number of people, and its inclusion as an optional, turned-off-by-default panel applet poses no threat whatsoever to GNOME’s policies and goals regarding interface design. We can have swimming fish and moving eyes in our GNOME panel by default, but a much more interesting and useful feature gets the boot.
If GNOME fails to address this issue (it’s their project after all), then maybe Ubuntu can step in and include this option. It would make it so much easier if it finally received what it deserves: blessing from the GNOME and/or Ubuntu community. Now that KDE is also looking at this specific implementation to serve as the cornerstone for a cross-DE implementation of the global menu bar, there is simply no excuse to hinder this process.
The rest of us were laughing too hard to vote. This idea is as lame today as it was then.
The rest of us were laughing too hard to vote. This idea is as lame today as it was then.
Care to explain actually how is it “lame” then? I find it a good idea. For me, that is, can’t say about others. You see, I have a small screen, 15″ CRT using 1280×1024. I almost never use menus, I either arrange the toolbar to have the functions I use or I know the keyboard shortcuts. As such, every single window having its own menubar on the screen wastes space that I could use for something more useful. Also, when I need to access the menu bar of an application I most likely have already switched to that application. Oh, and the screen looks tidier if there’s only 1 menu bar visible at all times and always in the same predictable place.
I ain’t saying it’s for everyone, but claiming that the idea is “lame” without even explaining any reasoning behind that claim is.. well, to borrow your terminology, “lame.”
It’s not just looks, for me at least. I find that if I’ve got more than one window on the screen at once, I’m liable to click on the menu bar nearest the top of the screen, even if I’m working in a different window. It’s not because I’m used to Macs (I’m not), I guess it’s just that usually I’ve got one window full-screen at a time, so the menu bar will be at the top, and when I have more than one window open, I still subconsciously expect it to be at the top.
Judging by other comments, it looks like it’s one of those eternally irreconcilable difference things (like Gnome vs. KDE, or Debian et al vs. Fedora et al.). I’d certainly like to see it as a standard option, though.
The universal menu bar made sense in 1986 when most applications would be command line programs running windowed, but in 2009 it’s makes less sense since most applications are written for the abstractions a GUI. It answers the question, “How do we add GUI functionality to command line programs running in a windows?” Add a universal menu bar with copy, paste, quit, etc. Basically, applications in 2009 take advantage of the abstractions the GUI provides, and the universal menu bar is a relic from a time when applications didn’t.
On small screens, I agree that a menu bar makes sense, but at the same time it’s still taking up screen real estate. The better idea would be to hide the menu bar under one icon or menu, and have a few shortcut icons. Since the menu bar is designed to hold rarely used items anyway, it becomes a rarely used item itself, and reducing the bar down to a single interface item would tidy the GUI up nicely. Microsoft is going this direction with it’s Ribbon interface, and there is the Tiny menu extension for Firefox to enable the functionality.
http://www.componentone.com/newimages/Products/ScreenShots/StudioWi…
https://addons.mozilla.org/en-US/firefox/addon/1455
A good compromise might be a combination be having multiple document windows with a menu/toolbar that can float or be pinned. Mainly a slimmed down version of the Dreamweaver/Photoshop/Gimp floating windows concept. This could solve the problem of toolbars and menu bars taking up screen space, and it would open up the possibility of having the menu/toolbar jump to where the mouse is after a key press then return to a home location.
Quick and ugly mockup of the idea:
http://i40.tinypic.com/2mgqrza.jpg
Thats exactly what GNUStep does:
http://www.gnustep.org/experience/images/Gorm-Example1.jpg
which is pretty nice also.
Yeah agreed, I’ve got 4 30″ Dell monitors (side by side rotated vertical). Having to move a mouse across that much screen real estate is just silly.
Obligatory pic:
http://www.digitalprognosis.com/pics/my-work-setup.jpg
Awesome! Thanks for passing that on, I was literally just thinking about it the other day…
And it’s written in Vala.
If it were to be included as optional and disabled by default, why the need to include it in the default Gnome distribution at all?
Wider deployment leads to better testing leads to more eyes on the code leads to more developers leading to a solution for non-Gtk+ apps like FF and ooo and to adoption by KDE/Qt/GNUSTEP/etc., finally leading to a cross-platform global menubar.
And people want it.
Edited 2009-02-14 00:46 UTC
Firefox is a GTK+ app, last I knew.
Also, KDE 3.x has the ability to move the menubar to the top of the screen.
Edited 2009-02-14 01:09 UTC
I understood that Firefox was a XUL –Mozilla’s own cross-platform GUI toolkit– application, and that XUL mimicked GTK+’s look’n’feel on *nix.
I believe it’s a hybrid, it uses GTK for the basic window, and XUL for everything displayed inside it. I don’t precisely know where GTK ends and XUL begins, but you can compile firefox with several toolkits (see the –enable-default-toolkit option in configure). Even XUL needs a base window in which to display its controls.
It uses GTK/GDK for basic window functions and drawing. And then it reads GTK config to paint the UI in a similar style.
It looks like GTK, but it’s not GTK or any native GUI toolkit at all, and there are some differences in widget behaviors (ex: you cannot use mousewheel to switch tabs).
It’s not. It’s a cross-platform application that uses GTK in a round about-way without the level of integration you would expect from a GTK application. XUL is then hacked on to the top so that it works in just about the same way that it does on other platforms.
That’ll be your sticking point, getting third party apps to code in the hooks to make use of such a cross platform bar. Firefox would be a big one to have on board, especially if they could have some cross platform support to publicize along with it.
1. This is at best going to be hacky on any unix desktop because of the issues with compatibility you have already pointed out. At least with KDE they have a very standard menu bar system where every app will work. With GTK there is a standard way of making menu bars but many apps don’t use it. You combine that with Firefox (probably the #1 most used app on the unix desktop) and OO.org and you get a messy, inconsistent cludge that will surely scare away new users and irritate old ones.
2. You can’t point to your poll as indicative of anything. Your sample (as others have pointed out) is self selecting. The only way to get an accurate representation is to do a random sample by contacting at random existing gnome users. That would be hard I admit but your poll certainly has no merit as indicative of what the overall community would like.
3. My intuition is that what we are hearing in your poll and in the bug only sounds significant because there is a vocal minority skewing our perception. I for one hate that interface. I think if you did manage to get a good sample of people even that would be misleading compared to what the random poll numbers would look like if you first had people use the other interface for a while (where they would see the mac way is not always best and it is especially a junky cludge on unix). My prediction is that if you did a test on a randomly selected group that the poll would in fact be overwhelmingly *against*. (However I admit that is just a guess without real polling data so I recommend not messing with something that is working just fine without data)
4. Even if people do want it and it doesn’t suck (both of which I would debate) you still have consider “how valuable is it?”. Is it just a nicety or would it transform the desktop in some important way? The reason I ask is that this is fairly disruptive on several fronts so it had better have high value because there is definitely a high cost. First of all existing users will have to adjust their long ingrained habits and expectations. Some users will be pissed off and defect to KDE or elsewhere. Existing GTK apps will have to be updated and long hard fought battles will have to be waged with KDE, OO.org, mozilla and others. And in the meantime gnome will suffer from the perception that it is inconsistent and cludgy. Older apps will never work and newer apps written first for windows or KDE will present an ongoing problem for ever. Is it worth it? Even for advocates I think the answer is probably no especially when there are so many other more worthwhile efforts.
Edited 2009-02-14 01:50 UTC
Personally, I think the single menu bar idea sucks. On the other hand, I’m sure there are significant numbers of GNOME users who think it’s the greatest thing since sliced bread. As long as it doesn’t add too much bloat to GNOME, by all means include the applet in the standard GNOME distribution. Just don’t enable it by default and don’t make it difficult for me to eliminate the applet from my panel.
What I’d like to know is why sliced bread always gets such a free ride, and such implicit endorsement as this. Sliced bread has disadvantages. It gets moldy faster. And it dries out faster than the unsliced, *real* variety.
Edited 2009-02-14 03:26 UTC
Or, as so stated by the late George Carlin:
What’s so great about sliced bread? You got a knife, you got a loaf of bread… slice the f**king thing and get on with your life.
The same can apply here. You got the applet, you got the option, set it the way you want and get on with your life.
I’m finding that the real bummer about being 45 is that entirely too many people, once a part of my life, are now “late”. When watching Star Trek movies, I find myself keeping a tally: “He’s dead. She’s dead. She’s dead. He’s dead.”
It’s disturbing.
Bones, Scotty, Khan
Thats 3, is there any I missed ?
I understand what you mean in your post, however, sometimes I find it strange when I find out some people who are still alive
Jack Klugman (Quincy), Jerry Lewis, Kirk Douglas, Norman Wisdom, Cliff Richard, the list goes on, so to speak
Plenty. Mark Lenard (Sarek), Jane Wyatt (Amanda), DeForest Kelly (McCoy), James Doohan (Scotty), Ricardo Mantalban (Khan), Majel Barret Roddenberry (Chapel/Number One), Gene Rodenberry, Persis Khambatta (Ilia), Bibi Besch (Carol Marcus), Merrit Butrick (David Marcus)…
Star Trek has done better than some. The entire cast of “I Love Lucy” is long dead.
Hope this post brings a bit of cheer to your day.
Edited 2009-02-14 13:12 UTC
According to wikipedia, that phrase came into common use after Wonder Bread launched a marketing campaign touting the innovation, so it looks like it’s a slogan from the ’30s or referencing a slogan from the ’30s.
http://en.wikipedia.org/wiki/Best_thing_since_sliced_bread
Plus, most people buy cheap knives that barely cut air, so they end up with squashed bread when they try to slice the loaf up.
Personally, indoor plumping gets my vote for best innovation ever. “Greatest thing since indoor plumping” doesn’t have the same ring to it though, and it brings up all sorts of negative connotations.
Yes, you are right in the beginning it might lead to inconsistent looking desktops, but if it is well documented, people will use it. Besides, not using standard ways of doing things is usually a bad idea. It means that you will have to handle more bugs and do more testing by yourself instead of relying on code that is used and tested by a larger amount of people.
As for scaring away new users, this doesn’t seam to be a big problem to MacOS, so why should it be a problem to Gnome.
This is one of the most reasearched area in usability, and research usually comes to the same conclusion as the poll. Read any 101 course in usability, and you will get plenty of references. Even though I can’t seam to remember any studie on Gnome, it would be resonable to believe that it is highly likely that you would get the same results as e.g. for MacOS-X.
The interesting thing is actually not if people would vote for or against this. The interesting thing is if a global menu would provide a more effective user interface (like most research suggests). People might vote against this just because it is something new that they have never tried. Once they have hade the chance to actually try it they might change their minds. For all people that remain hating it there could be an on/off switch in gconf.
If done right, it would also have the side effect of forcing developers to make better separation between control and application model. This would lead to more maintainable code.
It all depends on how it is implemented. Assume that it is implemented as a “menumanager”, with a standardized interface to the applications. Then it would give room for a lot of innovation, just like we have a lot of interesting windowmanagers we could have a lot of differenet menu manager, some of wich would create global menus, others may do other useful things like providing hooks for rekording of macros, or improve accessability.
There is actually no need for this when Avant does an excellent job as a drop in.
https://launchpad.net/awn“>
Here is one I made earlier….
http://i145.photobucket.com/albums/r240/ddonley/mydesktop.png“>
Note, on my bar, there is apps from Gnome and KDE, even one for GKTpod, which does look out of place as the icon has been streched by the bar, it does look a little blurry, not really noticable unless pointed out
Edited 2009-02-14 07:55 UTC
Err… So where is the Menu bar?
How does a dock replace a global menu bar?
Put it on top perhaps? Sorry, can’t resist.
I’m not sure if you got the point of a global menubar. It’s each application’s menubar anchored in the same location on top of the screen. Like Mac OS.
From the article itself, the original post was replaced with this one….
http://ubuntuforums.org/showthread.php?t=241868
Whick is clearly a Dock style applet
Or maybe I didn’t get the point, lack of sleep etc lol
Edited 2009-02-14 09:30 UTC
…?
The GNOME global menubar applet is an…. Applet. It goes into your GNOME panel. Docks have nothing to do with this.
I know lol, but like I said, lack of sleep combined with getting the wrong idea of the screenshots…..
Anyway, I now know what you are all on about, and I actually disagree.
I prefer the simple clean menus in Gnome, and if I need to stick stuff in there, I will use Alacarte.
I don’t want other people deciding what goes where in my menus.
KDE menus become a mess after a while.
What part of “optional GNOME panel applet” don’t you understand?
Anyway, I now know what you are all on about, and I actually disagree.
I prefer the simple clean menus in Gnome, and if I need to stick stuff in there, I will use Alacarte.
I don’t want other people deciding what goes where in my menus.
Sorry, you’re still talking about the wrong thing
We are talking about the menus in every application, like “File”, “Edit”, “Bookmarks” etc. Not the menu with launchers for your favorites. We also aren’t talking about editing the contents of those menus, we are talking about where the menu should be visible; inside the application window, or on the GNOME panel.
The point of those screenshots is not the dock at the bottom but the menu at the top.
Edited 2009-02-14 09:42 UTC
In small screens, saving space considerably improves usability. Ubuntu’s Netbook Remix gets it right using a single line on top for task switching, gnome-menu, system tray and window identification. That is two less bars than the standard gnome configuration, and I think usability is great (although it can be improved).
Putting the menu on the same line would save one further line and free even more space. It would fit fine, because as it is, the top bar in the Netbook Release is mostly taken by an almost empty tab that does the job of the window title bar.
I believe the idea of a global menu bar is not good. It is one of the things I mostly dislike on Mac OS X. What happens if I want to view the menu bar of each window currently open at the same time? I would have to activate its window in order for me to see the bar. That is so time consuming…. I would like to be able to see the menu bar for each program/window at the same time.
Not just that but by copying Apple you are just asking for trouble. Knowing Apple’s litigation past, Apple will threaten and take action against you. I am surprised they haven’t said anything about the previous KDE versions because they had an option for this. I guess it’s because it’s not enabled by default.
Also I would like to add, Linux users are lucky Microsoft has not complained about the taskbar so far but Apple is not Microsoft so my advice is forget about the global menu bar and spend your effort into consistency and efficiency of the current shaky desktop and improving the borken applications.
Edited 2009-02-14 10:46 UTC
And you want to see the menubar because you want to do something with an app. Switching to that app is no more time consuming than hunting for its attached menubar.
Why would you want to see the menu bar of an inactive application?
You can’t select anything there. separate menu bars just waste screen real estate, and are a distraction. Especially if you look at the new netbooks, a global menu bar make so much more sense.
I will agree that many users are used to the Windows way of things, that a global menu bar does need to be an option, so they can select whatever they are most comfortable with.
Sure I can select a menu item from an inactive window. Doing so makes that window active and opens the menu in a single click.
I could see why people prefer either way. Fitt’s law says the top menu bar is easier to click, but if you’re not maximized I think it saves time not having to go up to the top of the screen all the time.
maweaver, you obviously like having a menu bar in each window, which is fine, but I think there should absolutely be the option to either enable or disable a global menu bar based on user preferences, and I think it should be part of the standard Gnome system.
We can argue all year long about which one is better, but in the end, who cares. I like global menu bars, some don’t. Thats why there needs to be an option to enable it.
This people like me who love a global menu bar can use a system the way the like, and people like you who like individual menu bars can use a system the way you like it.
I think its a win – win situation to have this option.
I am usually use to application centric window rather than document centric window, this approach has been rather successful especially with browser where the tabs has been largely accepted as the standard for modern browser.
A global menu, also mean a change of abstraction for the windows.
One other concern is the integration with different flavour of windows manager. The configuration of most of them allow for a very clean desktop ( without even a placeholder at the top for a global menu ).
At the same time, I think that would be a good fit for the GIMP ( I would prefer an MDI interface, but that’s a matter of taste ). As windows are document centric.
But as the most used application remain the internet browser. Application centric window remain the abstraction of choice.
I’d say absolutely go ahead.
The sreeenshots look nice, and its a damed good idea.
A single menu bar makes so much sense, especially for apps that have a small window, and lots of menu items (like many of the ones I write).
I’ll post to the GNUStep list: I don’t think it should be too big of an issue to integrate this in with the GNUStep menuing system, as GNUStep menus are already separate from the main window.
I’d think there just need to be a user settable option to switch between a global and separate menu bars as many users come from Windows, and are used to have a separate menu for each window.
Instead of the global menu bar (which I think is a superb idea) being part of Gnome, could this be pushed up to the X server or window manager possibly?
If the global menu bar were part of X or the window manager, would this make it easier for non-gtk apps to use it?
The global menu has a D-Bus interface. Every non-Gtk+ app can serve it. So it is easy. They just have to do it.
Edited 2009-02-14 18:35 UTC
The global menu bar was an excellent decision for a product that was in a position to make a decision. Apple’s way forced all the functionality to be stored in an obvious place.
It’s not ideal for things that are meant to be used constantly, but rather as auxiliary and supportive to the main task (saving/switching/importing). Those of you with Al Gore’s monitor array who spend too much time tracking, your app is doing it wrong. Something like Photoshop where you might be applying lots of filters should always have palettes corresponding to such menus.
The design paradigm has the bonus of giving OS X the best hotkey support there is, because you can assign custom hotkeys to any entry in any app’s menu. Standardization can be a very good thing.
The state of interfaces in Linux is exactly what Apple’s menu bar was designed to prevent: functionality spread over non-standard controls, hidden in contextual (right-click, but on what?) menus, or laid out in multiple rows of cryptically labeled buttons. It’s a mess, and it would be naive to think any force of man could corral all the various UI designs into a standardized interface, and frankly the actual menus on systems that disfavor them to begin with probably aren’t worth the effort.
In short, if you’re saying a global menu bar is stupid in concept, you’re wrong. If you’re saying it’s stupid to try to shoehorn it into Linux, then you might be on to something.
That’s why I stopped using it myself. In addition to GTK and Qt, we also need patch in Java swing (half-done), wine, fltk, lesstif, etc, etc, and most importantly, the one-menubar-per-app design (rather than per-window), which is impossible IMHO.
It’s messy….
I’m surprised nobody here has said what seems obvious to me.
Menu bars are a crutch, only helpful for beginners. There is no need for them as a global tool, at all, anywhere.
Context menus are the most efficient option. Normally wasting no screen space at all, they only appear when summoned.
NeXT’s implementation was weird, putting the context menu outside the app window. RISC OS did it best, in the old-style Unix window manager style: press the middle mouse button & you get a menu relevant to what you’re doing now, wherever you’re pointing. Closer, even by Fitt’s law, than the screen edge – context menus require no mouse movement at all.
The context sensitive menus provided by applications in RISCOS make far more sense, especially on the limited real estate of a netbook screen, than either a Mac style menubar (which, don’t forget, was first implemented when Apple computers were only capable of running a single task at a time) or the Windows solution. Purely because they’re there only when you need them.
Besides… Does the Gnome Foundation really want to be sued by Cappuchino?
Edited 2009-02-16 23:21 UTC