Re: EggMenu

[James Henstridge <james daa com au>]

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