Re: Alternative GTK widgets

["Freddie Unpenstein" <fredderic excite com>]

Some thoughts about some of the alternative widget sets presented, and how I personally view them as applying 
to GTK...  Most of this I've been mulling over on and off for a while, in one form or another.  So I've 
decided to take this opportunity (since I didn't know most of these toolkits even existed until now) to put 
it all down in one place, and see if any interesting ideas pop up.


> http://www.curlyankles.com/
** ToolBar
+ Resizable toolbars (when docked against other toolbars).
+ Resizable floating toolbars.
+ The ability to hide buttons on a toolbar.
+ ALT customisable toolbars for dragging buttons between menus and toolbars.
+ Sub menus that can be torn off.
- Toolbars and Menus that keep a history and initially hide low usage count buttons.  [too "start menu"ish]
- An image editor for customising the toolbarbutton appearance.  [just say no!]
+ The ability to drag toolbarbuttons from the customisation dialog (or via ALT) between menus and toolbars.  
[and let GNOME automagically extend that inter-application and to panels]
+ Toolbars can be docked against the vertical or horizontal orientation.
** PageGroup
+ Draggable GtkNotebook tabs (reorder, maybe even drag tabs to different sides)
+ Nested notebooks with flexible tab drop control, can make this happen
** Docking
+ Enhanced handlebox widget that facilitates docking of basically anything

The highlights from the above, as I would see them implemented;
- Being able to move items between menus and toolbars
  - Similar to being able to modify menu item shortcuts
  - Drag and drop of menu and toolbar items between all menus and toolbars
  - Ability to simply reorder menu or toolbar items
  - Toolbars that will float and dock to any edge of the window
- A "GtkDock" derivative of GtkBin that allows docking on any/all edges
- A "GtkDockable", same as GtkDock, but has a handle marker and allows dragging
  - Toolbars would be moveable/reorderable/etc. if placed in a GtkDockable
- The ability to create a new toolbar/menu, and mix'n'match items
  - Saving of an applications current menu/toolbar configuration per-user

> http://kornelix.squarespace.com/utilities/
MatchWild :: compare a string to a string with wildcards (* and ? characters)

- Some kind of Glib matching object
  - An abstract base class that represents a "pattern" for string searching
  - An "exact" derivative that matches a fixed string against another string
  - A "glob" derivative that matches a glob pattern against another string
  - A "regexp" derivative that matches a regular expression against a string
- object represents a "compiled" pattern
  - simply a copy of a string for exact matches
  - possibly break up a glob string into exact sub-strings?
  - mostly needed for regular expressions
- support for partial and/or progressive matches, and (opt) sub-match portions
  - glob match could remember indicies where each wildcard matched (start/stop)
  - "extended glob" allowing shell-like {,} matches
    - sub-range markers; useful for extracting sub-strings around a match
(This sort of thing comes in handy for path and list matching, where the filter pattern is given in a 
configuration file or something.)


> http://gtkmaskedentry.sourceforge.net/
+ Formatted input fields have been around for a long time, and very handy for a lot of different things.
+ The "fill in the separators as you type" method is good for some thigns, especially where you can't 
reliably tell beforehand how wide to make each field (great big gaps can look kinda odd).

> http://view.sourceforge.net/
** DeadEntry
+ GtkEntry should fade out more when it's made uneditable
+ Uneditable GtkEntries should still allow select and copy of the text
** FieldEntry
+ For the same reasons as the masked entry
+ The positional nature is a definite interesting idea
  - How to handle UTF-8 text entry where a "character" may end up being wider?
+ Able to copy and paste the entire content is a positive (incl. sep chars)
** Header
+ For GTK, perhaps just a style for GtkFrame that fills the box
** UndoableTextView
+ Undo should be supported by every text entry widget in existance

> http://www.gnome-db.org/
- I've thought for a long time, this sort of thing should be inherant in GTK
  - Allow full databases to be used in place of existing GTK data stores
  - Standard GtkTreeView would instantly be usable with a full database
- Implement a "single row view" that describes how a row is to be rendered
  - View would hold a data source row reference, and widget "cell renderers"
  - Generalise the TreeView column renderers to also drive standard widgets
  - Text renderers could link to GtkLabel, GtkEntry, or even GtkTextView
  - Image renders link to GtkImage, or pre/post images in a GtkEntry
    - Potentially even images in a meny item, toolbar and/or normal button
  - Field renderer would allow multiple text renderers to be chained together
    - Would be able to be automatically editable, as long as individual fields
      are unique or seperated by a unique text seperator.
- Widgets then display the rendered output
  - The usual row data function can be used as well as standard linkage
  - Similar function to provide reverse update linkage where needed
- Set of standard button icons, and a standard "toolbar" for data row navigation

GtkEntry
- Allow widgets to be packed before and after the actual entry field, ala Firefox's address bar.
- Alternatively, make it possible to "fake" it reasonably easily and reliably.  That is, document how to 
create a style-friendly borderless GtkEntry, within a HBox, surrounded by a GtkEntry-esque box.


Just thought I'd throw in a quick spanner...  Haven't received any flames in a while.  ;)


Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!