Re: GEP 6: Toolbar

[Andres Salomon <dilinger mp3revolution net>]

Overall, it looks like a very clean solution.  I would love to see what
you have planned for GtkToolItem.

On Thu, Sep 12, 2002 at 09:26:31PM +0800, James Henstridge wrote:
[...]
> By having specialised toolbar child widgets that managed their own 
> appearance (in contrast to the way |GtkToolbar| currently maintains it), 
> we could reduce the number of APIs substantially. Other than the 
> standard |GtkContainer| |add| and |remove| method, we could make do with 
> an |insert| method something like this:
> 
> void gtk_toolbar_insert_toolitem (GtkToolbar  *toolbar,
>                                  GtkToolItem *item,
>                                  gint         position);
>  
> 
> Such a function could be used for |append| and |prepend| operations, by 
> passing -1 or 0 for the |position| argument respectively. If desired, 
> actual functions could be provided as well.
> 
> By treating separators as toolbar items too, we get rid of the need for 
> special APIs to add/remove them, and can manipulate them as with any 
> other item (changing the visibility, in particular).
> 

The option to iterate over the list of toolitems would remain, I would hope..


> 
>    2.2 Packing Options
> 
> There are a number of real world examples where "expand" and "pack end" 
> options would be useful.
> 
> The most obvious use for an "expand" option is for things like the 
> Mozilla and Nautilus toolbars, where the location entry box should 
> expand to fill any extra space.
> 
> The "pack end" option is useful for toolbar items such as 
> throbbers/spinners found in web browsers.
> 

How about an "align" enumeration, in each GtkToolItem; normal/middle, left,
and right?  GtkToolBar reminds me a lot of an HTML table row; being able
to specify alignment, the number of cells a toolitem will take up,
etc...


> 
>    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.
> 
> Two methods of presenting the additional toolbar items include:
> 
>    * The |BonoboUIToolbar| method, which pops up a panel containing the
>      extra toolbar items.
>    * The method used on Qt, Windows and Mac OS X, where a menu is
>      popped up that contains menu items representing the extra items.

There's another option as well; have the toolbar be a scrolled window,
w/ GTK_POLICY_AUTOMATIC for vertical/horizontal scrollbar.  Any overflow
(horizontal or vertical) will cause the creation of scrollbars.  I like
the idea of this better than an arrow button, as the arrow may be missed
w/ a cursory glance.  I'm not familiar w/ bonobo, so I'm not sure what
the panel would look like, but I would think scrollbars would be obvious
and non-intrusive (but not necessarily pretty).


> 
> The |BonoboUIToolbar| method has the benefit of not requiring additional 
> support from toolbar items. In contrast, the second is more consistent 
> with other popular user interfaces so has the benefit of familiarity.
> 
> Final say on how overflow items should be presented should probably be 
> made by the usability team.
> 
> 
[...]
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

-- 
Buying a Unix machine guarantees you a descent into Hell. It starts when
you plug the computer in and it won't boot. Yes, they really did sell you
a $10,000 computer with an unformatted disk drive.
	-- Philip Greenspun