Re: New menu ideas

[Michael Meeks <michael ximian com>]

Hi James,

	So sadly I forgot most of the things I meant to say to you about
merging; so here's 1 facet that I forgot, and a reply:

	Oh, and just so it's archived we need an intelligent scheme for
handling pixmaps - so that pixmaps can be set remotely; and that we can
associate various sizes / roles of pixmap to an 'Action' for different
situations, particularly menu vs. toolbar.

On Wed, 2002-03-27 at 14:57, James Henstridge wrote:
> In the proof of concept code I did (before even looking at menu merge), 
> I ended up using togglebuttons/checkmenuitems for radio actions

	Good - the current code is just dire for what we want. Mercifully the
new API will (should) entirely hide the implementation details, so it's
trivial to add some new private widgets that render it all nicely as
expected.

>  The lookup function could be changed into a virtual function.  Bonobo 
> could derive a new ActionGroup type, that could query a remote CORBA 
> object and construct proxy Action objects (these could be cached in the 
> hash table, so the CORBA lookup would act as a fallback).

	Sounds fine.

> I am not quite sure what you mean by symbolic links here.  Could you 
> ellaborate?  The placeholder ideas in bonobo don't seem that bad to me 
> (once I worked out what you were on about -- maybe a different name 
> would be more appropriate).  It seems like quite a clean approach to 
> merging entries into a particular positions in a container.

	The problem with placeholders - as discussed is that they make menu
editing hard / ugly. Then again the whole merging thing makes ordering
somewhat difficult.

> Does bonobo create menu items for node positions that have been shadowed 
> by other UI descriptions?  My plan was to only create one proxy widget 
> per node, and disconnecting/reconnecting it (if necessary) when 
> adding/removing UI descriptions from the merged UI.

	Bonobo doesn't create GtkWidgets for nodes that have been 'overridden'
in my terminology - ie, the nodes are from a different component and
overlay the existing nodes. In fact this would be highly wasteful - what
we do is, instead of destroying the widget and re-building it, we
(often) move the widget and associate it with the newly merged node -
this dramatically improves efficiency and reduces flicker when compound
merges are done.

	Notably, it's important that strange merge orders work - eg. in
evolution when we switch component, we merge the new UI in, and then
remove the old one - precicely because then the widgets are transfered,
resulting in no flicker as we re-build the menus / toolbars.


	Finally - the idea I had was this; it's hard in the current bonobo
world to avoid doing redundant sets, which are not at all desirable to
anyone. This is since it is not (currently) possible to cache state
information at the client.

	This is a consequence of the merge rule that says "the latest guy to
merge to this path 'wins' in the stacking order of overridden nodes". (
so it would be possible to emit a load of signals when nodes were
overridden etc. but this would be even worse performance wise I guess -
and introduce nice races ;-).

	So - I think the merge order should be determined by a more global
'priority' setting [ perhaps combined with a special 'invisible'
priority ? ]. This would mean that when someone does a set, it doesn't
affect the merge order, merely the attributes on that particular node (
whether it is visible or not ).

	This would mean that we could aggressively cache information at the
client side (in the out of proc case) mainly to avoid redundant sets. [
clearly we'd want a mapping to the same Gtk+ API at the client side
anyway to make it yet more transparent ].

	Does that make sense ?

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot