Re: gnome-ui-handler

[Nat Friedman <nat nat org>]

Hi Elliot,

	I hope you don't mind, but I've CC'd this to the list.

Elliot Lee <sopwith@redhat.com> wrote:
> OK, I got around to looking at gnome-ui-handler, although I think I
> deleted your original RFC post.

	Ok, I've forwarded you the original post.  Please read that
first.

> At least one of your reasons for ditching GnomeUIInfo is incorrect.
> 
> "1. My structure lets you set per-item callback closures."
> 
> You can do this with GnomeUIInfo already - the create_with_data() routine
> just overrides the 'data' element in the structures.

	True.

> "2. I support Havoc's dynamic list idea."
> 
> If I gather correctly, this is so you can do dynamic menu items easily. We
> should be able to do this in GnomeUIInfo without any problems.

	Naturally, you can modify menus at runtime using GnomeUIInfo,
but that's a superset of what Havoc was talking about.  Havoc proposed
that it would be useful to have a very nice, easy way to generate
dynamic menus which act sort of like a ring buffer.  So a dynlist
would be a region of a menu with a maximum size onto which you could
push menu items.  The old items would pop off the bottom.  So adding
an item to a 'recently visited documents' list would be as easy as:

	gnome_ui_handler_menu_dynlist_prepend_item (uih, dynlist, item);

And the developer wouldn't have to manage the list manually.  I think
it's a nice idea.

> "3. I keep the fully-qualified path to the UI item in the structure."
> 
> Do you have any examples of where this is needed? It may be that we can
> get the needed hooks into GnomeUIInfo.

	The idea of a path is that you always have access to the
unique identifier which is used to refer to a menu/toolbar item.  This
is especially important since now, with Bonobo, menu/toolbar items
will be referenced and manipulated across process boundaries.  And
additionally, an application will need a way to refer to menu items
which it did not create.  So, for example, it may need to add an item
to the "Edit/" subtree.  The path provides it with a unique way of
identifying the "Edit/" subtree.  I don't know how to do this without
adding such a field to the structure, or forcing the application
developer to maintain a GnomeUIInfo <--> path association himself.

> Anyways, I guess I'm not very familiar with your setup, but it does look
> like a lot more function calls to me than with GnomeUIInfo. The whole
> point of GnomeUIInfo was to make doing the common tasks easier on the
> programmer (like, gnome_app_create_menus() and everything just works :-)

	Just because I provide a lot of class methods doesn't mean
that you have to use them.  I do provide gnome_ui_handler_menu_add (),
which will recursively add GnomeUIHandlerMenuItem menu items just like
gnome_app_create_menus.  The extra class methods are just for
convenience, so that you don't have to manipulate a structure to
modify the state of a menu item if you don't want to.

	So for example, right now, if you want to change the
sensitivity of a menu item (to grey it out, for example), you have to
find the GnomeUIInfo structure which refers to the menu item and
manipulate the actual uiinfo->widget.  With my proposed stuff, you
just do:

	gnome_ui_handler_menu_set_sensitivity (uih, path_to_item, FALSE);

This is actually necessary since you aren't guaranteed that you will
actually have access to the GtkMenuItem widget, if, for example, you
are in another process.

	So I would argue that having more class methods actually makes
the programmer's job easier.  Nothing is forcing him to actually use
all of those methods, but they are there if he needs them.

	I am not trying to evangelize my proposal at all; as I said, I
think it would be nice if I could find a way to stick with
GnomeUIInfo.  So I'm just explaining the choices I made.

> Another thing that isn't so much a problem with the current
> gnome-app-helper interface as with the implementation - for stock
> menu items, it should use a shortcut key combo set in the control
> panel, instead of using the one set in the GnomeUIInfo structure.

	Ok, what do you think about using gnome_config to map standard
menu/toolbar item paths to default shortcut key combos?

> As for localization, I didn't know there were any actual problems with the
> current setup - what are they?

	The problem is that I need a unique language-independent way
to address menu/toolbar items.  My idea was to use the untranslated
gettext () keys for the menu/toolbar labels, concatenated into a
menu/toolbar item "path", like this:

	"File/Quit"[1]

So whatever menu system we end up using does need a way to provide the
user with:

	1. The standard menu labels such as _("File")
	2. The untranslated menu labels ("File") which can be used as
           path components.

> (I gathered all this from reading the header file. If you addressed these
> issues in your post, apologies.)

	Some of these issues will probably be clearer if you read
that.

Nat

[1] With a different delimiter, as I said in my post.  Or with a
GList, as Miguel suggested.