Re: Bonobo requires a new toolbar widget.

[Ettore Perazzoli <ettore comm2000 it>]

Hello,

    Nat> Actually using Bonobo in real applications is making it extremely
    Nat> obvious that we need a new toolbar widget.  Ettore suggested that I
    Nat> write up a list of what I saw as the requirements for the new toolbar
    Nat> widget.  If it isn't going to take too much time, we should implement
    Nat> it.

Actually, I would like to give it a shot, as I need this for the
GtkHTML editor component as well.  (And this would also give me a nice
break from GtkHTML.  :-))

    Nat> 1. The ability to handle objects which are inserted and removed at 
    Nat> run-time.  This means it needs to relayout the toolbar whenever 
    Nat> its child count changes.

In order to make the API simple and consistent, I think we should give
a name to each of the toolbar children, just like the way GnomeDock
works.

    Nat> 2. It needs to handle the situation where there is not enough
    Nat> window space to display all the toolbar children.  Whether this 
    Nat> is by using the combo box trick or something else, we need a
    Nat> solution to this problem.  Andersca's coolbar code might be
    Nat> usable here.

The M$ implementation of this has a nice "prioritary" mechanism.  When
the toolbar gets less space than it needs to be fully visible, it
moves the less commonly used elements into a menu on the right (like
Anders' code does).  I would like to know how people feel about it; it
looks like a cool feature to me at first sight, but it has the bad
side effect of changing the relative visual position of some of the
items.  (I.e. if you are used to know that the X button is near the Y
button and the Y button is moved to the menu, then it might be harder
for you to find the X button.)

Anyway, emulating this would just require an extra integer value to
specify the "priority" of the element.  E.g. objects with lower
priority value would have a higher chance to be moved to the menu on
the right.  We may also want to be able to specify that a certain item
should never go to the right (with an "infinite" priority value).

GnomeDock is already designed to handle these situations; it just
needs a toolbar widget that deals with a non-optimal allocation
nicely.

    Nat> While we must provide a way of accessing the dock, we also need
    Nat> the merging functionality.  Microsoft supports it (Outlook uses it
    Nat> extensively; it's probably used elsewhere too), Delphi supports it,
    Nat> and I think JavaBeans supports it.

I agree.

Another thing that we need to provide, on the Bonobo side, is a way to
de-sensitize a specific GnomeDockItem.  For example, the HTML
component in Outlook's message composer uses the main cut & paste &
etc. toolbar for cut & paste, and a separate toolbar for paragraph
style, fonts etc.  When the keyboard focus is not in the HTML
component, the component-specific toolbar is made insensitive.  We
definitely need to support this in order to have a consistent UI.

-- 
Ettore