Re: panel bonoboui stuff

[Michael Meeks <michael ximian com>]

Hi there Mark,   

On Mon, 12 Nov 2001, Mark McLoughlin wrote:
>       Uggh, my poor little head is still coming slowly around to this   
> stuff :-)

        Heh :-)

>       I've got a first cut at doing the popup menus for applets.
> Unfortunately though, it needs the menu-sync headers installed. Is
> that a problem?

        Um; no - not if we can expose a sensible API to construct a
synchronizer; not convinced installing the full header is ideal, but we'll
see ... :-) It's quite possible we can come up with a nice convenience API
that will hide a lot of this stuff ...

>       I know, the solution for that is for the panel to be a
> bonobo-window - but I don't think that's practical, or is it?
        
        No you're right - it's totaly the wrong solution.

>       Anyway, I've dumped up a tarball[1] of this if you fancy having
> a look at it
>
>       http://www.skynet.ie/~mark/pub/bonoboui-tests-0.1.0.tar.gz
  
        Ok - I read it over; there are a few things:
 
        * You get a warning:
        
                ... excess widgets at end of container ...

                This is because you're shoving your own widgets into the
        popup - you need to use a local BonoboUIComponent to do that
        properly.
        
        * You did it backwards I think :-)

                We tried it this way in some placs, but it doesn't work
        all that well; in fact it's horribly broken; it is not feasible
        for the ControlFrame side to be snooping all the mouse presses
        ( and keystrokes - accessibility ) that might popup a context
        window; indeed it's not at all a good idea I think.

                Problem is we need some more CORBA signaling to do it
        right - as I outlined in my last mail.


        So ... what we want is:
Control                                 Frame

gets mouse event,
decides if it wants to popup
create GtkMenu
attach it to it's own local UIContainer
Popup ...

Verbs -> Control                        or Frame.


        So ... the question is; how does the Frame populate the child's
popup menu - or put another way; how can it get a handle to the Control's
Popup UIContainer - I think we should put this on the 'Control' interface;
since it's a common thing we want to do; and on-demand create a
UIContainer there so it's not inefficient.

        Quite possibly the Frame should merge into some defined paths
there eg.

        /popups/button1
        /popups/button2
        /popups/button3

        Or somesuch - to make it somewhat easier to deal with the
signaling; then it can just merge when it wants to / enable / disable
items as it pleases with no hassles, and the Control side doesn't need to
worry about it all.

        What do you think ?

        I think we could get away with:

        interface Control {
                UIContainer getPopupContainer ();
        };
                
        And while you're there can we rename ControlFrame's
Bonobo::Unknown, getUIHandler to Bonobo::UIContainer getUIContainer ? to
make it descriptive ?
        
        For the Control side API I think we should have:
        
        BonoboUIContainer *bonobo_control_get_popup_container (control);
        BonoboUIComponent *bonobo_control_get_popup_component (control);
        void bonobo_control_do_popup (
                BonoboControl *control,
                guint          button, /* to make the path */
                guint32        activate_time);

        What do you think ? simple and very valuable I think ...
        
        So ... can you hack that up; or shall I - it'll only take a few
minutes I should thing; and it avoids exposing the Synchronizer, and makes
the API easier to use I think. Let me know if you're not confidant and
I'll do it.
 
        Regards,

		Michael.

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