Re: More Canvas Item and UI comments

[Michael Meeks <michael helixcode com>]

Hi Mike,

On Sun, 10 Dec 2000, Mike Kestner wrote:
> Are there plans to make a stable branch?  I'll make these changes when
> there is a 2.0 branch available.

        Yes there are plans to make a stable branch, in due course, all
things being precipitate and in the fullness of time.

> 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?
         
        No thoughts currently. It seems to me that the canvas is a total
slave to the container though, which is responsible for 'activating' it   
etc. so we should be able to get away with adding a setUIContainer /
getUIContainer pair on the canvas interface I imagine.

> 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;

        You probably don't want to do this; you probably want to connect a
state-full event listener to the toggle, this will pass you the state as 
it changes:
           
        bonobo_ui_component_add_listener (uic, "MyVerbName", my_cb,
                                          user_data);

...

static void
my_cb (BonoboUIComponent           *component,
       const char                  *path,
       Bonobo_UIComponent_EventType type,
       const char                  *state,
       gpointer                     user_data)
{
        gboolean show;
  
        if (type != Bonobo_UIComponent_STATE_CHANGED)
                return;

        show = atoi (state);

        ...
}

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

        Whilst you can do it like this it's considerably more ugly, I  
would suggest instead reacting to user state changes. Also, if you are
going to do it like this, you can do it thus:

        if ((state = bonobo_ui_component_get_prop (uic,
                    "/commands/MyVerbName", "state", NULL)) {
                if (atoi (state)) {
                        ...
                }
                g_free (state);
        }
        
        NB. several things, the ev is optional, the path should be that to
your verb/id for correct command / widget separation. All in all I don't
think this is drasticaly worse than the previous case; but you shouldn't
be doing it anyway :-)

        Of course, what you could do is follow the route some others have
taken of creating another layer of helper wrapper and showing no interest
in feeding it back into bonobo :-)

> 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.

        This was just hidden for you before; at least now you can get the
exeption if you wish, you can still be fully unsafe by passing NULL as the
ev.        
        
> While I can sense the power and capabilities of this new architecture,

        A lot of the niceness comes from the cmd / widget separation which
you should be using, please see bonobo/doc/ui-faq.txt:

* What does this cmd / widget separation really mean ?
       
        You should probably also read the section on porting an app to
the new UI handler code at the top. It's probably very much worthwhile
basing your ui xml description on that in bonobo/doc/std-ui.xml if you
havn't noticed that.
       
        Regards,
  
                Michael.

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