Mac-style Menu Bar for GTK and Java/Swing applications!

[sicofante]

you may want to read the orignal bug posted by adq.

Thanks!

[l.duesing]

Hmm, I'm browsing like dead through over 90 Pages searching for current patches and the applet, all links are dead I found so far.
gtk-patches could be found in http://bugzilla.gnome.org/show_bug.cgi?id=353076
as far as I found out.
Applet Sources are not found so far - any hints?

[gdaman]

I patched several times gtk+-2.10.14 on Feisty x64, but no result for me.
It might be because 2.10.14 version, anyone suggest 2.10.x version that worked with the patch on Feisty x64.
It would be really nice if anyone could post x64 debs, patched files or something that works for sure

cheers

[kenchuamy@gmail.com]

hi everyone,

recently i was successful installed avant window navigator after reading some forum, but it seem the awn(dock) seem to have black bar. unable to solve, can anyone face this before......very new to awn, attract to osx dock. thanks a lot.

[nikoPSK]

requires compiz/ beryl or some window composting program. Please watch where you post. This is the mac menu bar thread not the AWN thread. http://ubuntuforums.org/showthread.php?t=385981&page=90
Here you are.

Also this is explained on the guide. Search awn or avant or something before you go asking on a random thread.

[Dawudd]

If I remember correctly, in the IXDA discussion someone points out that coming back from the menu to the application window should be taken into account too. While the menu bar at the top has infinite height and mouse acceleration makes it easy to reach it, any other targets in the application (icons in tool bars, for instance) are just ordinary targets and become "far targets" when coming back from the menu bar if the monitor is big, the application is not covering the whole screen and the tool bars or tool pallettes are floating somewhere far from the top.

That’s a good point. So, how much time is spent on the return trip? Well, that depends on the return distance and the target size (D and S, respectively, in Fitts’ Law). I would posit that this D is, on average, much smaller, considering that one often leaves the cursor alone right after using the menu. The new S, on the other hand, is, on average, much bigger, considering that it is often the size of the whole document being viewed. What about the worse-case scenario, where the return trip is just as long and the destination is just as small? Again, using Jef Raskin’s numbers in The Humane Interface, the return trip is actually identical for both interfaces! Thus, overall, the Macintosh menu is still more efficient. How small would the average distance to the menu bar have to be on a Windows system to equal a Macintosh menu’s speed? It would need to be 28 mm, about a third of the distance. This is all for a 14-inch display. On larger displays, however, D actually grows (for both types of menus).

In case someone is actually trying to follow the mathematics, Raskin’s determination for a and b in Fitts’ Law are 50 and 150, respectively.

OFF TOPIC: For those interested in user interaction design in open source software, I found a very interesing article yesterday: http://humanized.com/weblog/2007/10/05/make_oss_humane/
(If you feel like chatting about it, maybe we should open a new thread.)

One of the founders, Aza Raskin, is Jef Raskin’s son. I would also highly recommend the site and its weblog.

The Patent is owned by IBM until 2016.

The fact that this was filed by IBM in 1996, rather than by Apple in the 1980’s, should tip you off that this is not about the Macintosh-style menu bar. This patent is about having the same menu bar for all documents, using OpenDoc, rather than having the same location for each application’s different menu bar. In fact, the patent actually refers to the Macintosh menu in explaining the differences: the Macintosh allows each application a ‘private menu bar’ in the same location, whereas this patent is for a ‘global menu bar’ for all applications.

I agree that this is hacky and it's not the right way, but I also agree that some official consideration should be made by the Gnome team. Where's the place to push for it? I'm ready for the battle (and most of all, I want to hear their "why-nots").

So would I, but I doubt we will. My impression is that these changes are being held back by apathy, rather than opposition. You might also have some luck on the GNOME Usability Project’s mailing list and IRC channel.

On a related note, one might be interested in looking at toolbars in Sugar (which is implemented in GTK+). Note the upside-down tabbed toolbars at the very top of the screen (maximizing the Fitts’ Law advantage). Interestingly, there is no reference to Microsoft’s Ribbon. Globalizing such a ‘toolbox’ for GNOME would be brilliant, in my opinion. This is yet another reason to allow toolbars to be placed at the top of the screen as well, as I have already argued.

[Frak]

The fact that this was filed by IBM in 1996, rather than by Apple in the 1980’s, should tip you off that this is not about the Macintosh-style menu bar. This patent is about having the same menu bar for all documents, using OpenDoc, rather than having the same location for each application’s different menu bar. In fact, the patent actually refers to the Macintosh menu in explaining the differences: the Macintosh allows each application a ‘private menu bar’ in the same location, whereas this patent is for a ‘global menu bar’ for all applications.

Then please show the correct patent.

I would love to be intrigued.

[sicofante]

That’s a good point. So, how much time is spent on the return trip? Well, that depends on the return distance and the target size (D and S, respectively, in Fitts’ Law). I would posit that this D is, on average, much smaller, considering that one often leaves the cursor alone right after using the menu. The new S, on the other hand, is, on average, much bigger, considering that it is often the size of the whole document being viewed. What about the worse-case scenario, where the return trip is just as long and the destination is just as small? Again, using Jef Raskin’s numbers in The Humane Interface, the return trip is actually identical for both interfaces! Thus, overall, the Macintosh menu is still more efficient. How small would the average distance to the menu bar have to be on a Windows system to equal a Macintosh menu’s speed? It would need to be 28 mm, about a third of the distance. This is all for a 14-inch display. On larger displays, however, D actually grows (for both types of menus).

I'm sorry I'm really lazy to follow the mathematics behind Fitts' Law, but I would say:

a) The return target is not really the document window (which is very big), but a specific place inside the document, such as the cursor position or a toolbar button. Doesn't that change the calculations?

b) I don't quite get that D grows equally for both menu types. Isn't precisely that distance what were talking about when we say the window menus are closer to the original position of the cursor making the return distance smaller?

One of the founders, Aza Raskin, is Jef Raskin’s son. I would also highly recommend the site and its weblog.

I also do recommend it. Aza is trying to follow his dad's latest ideas on getting back the text input interface. I'm not quite with them on this, but it's interesting nonetheless.

So would I, but I doubt we will. My impression is that these changes are being held back by apathy, rather than opposition. You might also have some luck on the GNOME Usability Project’s mailing list and IRC channel.

On a related note, one might be interested in looking at toolbars in Sugar (which is implemented in GTK+). Note the upside-down tabbed toolbars at the very top of the screen (maximizing the Fitts’ Law advantage). Interestingly, there is no reference to Microsoft’s Ribbon. Globalizing such a ‘toolbox’ for GNOME would be brilliant, in my opinion. This is yet another reason to allow toolbars to be placed at the top of the screen as well, as I have already argued.

Very interesting indeed. Well, maybe the Gnome developers suffer that terrible Not Invented Here syndrome and want to avoid copying the Mac at all costs. In that case, maybe taking ideas from the nice OLPC project (which everybody sympathizes with) can wake them up?

I've been subscribed to the Gnome Usability list for a few months now and the list is pretty dead (got some 20 messages in all these months). Maybe all the interesting discussions are held anywhere else, I guess I'll have to subscribe to all of their lists to make sure. Anyway, why don't we meet there and make the subject active? You never know...

[Dawudd]

a) The return target is not really the document window (which is very big), but a specific place inside the document, such as the cursor position or a toolbar button. Doesn't that change the calculations?

What I was saying is that often there is no return target at all (such as when the next action is using the keyboard), or it is the whole window (such as for scrolling or focusing a window). If the return target is a toolbar button, well, you already know what I think about where that should be placed. In any case, my calculations were for the worse-case scenario, where the return trip is the same as the first one and the target is as small as a menu bar.

b) I don't quite get that D grows equally for both menu types. Isn't precisely that distance what were talking about when we say the window menus are closer to the original position of the cursor making the return distance smaller?

It doesn’t grow equally. Since I have no data on the average distance to a menu bar on larger displays, I can only estimate. Remember: the trip up on a Macintosh is much quicker than on Windows, whereas the trip back on both systems will be slow. At best, on Windows it will be slightly less slow by the amount of time it takes to travel from a Macintosh menu bar to a Windows menu bar en route to the target. I find it telling that this difference averages to 0 for a 14-inch display, according to Jef Raskin.

Very interesting indeed. Well, maybe the Gnome developers suffer that terrible Not Invented Here syndrome and want to avoid copying the Mac at all costs. In that case, maybe taking ideas from the nice OLPC project (which everybody sympathizes with) can wake them up?

Let us hope so. The two sets of developers already greatly overlap.

I've been subscribed to the Gnome Usability list for a few months now and the list is pretty dead (got some 20 messages in all these months). Maybe all the interesting discussions are held anywhere else, I guess I'll have to subscribe to all of their lists to make sure. Anyway, why don't we meet there and make the subject active? You never know...

Good idea. If you post, I’ll be happy to add to the discussion. I’ve been subscribed ever since I came across ‘Mac-style menubar in GNOME’. Alas, nothing seems to have emerged from that brief discussion.

[sicofante]

What I was saying is that often there is no return target at all

Oh, I see. You're right.

It doesn’t grow equally. Since I have no data on the average distance to a menu bar on larger displays, I can only estimate. Remember: the trip up on a Macintosh is much quicker than on Windows, whereas the trip back on both systems will be slow. At best, on Windows it will be slightly less slow by the amount of time it takes to travel from a Macintosh menu bar to a Windows menu bar en route to the target. I find it telling that this difference averages to 0 for a 14-inch display, according to Jef Raskin.

I understand now. Thanks for the explanation.

The two sets of developers already greatly overlap.

Mmmh... That's good, isn't it? While the OLPC screen is fairly small (and that makes some difference), how that new interface would perform on a regular desktop might bring an interesting discussion, no? (and who knows, some consequences to our Gnome desktops). I'll check for mailing lists/forums on that development.

Good idea. If you post, I’ll be happy to add to the discussion. I’ve been subscribed ever since I came across ‘Mac-style menubar in GNOME’. Alas, nothing seems to have emerged from that brief discussion.

I'll be there in a couple of days.