Widgets typically do a selection of the following:
- display text (simple or formatted)
- display image
- display some special thing (spinner, accelerator key, status, level, progress)
- display a clickable link
- expose a control (scrollbar, slider, button, check button, radio button, switch, combo box)
- input (numerical spinner)
- edit text (entry, search)
- contain sub-widgets (button, scrolled region, specialised collection of controls, stack/tab)
- window (proper windows, dialogs, popups)
### Displaying text
Text display can potentially have a *lot* of complexity:
- size/scale/DPI
- font family (regular, monospace, ...)
- specific font
- style (bold/italic)
- colour, opacity
- clickable links
- flow control: tables, lists, offset blocks, etc.
- display angle
- embedded objects (typeset maths, images)
How precisely should this be handled? Different toolkits like GTK and Qt already
have ways of handling "rich text":
- Qt supports plain text and rich text (subset of HTML 4)
- GTK supports style information via CSS and applying tags to text ranges
- Windows supports alignment, justification and colour per *control* and an
accelerator key within the text (via `&`)
- MacOS's AppKit appears to support both text properties per control and
some type of rich text format
Suggestion: support both plain and rich text (like Qt); let the toolkit
translate or discard formatting as necessary.
Note: associated icons should not be handled as an embedded image because of
localisation, theming and scaling.
#### Where to allow rich text?
The simplest answer may be to have a single "text" widget which gets embedded
in anything displaying text: labels, menu entries, buttons, ...
This appears to be compatible with GTK's model (which allows buttons etc to have
child widgets), but not Qt's (which only allows a plain-text label and icon for
many widgets).
#### Usability and localisation
Several toolkits support accelerator keys, set as part of the label: `&Control`.
This allows the key in question to be defined by the localisation.
Text strings will often be loaded from a localisation rather than used raw. This
doesn't necessarily need to be part of the GUI code however (it it were, it
would imply a need to handle raw strings and localised strings differently).
#### Dimensions
Size of font depends on the style, but line length could be specified in terms
of characters. Text displays should allow "width for height": typically being
given a set width, then calculating the ideal height.
Additionally, text views should be able to choose a preferred width. This may
be "as long as necessary" to display text without extra line breaks, but for
large passages of text this may not be ideal: instead it may be preferable to
automatically break passages after a length of 80 or so characters.
### Properties
#### Anything with a label
- text
- text kind: plain or rich text
- various text properties (or style information)
- rotation?
- icon (many entries with a label)
- selection (to allow copy)
#### Text edit fields
There is a lot of overlap with "labels", but some distinctions too (cursor
position, possibly lack of rich text support).
- text
- cursor position
- selection
#### Simple value fields
- boolean (toggle buttons, check boxes, radio buttons)
- numeric (progress bar, spinner, etc)
#### Anything accepting user input
- enabled / disabled
- accelerator key
- has focus?