Re: bonoboui toolbar bits ...

El vie, 01-11-2002 a las 16:45, Michael Meeks escribió:
> Hi Ricardo,
> 
> On Thu, 2002-10-31 at 14:54, Ricardo Fernández Pascual wrote:
> > I think that is working well enough using controls. And I need to use
> > controls anyway because I need context menus there.
> 
> 	Ok - as you see, I just improved the control stuff for you.
> 

Great. That will surely help us. We will have to reimplement some of our
"old" controls but this is great news. Thanks!

> >         - context menus: I want to be able to add context menus for
> >         menuitems and toolbar buttons. Using gtk+ this is very easy, but
> >         using libbonoboui you have to use a control for each toolbar
> >         item. And it can't be done for menuitems.
> 
> 	Yes; it's not clear quite how to do this; we can proxy the button click
> event I suppose, and provide you with a fake 'signal' on the
> BonoboUIComponent with a fake GdkEvent, it's not _that_ difficult, but
> more API.

Context menus are my main problem with bonoboui. What is the api that
you propose? Will it be implemented? ;)

Also note that for adding context menus for menus I have to use the
button_press event (and when porting to gtk2 I needed the event_after
signal too in order to make it behave correctly). I don't know how would
this fit in the API.


> >         - being able to know what button the user uses to click a
> >         menuitem/toolbaritem. In galeon 1, we opened things in new
> >         windows/tabs depending of the button used. It added consistency
> >         to the interface and was a very useful feature, IMO. I
> >         understand that this may not fit very well in the bonoboui
> >         design and philosophy... maybe being able to add different verbs
> >         depending of the button?
> 
> 	Ok - that's certainly possible; again it needs a little work, but it's
> essentially quite easy to do I think. It'd be great if you could do the
> work here; what I think we want is something like:
> 
> 	verb_[N]="SomeOtherVerb" attributes on the item.
> 
> 	where the 'N' is mouse-button mask you want to match against; how does
> that sound ? should be pretty trivial, also you can add those verbs, and
> it'll work nicely in 2.2 and not complain in 2.0.

That would be enough for most things. 

> 
> >         - In general, creating dynamic menus (like bookmarks,
> >         history...) using libbonoboui is a pain. Building XML on the fly
> >         to immediately parse it looks  wrong to me. I would love to be
> >         able to mix bonoboui menus (for general menus of the
> >         application) and standard gtk+ menus (for dynamic things). That
> >         would solve all my problems with libbonoboui (at least all the
> >         important ones ;-) ).
> 
> 	:-) Ok; so there are a lot of tips here; and some room for improvement.
> I believe we currently create all the widgets on the fly whether they
> are seen or not, which is rather painful. We can do better than that in
> libbonoboui.
> 
> 	Far more crucially, are you doing a:
> 
> 	bonobo_ui_component_freeze
> 	... umpteen operations ...
> 	bonobo_ui_component_thaw
> 
> 	If not, I can believe that performance is dire ;-) it's re-building the
> GUI after every round-trip.
> 

I think I'm not doing it. I'll look.

> 	Another thing you can do that can markedly improve performance is
> building the entire menu, and then merging it all at once; ie. maintain
> your client side bookmark menu copy as BonoboUINodes, then merge it all
> in 1 shot.
> 

Yes, we already do this for the "Encodings" menu.  I should do the same
for bookmarks.

But my point is that having to build XML for building a menu is a pain,
even if it could be done efficiently. It's good for the apps interface
because you keep it in a separate file and it's clean. But building the
XML from C is messy.



-- 
Ricardo Fernández Pascual
[email protected]
Murcia. España.



-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com