[GUI] State, Attributes and Some basic widgets

[Glynn Clements]

Wolfgang Thaller wrote:

> > The label is more style than state; it seldom needs to be set
> > programmatically; text output (e.g. status indicators) should use a
> > read-only text widget.
> 
> Of course. But I don't see why "style" attributes shouldn't be just 
> "attributes", or why it should not be possible to modify them in the 
> same way as the contents of a read-only text widget.

Oh, the label is an attribute. The point I'm making is that it's part
of the widget's style, rather than it's state, so it should be
discussed along with the other style attributes (font, colour, etc),
rather than with state (toggle state, scrollbar position, text-field
contents etc).

State is something that the API has to provide an interface for at an
early stage. You can't write useful UI code without being able to
read/write state, and any changes to the interface would require
a substantial re-write of application code.

OTOH, the style issues can largely be deferred; in some cases (i.e.
Xt), the code needn't deal with style attributes at all.

In any case, application code shouldn't be attempting to modify
labels. I'm not sure that the API should even support it; doing so is
an invitation to write applications which can't easily be localised
(bear in mind that, with Xt, anyone can localise an application simply
by editing the resource file; this will break if the application
programmatically changes the label to a hard-coded string).

> >> Scroll Bar:
> >> Read/Write attributes: Value, minimum, maximum, size of visible part,
> >> step sizes etc...
> >> Callbacks: onScrollStart onScroll onScrollFinished (or something like
> >> that)
> >
> > Motif has separate callbacks for each type of motion:
> >
> > 	decrementCallback
> > 	incrementCallback
> > 	pageDecrementCallback
> > 	pageIncrementCallback
> > 	toBottomCallback
> > 	toTopCallback
> > 	dragCallback
> > 	valueChangedCallback
> >
> > If one of the first six callback lists are empty, valueChangedCallback
> > is used in its place.
> 
> No problem here, I think. I was trying not to impose my own view of a 
> scroll bar, and to play nice with toolkits that insist on providing 
> default behaviour for scroll bars. If all toolkits allow this kind of 
> detail (Mac OS does), then no problem. One small note though: I would 
> like to be able to tell if we're still tracking the mouse or if we are 
> finished (in case I want a fast low-quality preview while scrolling). 
> Can that be achieved on Motif?

dragCallback is called during dragging; valueChangedCallback is called
when the thumb is released.

> > For all Xt widgets:
> > 	colormap
> > 	depth
> > 	screen
> 
> Screen? The one that the app is running on; if you want to access 
> separate X displays from one app, that would probably need a 
> platform-specific extension anyway.

Note: Display and Screen are different things. A display corresponds
to an X server instance. A screen basically corresponds to a monitor;
on a multi-headed system, you would normally have one screen per
monitor (unless you use e.g. Xinerama to split a single screen across
multiple monitors). Screens may have different bit depths and/or
different visuals (e.g. you could have a colour screen and a
grey-scale screen).

> Depth & Colormap?? I definitely do not want to deal with that strange X 
> visual and colormap business when I'm writing programs for Mac OS and 
> Windows... also, I remember writing small Gtk programs without ever 
> thinking about specifying such attributes. What should we specify here, 
> and is it really absolutely positively impossible to automate it?

No, all of those resources have defaults; typically, the default
screen and default visual determine everything.

For the most part, it's possible to hide display format issues from
the user.

However, they have to be dealt with somewhere (i.e. the back-end). 
E.g. most of the underlying X functions use colour indices; obtaining
a colour index for a specific RGB value is an explicit operation. 
Also, server-side resources such as Pixmaps and GCs are tied to a
specific screen, so you can't create a Pixmap once and use it
everywhere.

It may be necessary to reflect some of this detail into the API,
primarily due to efficiency considerations; repeatedly converting
fixed data from a "portable" format is undesirable.

> > Also, XmRowColumn has a lot of attributes which can only be set at
> > creation time; it also has a lot of pseudo-attributes related to menus
> > which can be set at creation time but can't subsequently be written or
> > read.
> 
> Well, I doubt we will be using XmRowColumn exactly as-is for 
> cross-platform programmatic layout of widgets. The various layout 
> mechanisms deservere their own discussion...

That's why XmRowColumn has so many non-writable attributes and
pseudo-attributes. It tends to be used in fairly idiomatic ways; e.g. 
menu bars and menus are actually XmRowColumn widgets, radio groups are
implemented using XmRowColumn widgets etc. There are 7 different
convenience functions for creating specific types of XmRowColumn
widget, each of which provides specific values for certain resources
(the ones which create menus also create the shell).

-- 
Glynn Clements <glynn.clements@virgin.net>