Linked by Thom Holwerda on Thu 17th May 2007 18:54 UTC
Gnome In the GNOME bugzilla, there is an ongoing discussion about whether or not to include a patch into the default GNOME installation which would enable GNOME to (optionally) have a global application menubar, similar to that of the Mac OS and KDE (in the latter it is optional and off by default). Installation instructions and .deb packages, as well as a 60-page (and counting) discussion of the patch, are available on the UbuntuForums. Read on for a poll on this issue.
Permalink for comment 241334
To read all comments associated with this story, please click here.
comments
by elanthis on Thu 17th May 2007 23:00 UTC
elanthis
Member since:
2007-02-17

The question you should be asking is this: "why not?"


Because it breaks tons of apps. Any app that was designed without this in mind, such as the GIMP, becomes very difficult to use with this patch.

Firefox and OOo don't support it.

On a bigger monitor, it's more of a pain to use. The eye and mouse both have to travel further to get to the menu bar.

KDE manages fairly fine with it. GNOME+this patch as well, especially taking into account this patch is done and maintained by one single guy.


Except that it still won't work right. First, KDE and GNOME use different method of pulling this off. You won't be able to mix-n-match KDE and GTK apps using this patch seemlessly like you would expect. And it still doesn't help Firefox, OOo, and any other non-GTK/non-QT app out there.
The patch doesn't even work flawlessly, nor will it ever given its approach. It is based on reparenting the menubar, which is about as hacky as you can get, and the author notes that a number of a pure GTK apps don't work correctly with this.

You're absolutely right. The reason is simple: I find it to be a UI enhancement.


Which is irrelevant, really. You could very well be a small minority (and I do NOT take the number of posts on a forum to be a sign of majority - 50 people posting on forums doesn't mean crap when there are 1,000s of people silently reading the forums and 100,000s more who don't use the forums at all). Despite the average user's ego, your opinion is really quite meaningless, unless you represent a large enough user base - adding features, code, and complexity (especially in terms of how hacky this patch is) for a handful of users is just bad, bad product management, Open Source or not.

Trying to tack global menus onto a system where the applications are fundamentally designed around a menu-per-window basis is a flawed approach.


Ding.

People, read the actual bug report thread. This is brought up. It's not just a matter of tossing menus to the top. The whole desktop needs to be redesigned with this in mind, or it just won't work. It'll be a neat novelty at best, really useful only to a handful of people who only ever use the GTK apps that actually work with this patch.

Just like on KDE, how only KDE apps can use the top menubar, and every other app is left not only looking different, but completely breaking the desktop design the user wants to use. That renders the feature almost useless.

If some of us like something, it is enough to be respected.


Sure. Doesn't mean that the project should be required to maintain a bunch of hackish code to add an obviously contested feature merely for the sake of "some people like it." Especially not when there are so many things broken with the patch in question.

Different Approach

A different approach is mentione din the bug report for this patch, and I think it's clear that, if such a feature is to be added, it is the only way to get it done - this patch IS NOT satisfactory, at all.

The way this patch works is by reparenting the GTK menubar. In laymans terms, it kind of cut-n-pastes the menubar from the window to the top of the screen. This has a number of problems:

(a) It only works for GTK+
(b) It only works for _some_ GTK+ apps, because some use slightly different window layouts that makes the patch fail
(c) It can't alter the content of the menu in ways that make sense in this case, such as making the menu follow the panel's background settings.

The alternate approach mentione din the bug report is to make the applet for this feature a DBUS service. Then, GTK+ can attempt to create the menu using the DBUS service (as an implementation detail of GTKUIManager), and create the menu locally if this fails. As GTK would then have explicit knowledge over which type of menu is in use, it can also alter the menu contents in appropriate ways for the different styles.

Second, this approach makes it possible for any non-GTK app to perfectly fit in. The apps would still require modification, but it would make it possible to be compatible with the GNOME applet (or possible for a different service to be used, like KDE's top menubar). KDE could add the DBUS support to their menu system, as could XFCE, ROX, GNUStep, etc. Then - and only then - could all toolkits that support this feature actually work together seemlessly. Firefox and OOo would (eventually) get support and fit it, too, and they wouldn't need a different implementation for each desktop.

This patch is a hack, and one that doesn't even work that well by the author's own words (though he doesn't phrase it quite that way - he just lists all the pure GTK apps that the patch fails to work on). The alternative approach is more solid, more interoperable, and more likely to actually be accepted.

As a closing remark, I think the poll on this article is silly. I'd vote NO because, while I'm not against the feature, I'm against having it as an option. It makes no sense as an option. To get the OS X experience out of this, you have to actually design the desktop and your apps to fit in with it. Either do it and do it 100%, or don't do it at all. Adding an option to switch between two different half-working designs is entirely pointless.

Reply Score: 5