Re: Bonobo -> Gtk toolbar ...

Michael Meeks <michael ximian com> writes:

> 	I'd greatly appreciate you taking a look at some of the hacks in what
> I've done to libbonoboui to try to get it to use the new toolbar. If you
> checkout the 'toolbar-rework' branch, that shows the problems well. The
> best test for seeing it in action is tests/test-ui.
> 	There are 2 really evil things:
> 		* bonobo/bonobo-ui-internal-toolbar.c - what we have
> 		  to do to get the true size wrt. arrows

Your basic problem here is that you are hacking a feature in, that
gtk+ and GtkToolbar quite simply don't have. You should _expect_ the
result to be evil.

As far as I can see, what you have now is going to queue a resize out
of a size_allocate(), because set_show_arrow() queues a resize, and
get_full_size() will typically be called out of a
size_allocate(). That is just not going to work reliably.

Your best bet might be some cut-and-paste action from
gtk_toolbar_size_request() along with gtk_container_list_children().
If you apply the assumptions "new API" and "!show_arrow" to the code,
it isn't actually that terrible.

> 		* bonobo/bonobo-ui-toolbar-control-item.c - not being
> 		  able to detect when a popup menu is instantiated,
> 		  and having a remote control that has to be re-parented
> 		  [ possibly insoluable but ... ]

It certainly looks really evil what you are doing there.

As far as I can see (not knowing much about Bonobo) the problem is
that there is no way to ask a BonoboControl to generate a menu item,
so you are just taking its local proxy widget and putting that into a
menu item.

Some suggestions:

        - If BonoboControls have a name that can be displayed to the
          user, just use that as the label of the proxy item.

        - Give up, and just don't create a proxy menu item for the
          control. Not optimal, perhaps, but

                - It does work with buttons (as far as I can tell)

                - Non-buttons are less important as menu items

                - The user can still resize the toolbar to get the

But if you insist on reparenting, then you should certainly not
connect to the "destroy" signal of the menu item, because the toolbar
is not going to destroy the menu items. A better strategy might be to
extend the ::map method of the toolitem to reparent the control back,
with the idea is the tool item and the menu item are not going to both
mapped at the same time.

> 	Input appreciated,

I am not sure why you are trying to move libbonoboui to GtkToolbar in
the first place. You mentioned keyboard navigation, but if that's the
only reason, then just fixing BonoboUIToolbar seems like a much easier

The GtkToolbar keyboard navigation is completely straight forward --
it doesn't use any hacks or internal feature of gtk; in 2.4 a
GtkButton has the property "focus-on-click" which can be turned off to
prevent buttons from grabbing the focus when you click them.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]