zAo, I don't mean to sound stupid but - are you sure you actually installed the patched GTK?
multi-head support added to xfce plugin and gnome applet 1.0.1.
Please help me to test, because I don't have two monitors
my tiny little suggestion:
can you define a standard container for the menu?
this way all the gui toolkits may have a single point of
reference for using the menu element, and it may allow
flexibly in defining the menu gui element;
1. radial menu on shortcut key (like in neverwinter nights)
2. large icons for edit, insert, file, etc on the buttom of the
screen (for simplified applications).
3. global menu
4. per application menu.
5. menu as stacked of actions in a large round button, like in office 2007
6. little animated penguins that run away when clicked.
pseudo code example for a possible container:
// freedesktop.org menu item standard container
// 2006, bsd, copyright AqD
// Mangar_is_a_silly_alias (tm)
app_id; //i don't know if it's necessary (can be suid)
app_name; //the name of the initializing application.
app_screen; //the screen (physical / virtual) it's on
set[menu_element] menuElements; //holds the menu elements (file, edit, etc)
image; //image for the menuelement (optional)
command;// (abstarct - submenu, action, checkbox, whatever)
forums system doesn't retains tabs, sorry
It retains tabs if you use the CODE tag
- gtk2-aqd 2.10.6-4: remove a lot of code for standalone menubar, change to a model similar to that of KDE's. It will need panel plugin/applet to work properly.
- gnome-macmenu-applet 1.0.2-1, xfce4-macmenu-plugin 1.0.2-1: a lot of changes for the new menubar model.
These new packages/patches are completely incompatible with previous ones, and you must upgrade them altogether. However there isn't any user-visible change this time
The new model only provides minimal support for the standalone menubar; it's less problemic but you will be better to use a panel applet for xfce or gnome (if you haven't done so yet)
Support for KDE's mac menubars will come very soon.
from the user's point of view, you are correct, and it will
be wonderful, in the short term.
in taking a little longer view, having a standard container will
allow for all the toolkit providers to assign their menus there,
1. will lower the burden of maintaining event capturer for each
menu container type,
2. will allow support of any toolkit that supports the standard.
3. will allow for different implementation of the menu -applet,
perhaps not even in an applet form (like the examples i've given
4. allow for easier porting of software to osX (since there's a
menu container, the toolkit and the application has less to worry
BUT.. that my own, private opinion - you're the developer,
therefore, ultimate power is yours.. (and the world quakes in fear! )
i agree, though, that as proof of content, and as a short term
solution, your implementation is the best for now.
(modifying all the toolkits shouldn't be your problem)