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