Re: GEP 6: Toolbar

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

   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.


Email: james daa com au              |
WWW: | Jan 22-25 Perth, Western Australia.

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