Toolbar ideas
- From: James Henstridge <james daa com au>
- To: gtk-devel-list gnome org
- Subject: Toolbar ideas
- Date: Thu, 04 Jul 2002 22:28:04 +0800
Anders asked me to post some ideas on what would be nice features to
have in a new toolbar widget, so here is what I have so far:
While implementing the UI merging code for EggMenu, I ran into a number
of issues that made implementing the toolbar merge code fairly
difficult. Most of these problems would probably be better solved by
fixing the toolbar APIs.
Some of the problems in the current file selector code include:
* Toolbar buttons are handled different to separators, which are
handled different to other widgets. It would be nice if all
toolbar items had a common base type (GtkToolItem, mirroring
GtkMenuItem, maybe?) This would make handling in EggMenu and
GtkItemFactory doable.
* Pattern for creating toolbar buttons quite different to other
child widgets; one function to construct and add to parent. Can't
easily remove a button from one toolbar and add to another (or
move a button in the same toolbar).
* No way to get some toolbar items to expand to fill available
space. This is useful for things like the location bar in
Mozilla/nautilus, and may also be useful to insert spacers (which
would allow for putting items such as throbbers on the right edge
of the toolbar).
* No handling of overflow. If the width of the toolbar exceeds the
width of the window, then it would be nice to handle overflow in
one of a number of ways:
o Like BonoboToolbar: a button that pops up a panel with the
extra items.
o Like Windows/OSX: a button that pops up a menu with items
representing the toolbar buttons
o wrap round to a second line of buttons? (this is difficult
with existing GTK+ geometry management, so can probably be
ignored).
Ideas for the a better toolbar API:
* children of toolbar are GtkToolItem objects (which may be a
subclass of GtkItem; this would make it usable to GtkItemFactory).
* Have tool items for various button types, separators, and one that
can hold an arbitrary widget (good for entries, etc).
* GtkToolItems track orientation, toolbar_style and icon_size
properties of toolbar and are responsible for the consistant display.
* Have a flag to specify whether a tool item should be used in the
calculation of the size for toolbar buttons.
* - tool items have a hook for creating a menu item proxy for use in
overflow situations (if we decide to support that form of overflow
handling).
* Toolbar allows setting "expand" packing property. (to handle
things like a location bar).
* simple API to add and remove GtkToolItems from toolbar.
Do we want to build on top of the existing toolbar widget?
* would probably want to deprecate half the APIs
* constrained by existing struct layout.
o no fields marked /*< public >*/, but children and
num_children are documented in the reference docs.
o GtkToolbarChild struct
* how much of the internals are currently in use by applications?
or create a new widget?
* no backward compatibility concerns if we create new widget
* can't call new widget GtkToolbar if we go with new widget
Other toolbar APIs:
Mac OS X Cocoa:
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/Toolbars/
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/Java/Classes/NSToolbar.html
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSToolbarItem.html
.Net Windows Forms:
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemWindowsFormsToolBarClassTopic.asp
http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemwindowsformstoolbarbuttonclasstopic.asp
Java Swing:
http://java.sun.com/j2se/1.4/docs/api/javax/swing/JToolBar.html
James.
--
Email: james daa com au | Linux.conf.au 2003 Call for Papers out
WWW: http://www.daa.com.au/~james/ | http://conf.linux.org.au/cfp.html
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]