Re: GEP 6: Toolbar

[Jody Goldberg <jody gnome org>]

A few minor additions.

On Thu, Sep 12, 2002 at 09:26:31PM +0800, James Henstridge wrote:
>  2. Requirements
>    * /think of some more reasons why this is bad/
Too many APIs and mismatching features for the same concepts.
 
>    2.3 Overflow
> 
> On some displays, a toolbar may not be able to display all items in the 
> width of the screen. The toolbar should handle this gracefully, rather 
> than forcing the window to be wider than the screen. The common way to 
> handle this is to omit the last items in the toolbar and provide a small 
> arrow button at the end of the toolbar that can be used to access the 
> extra items.
A potentially useful enhancement would be to provide a priority for
toolbar items so that less useful items can get culled first.
Another useful attribute would be to flag an item as being visible
for H or V only arrangements.
 
>    2.4 Priority Text
Ideally GtkToolbarStyle would have PRIORITY_TEXT added and the
control centre changed to support it.

>    2.7 Toolbar Customisation
> 
> Decision on the preferred interface should be up to the usability 
> project and/or accessibility project.

> Whether the toolbar should include code to help customise the toolbar or 
> not is open to discussion. The toolbar should definitely not get in the 
> way of such code though.
I doubt we'll be able to side step this choice some of the methods
mentioned will require toolbar support to be feasible.
eg MS Office direct manipulation would be substantially easier with
some support routines in the toolbar.

Whatever method is chosen it seems like it would belong in eggmenu
with the convenience wrappers 
 
>    2.8 Compatibility Concerns
> 
> Compatibility with the existing |GtkToolbar| is desirable, as it 
> eliminates the need to deprecate the widget.
I doubt there is much we can really do here given the api/abi freeze
in gtk+ and gnome.  The existing api and its associated semantics
must continue to exist until 3.0.  Although Bonobo's toolbar usage
is wrapped in xml we are not completely free to substitute in
another implementation.  Bonobo has different semantics for some of
its callbacks (eg toggle items which fire before vs after the state
change is registered).  It seems wasteful to blur the api by adding
magic 'send the signal the bonobo way vs oldgtk way'

>  3. Issues Raised During Discussion
Sensitivity changes

    A common application requirement for toolbars is to enable/disable
    many/all items.  There are several things to consider here.

    1) Desensitizing the toolbar should desensitize the contained items
       Resensitizing the toolbar should restore the states that were
       there before the original desensitization.  BonoboUI gets this
       wrong and overwrites the states of the contained items.

    2) Efficient use of bandwidth.  In gtk2 changing the sensitivity of
       a toolbar results in significantly more network traffic than gtk1.2.
       Gnumeric over 10mb/s (eg a wireless connection) crawls as the
       toolbars are enabled/disabled.

    3) If at all possible I'd like to be able to support MS Office style
       toolbars which desensitize most but not all toolbar commands
       while editing something.  Since some of the items will remain
       enabled the application can not just desensitize the toolbar.
       It needs to do a mass change.  Doing that efficiently would be a
       benefit.

    An example of this is their format toolbar which frequently
    leaves several of it items (font & colour selection) enabled
    while editing or selecting objects to which they apply.

Icons and focus indication

    Do we want to support MS IE style focus colouration changes ?
    In Office 2k the toolitem with the focus gets raised edges if it
    is a button, and has no indication if it is not (eg a combo)
    In MS IE they visually differentiate between
    - insensitive                : 'flat' grayed out
    - sensitive but not focus	 : gray scale image
    - sensitive with focus	 : coloured
    Which is a nice touch.  Would eventual support for something
    like this add any requirements ?