More Canvas Item and UI comments

[Mike Kestner <mkestner ameritech net>]

Michael Meeks wrote:
 
>         Sorry for the delay, I got distracted. Just committed the fix. The
> idea sounds most reasonable for Bonobo 2.0, although interface versioning
> is apparently not something that works at all.

Are there plans to make a stable branch?  I'll make these changes when
there is a 2.0 branch available.

Also, I've got some other issues with CanvasComponents.  One of the more
glaring is lack of access to a remote UIContainer.  On the view side,
this is provided through the Control--->ControlFrame interworking.  With
CanvasComponent deriving directly from BonoboObject, there is currently
no way for a CanvasComponent to merge UI elements in its container. 
Duplicating the Control code in the Canvas proxy elements seems a bit
hackish.  Any thoughts?

I'm also working on converting Achtung to the new UI handler, so I can
use it to play with my new Shape components.  I have to admit that I'm
finding it much harder to learn than the old UIH.  Am I correct in my
analysis that things like:

	if(bonobo_ui_handler_toolbar_item_get_toggle_state(uih,path))
		do magic;

Now become:

	state = bonobo_ui_component_get_prop(uic, buttonpath, "state", &ev);
	if(!strcmp(state, "1"))
		do magic;
	g_free(state);

Or am I missing the elegant solution?  If the above is accurate, I think
we've taking a significant step backwards in the
readability/intuitiveness of the API.  Once I've managed to wade through
some XML examples and create my UI elements, I now have to make the
realization that its toggle state is a readable property of a node in
the UIComponent and determine that the property name is "state" and not
"toggle" or "togglestate" or whatever other internal identification it
might have been given. Then it's on to dealing with exception reporting,
converting the property string to a boolean, and finally remembering to
release the returned prop string to avoid leaks.  

While I can sense the power and capabilities of this new architecture,
having to discover all the above just to get the toggle state of a durn
button doesn't feel like progress to me at this point in the learning
curve. :-) If a convenience API for common tasks like this already
exists, I'll attempt to remove my foot from my mouth.  If it doesn't, is
the plan to add one, or leave it as is?

Mike