Re: GEP 6: Toolbar

[James Henstridge <james daa com au>]

Jody Goldberg wrote:

> 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.
Good point.

> 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.
This sounds like an interesting idea.  Michael talked about a similar 
idea for priority text (items with higher priority might get text 
labels, in order to fill available space).  Could make sizing a little 
more difficult, but might be worth it.  It would have to be balanced 
with the confusion due to buttons reordering themselves ...

The "only when horizontal" and "only when vertical" flags sound good. 
We had talked about them a bit when brainstorming for EggToolbar, but I 
forgot about them when writing the GEP.

> Ideally GtkToolbarStyle would have PRIORITY_TEXT added and the
> control centre changed to support it.
That seems like the best way to integrate this mode.

> > 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.
Some drag and drop helper routines might be the best way to handle this. 
That seems to be one of the more fiddly parts of a customisation UI.

> 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'
Do you directly connect to signal handlers on the bonobo toolbar items? 
If not, it might still be possible to maintain bonobo's behaviour.  The 
toggle button example you give is simply a case of connecting to the 
toggled signal with or without the G_SIGNAL_CONNECT_AFTER flag.

> > 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.
I haven't really looked at doing any special sensitivity handling in the 
EggToolbar prototype, so standard GTK sensitivity handling would control 
things.

> 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 ?
>  
I may be wrong, but I think this is already possible for stock icons. 
You would simply need to set different stock images for the NORMAL and 
PRELIGHT states, so I would consider this a theme issue.  Not sure if 
this should be a toolbar specific issue.

James.

--
Email: james daa com au              | Linux.conf.au   http://linux.conf.au/
WWW:   http://www.daa.com.au/~james/ | Jan 22-25   Perth, Western Australia.