[GUI] State, Attributes and Some basic widgets

[Wolfgang Thaller]

Glynn Clements 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.

>> Callbacks: onClick
>
> "onActivate"; "onClick" implies use of a mouse.

OK.

>> 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?

> Also, Motif has "scale" widgets (Windows has something similar), which
> should be used for generic value input; scroll bars are specifically
> for scrolling.

Same thing everywhere... Mac OS has "sliders".

> 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.
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?

> For all Motif widgets:
> 	layoutDirection
> 	stringDirection

Looks like an internationalization issue... a useful default would be 
the direction of the application's language. Normally, I'd expect the 
"text direction" of a button label to depend on the (language of the) 
button label.

> Scrollbar:
> 	orientation

Of course. Nobody will mind passing a boolean to the constructor in 
this case...

> 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...

Cheers,

Wolfgang