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