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

[Neo4]

I Guess the 0.2.1 version is already on the wiki right? the problem is that I've an old version installed and if i try to install the new version nothing happens...

I've tried to remove the old version but using the synaptic mode gives me an an error...

anyone can help? thanks

[rainwoodman]

2.12.0


The second way was my suggestion too.


Maybe we could make a poll or something, different users need different things.

Btw, i tried version 3 (revision 158 i think) . Great work !!! The only serious problem that i found has to do with skinning and it's very important to solve it in order to push the patch upstream. To be more specific , the menubar should be able to inherit the panel style when it sits on the global menu applet. You can maybe make a wrapper with a different name for the panel embedded menubars, or instead of stealing the menubar and plugging it to the applet, hack gtkmenubar so that i creates a regular menubar and another one (different object with a different class name) for the applet.

[EDIT]
I lust found another bug : When i add the applet to the panel, any application i'd already opened loses its menubar (as it should) but the menubar doesn't go to the applet. In simpler terms, every app already opened when i add the global menu applet , completely looses its menubar or the menubar on the applet isn't visible. If i remove the applet though, the menubars reappears as it should.

The skinning. gtk_rc_xxx are so messy to me, but I'll try to figure it out, tonight.

It will be very difficult to duplicate panel-menu-bar, it depends on a undocumented gnome class: GMenuTree in (lib)gnome-menus. Also, the panel menus support drag and drop, which is also difficult to implement. The DnD of panel-menu-items also reminds me to find a test case where some application support dragging menu item into toolbar for defining a new toolbar button.

I also confirmed the bug this morning. I think I know where it comes: I made the menu bar hidden immediately after they are globalized to avoid it visible to user, but when the menu server picks it up, gdk_window_show seems to malfunction. Something is broken with the function calling flow. I'll go into it tonight.

[rainwoodman]

It's OK, not a distraction. We can leave the discussion in this thread and hopefully it can inspire some others' work.

Ribbon is just Office 2007, isn't it? It is a revolution! Although I can't get accustomed with it at all, I am sure the UI makes great sense.

Sugar and the Ribbon both have tabbed toolbars, where the menu and the toolbars have been fully integrated. They illustrate how putting the menu bar and toolbars together allows for some interesting innovations in the future.



You’re absolutely right. Some “application elements” definitely work better when placed with the documents. The GIMP’s rulers immediately come to mind as an example. Many web pages (not all) are a further example, as you point out. Standard toolbars, however, as far as I have seen, are nothing more than lists of shortcuts for application functions, and they almost always correspond to items in the menu. They belong more to the running application than to any particular displayed document. That is why I believe that toolbars logically do not differ from the menu bar, and, thus, belong with it.

In any case, I don’t want to distract you any further from your important work. Please continue.

[rainwoodman]

emm, would you tell me what is the difference/relation between Gnome and GnuStep?
What is the relation between GnuStep framework and freedesktop's standards?

Gnustep is not based on gtk, isn't it?

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 Etoile 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. Apt is great for the system, not so much for consumer apps, especially for Shareware/commercial vendors.
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.

[rainwoodman]

just a hint, try to remove gtk2-aqd and install gtk2 in the same run.
don't knwo if it will help.

I Guess the 0.2.1 version is already on the wiki right? the problem is that I've an old version installed and if i try to install the new version nothing happens...

I've tried to remove the old version but using the synaptic mode gives me an an error...

anyone can help? thanks

[SkiesOfAzel]

SkiesOfAzel, can you post the steps you did to have the svn working so that I can update the wiki on the Global Menu project page (the one on Google Code)

Sure :

mkdir packages
cd packages
mkdir gtk-aqd-3
cd gtk-aqd-3
apt-get source libgtk2.0-0
sudo apt-get build-dep libgtk2.0-0
sudo apt-get install fakeroot

Get the attached gtkmenubar.patch and put it inside the debian/patches folder of the gtk source you just downloaded. Open the series file found on the same folder and add a new line containing

gtkmenubar.patch

save and exit.
now on the terminal

cd gtk+2.0-2.12.0
dpkg-buildpackage -rfakeroot

That's it.

I can also provide some debs if you like.

[SkiesOfAzel]

The skinning. gtk_rc_xxx are so messy to me, but I'll try to figure it out, tonight.

The problem is simple really. The class name and path of the menubar doesn't change when the menubar is plugged to the applet (the path stays the same probably because the gtkmenubar isn't really a part of the applet but it is just plugged there). We need something to different the 2 states of the menubar through class name or path.

It will be very difficult to duplicate panel-menu-bar, it depends on a undocumented gnome class: GMenuTree in (lib)gnome-menus. Also, the panel menus support drag and drop, which is also difficult to implement. The DnD of panel-menu-items also reminds me to find a test case where some application support dragging menu item into toolbar for defining a new toolbar button.

You don't need to duplicate panel-menu-bar (at least i don't think so ), just hack the global menu into it. Add the global menu into the same Gtkbox and you just need to hide the menu bar when it's not supposed to show up.

[rainwoodman]

The problem is simple really. The class name and path of the menubar doesn't change when the menubar is plugged to the applet (the path stays the same probably because the gtkmenubar isn't really a part of the applet but it is just plugged there). We need something to different the 2 states of the menubar through class name or path.

You are at some point right. But actually neither of them owns the menubar in the very fundamental languages. My understanding is that, the window of the menubar (float_window) lives in X, whereas two processes, menu-client and menu-server both have access to it(handle the events, set window properties, eg, position, size) via GDK.
The client creates the Xwindow with gdk_window_new(GDK_WINDOW_TEMP), the server wraps the Xwindow with gdk_window_foreign_new (GDK_WINDOW_FOREIGN). On the server side, the GdkWindow is not associated with any widget, and thus no signal is emitted upon Xevents' arrival. On the client side, the float_window is associated with the menubar widget, and event's of the float_window is propagated to the menubar widget. In that sense, the float_window is owned by the menu-client.(or application, in your context)

In order to judge this shared resource(kinda of a competition), we need to introduce a way to communicate between menu-client and menu-server, and that protocol is based on GlobalMenuSocket, which create one GDK_INPUT_ONLY window for each socket and pass messages on top of XClientMessage.


How to set the class name and path of the menubar? The owner process gets an notification when a menuserver starts, and prepare the menubar to be globalized. So if we want to change the class name and path, we'd better do it at this stage.

There is a seconde place to do that. The function of gtk_menu_bar_ensure_style when ever the menu bar widget request its widget->style. In current(svn 158?) that function simply pass the request to gtk_widget_ensure_style and make a few adjustments if the menubar is globalized. perhaps I should go into the source of gtk_widget_ensure_style and get some inspirations.

You don't need to duplicate panel-menu-bar (at least i don't think so ), just hack the global menu into it. Add the global menu into the same Gtkbox and you just need to hide the menu bar when it's not supposed to show up.

So I'll need to create a widget, global-menu-server-widget, and merge it into gnome-panel's source.

[SkiesOfAzel]

You are at some point right. But actually neither of them owns the menubar in the very fundamental languages. My understanding is that, the window of the menubar (float_window) lives in X, whereas two processes, menu-client and menu-server both have access to it(handle the events, set window properties, eg, position, size) via GDK.
The client creates the Xwindow with gdk_window_new(GDK_WINDOW_TEMP), the server wraps the Xwindow with gdk_window_foreign_new (GDK_WINDOW_FOREIGN). On the server side, the GdkWindow is not associated with any widget, and thus no signal is emitted upon Xevents' arrival. On the client side, the float_window is associated with the menubar widget, and event's of the float_window is propagated to the menubar widget. In that sense, the float_window is owned by the menu-client.(or application, in your context)

In order to judge this shared resource(kinda of a competition), we need to introduce a way to communicate between menu-client and menu-server, and that protocol is based on GlobalMenuSocket, which create one GDK_INPUT_ONLY window for each socket and pass messages on top of XClientMessage.


How to set the class name and path of the menubar? The owner process gets an notification when a menuserver starts, and prepare the menubar to be globalized. So if we want to change the class name and path, we'd better do it at this stage.

There is a seconde place to do that. The function of gtk_menu_bar_ensure_style when ever the menu bar widget request its widget->style. In current(svn 158?) that function simply pass the request to gtk_widget_ensure_style and make a few adjustments if the menubar is globalized. perhaps I should go into the source of gtk_widget_ensure_style and get some inspirations.

Thank you for a very informative post.
When you want to skin the same widget with a different style there are 2 ways to do it. The first is to wrap the object (struct) inside another, effectively changing its name , the second, skinning by absolute path is as you said unusable.

So maybe you can make a wrapper that gets the GtkMenuBar inside it when the menuserver starts. The name of that wrapper should be enough to skin it.

gtk_widget_ensure_style is useless and changing it would be a pain imo. Maybe you could use gtk_widget_get_style to get the panel_menu_bar style and gtk_widget_set_style to apply it to the menubars .

[EDIT] I've also noticed that when you change the current theme, the menubar doesn't get refreshed (it keeps using the previously assigned style) .
[EDIT2] Try nautilus or thunar with the clearlooks theme, you will notice that the menubar isn't properly skinned. It has probably something to do with the fact that both of these programs use wrappers for most of their widgets (i will dl the source and have a look for custom menubars just to be sure).

[Dawudd]

It's OK, not a distraction. We can leave the discussion in this thread and hopefully it can inspire some others' work.

Ribbon is just Office 2007, isn't it? It is a revolution! Although I can't get accustomed with it at all, I am sure the UI makes great sense.

I haven’t used it myself. From what I can see, OLPC’s Sugar is more clever in some regards, since it inverts the tabbed toolbars, thus taking advantage of Fitts’ Law. However, putting the toolbars on top of the menu bar seems even more logistically difficult within GNOME.

And thanks. I do hope these ideas can serve as inspiration to someone.