Re: EggMenu



Ettore Perazzoli wrote:

   * concept of Action objects.  An action combines menu label, icon,
     tooltip, toolbar label, callback, etc.  Any number of proxy menu
     items and toolbar buttons can be created for an action, which
     reflect the state of the action (ie. if you change the label or
     keybinding for an action, all proxies reflect that change
     automatically).  There are special action types for toggle actions
     and actions that are part of a radio group.

I don't like the way the callback data gets passed in an array of
EggActionEntries.  When that happens, it's always annoying (as it often
means that you have to fill in the array with data that you only have at
runtime, and that sucks.)

None of the APIs are set in stone. The egg_action_group_add_entries() function is simply a C convenience function. It simply creates the EggActions, connects a callback to the action's "activate" signal, adds an entry to the accel map and adds the action to the action group. Anders also pointed out that this would be desirable, so I will look at it.


Rather, I would just have a single piece of data that gets passed to all
the callbacks.  Like

	void egg_action_group_add_entries (EggActionGroup *group,
					   const EggActionGroupEntry *entries,
					   int num_entries,
					   void *data);

Maybe entry-specific data is still useful (for using just one callback
for multiple operations of the same kind), but you really want the
global closure pointer.

   * Menu/toolbar descriptions defined in XML files.  The format is a
     subset of the bonobo UI XML format.  Keybindings are not handled
     in the XML, but instead use the GTK accel map, and menu labels,etc
     are taken from the action objects.  In fact, no user visible
     strings are included in the XML file.

I am not sure how I feel about these.  The nice thing about the original
Bonobo UI handler is that the UI designer can tweak the menus without
touching the code at all...

The designers can tweak menu item placement just as easily when the strings are not in the XML. Of course, even when the strings are in the XML, changing the menu labels is not so straight forward, due to coordination with translators, etc.


On the other hand, the Bonobo UI handler XML files have never been very
nice to deal with.  (Especially because I always found the way paths
work kinda confusing and undocumented.)

Putting all the icons and text in the action objects has a number of benefits. It means that the programmer doesn't need to worry about what the menus and toolbars look like in order to eg. change the menu label for an action, disable an action, etc.


   * Ability to merge multiple XML user interface files together (with
     support for placeholders).  I haven't implemented the toolbar
     handling in the merge code yet though.

One thing that we should keep in mind is that, in the end, the layout of
the toolbars should be user-tweakable.  Does the current design allow
for that?
Not much work has been done on in place toolbar editing, but it would certainly be possible to unload a UI file describing the toolbars, generate a new UI file for the toolbars and readd the toolbars to the UI. I have not designed a user interface for doing anything like this though.

Since all the icons, labels, etc are stored with the actions, toolbar customisation would simply consist of arranging actions on the toolbar.

James.

--
Email: james daa com au              | Linux.conf.au 2003 Call for Papers out
WWW:   http://www.daa.com.au/~james/ |   http://conf.linux.org.au/cfp.html







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]