[Python-3000] back with more GUI planning in a few days...

[Talin]

Bill Janssen wrote:
>>A far as widgets go, I think I'd be satisfied (mostly) with the following
>>(this is just off the top of my head, and not a definitive list):
>>
>>  Window
>>  Dialog
>>  Button / Checkbox / Radio
>>  Scrollbar
>>  Slider
>>  Listview
>>  Combo box / drop-down
>>  Scrollview
>>  Group box
>>  Tree View (extra credit: support drag and drop.)
>>  Spinner (i.e. increment/decrement control)
>>  Grid View
>>  Text Edit / Multiline Edit / Styled Edit
>>  Static Text
>>  Static styled text
>>  Static Image
>>  Toolbar (Dockable if supported by the platform)
>>  Menubar / Menu / Menu item  
>>  Status bar
>>  Tab panel
>>
>>Standard system dialogs:
>>
>>  Open File
>>  Save File
>>  Select Directory
>>  Color Chooser
>>  Font Chooser
>>
>>Standard application dialogs:
>>
>>  Caption + Single button (notify)
>>  Caption + Two buttons
>>  Caption + Text Entry + Two buttons
>>
>>Standard cursors:
>>
>>  Arrow
>>  Hourglass / Wait
>>  Sizing cursors: left/right, up/down, NE/SW, NW/SE
>>  I-beam cursor
>>  Hand / Drag cursor
>>
>>Standard Alerts:
>>
>>  Notice
>>  Warning
>>  Error
> 
> 
> That's an interesting list, Talin.  It's close to my list.
> 
> I have to confess I don't see the point of some of them: Listview and
> Gridview are trivial if there's a reasonable layout system, Statusbar
> and Toolbar are likewise just arrays of other widgets.  Spinner is a
> non-issue for me.  I also don't really see the point of the "standard
> application dialogs", as they are so easy to build yourself.

Both List views and grid views have behaviors that are subtly different 
from mere groups of independent widgets.

For example, in a list view, the up and down arrow can typically be used 
to select the previous / next item.

Some UI systems have two kinds of list views: a simple "list box", which 
stores only strings, and which scrolls by line rather than by pixel (in 
other words, scrolling is quantized so that you never see "half" of a 
line); and "list views", which can contain arbitrary variable-height 
items and which scroll by pixel.

Both list views and grids are presumed to have dynamic content, in the 
sense that the program is frequently changing the data being displayed.

A grid view is essentially a spread sheet, with row and column headers, 
variable-sized rows and columns, and so on. Its use is somewhat 
specialized - in most cases, a multi-column list view can do the same job.

Spinner is easy to do (it's just a scrollbar without the thumb), and 
supported by every GUI that I've seen. And it gets used fairly frequently.

Statusbar and Standard Yes/No dialogs are convenient packagings of other 
widgets, with an interface wrapper around them. Because the are used so 
much, there's no real reason for the application developer to have to 
reimplement them for every app.

Toolbars are a little different, depending on what level of feature 
support you want. At the most basic level, they are just collections of 
widgets. Most modern platforms, however, allow docking/floating (the 
ability to move the toolbar to different edges of the window), or user 
customization.

> "Color chooser" and "Font chooser" seem to fall into the category of
> "widgets that aren't used by UIs, but are very hard to build yourself,
> so the toolkit should do it", which is a reasonable contention
> (though, I think, not overwhelming).

Actually, they fall into the category of dialogs which look completely 
different on different platforms. The OS X color dialog looks nothing 
like the windows color dialog. Ideally, the application writer should be 
able to just say "ask the user for a color", and the correct sort of 
dialog should pop up.

> Styled text is another question mark.  Though I've used static styled
> text, and found it handy, I'm not sure I'd miss it that much.  Ditto
> for editable styled text (I'm not sure I've ever used it).  More
> important to me would be a text editor widget which supported in-line
> objects, like images and hyperlinks.

Agreed, editable styled text is probably in the realm of an "advanced" 
feature. I only added it because it's been on my mind lately (One of the 
things that I am working on at work is a web browser for embedded 
systems that supports CSS.)

> Bill