Re: GEP 6: Toolbar
- From: Andres Salomon <dilinger mp3revolution net>
- To: James Henstridge <james daa com au>
- Cc: gtk-devel-list gnome org
- Subject: Re: GEP 6: Toolbar
- Date: Fri, 13 Sep 2002 16:48:40 -0400
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,
> 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
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
] [Thread Prev