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
That "doing so is an invitation" attitude sounds dangerous. Every other toolkit out there supports changing style attributes of widgets at runtime, so why shouldn't we? I would just manage the "style" attributes and the "label" attributes using exactly the same syntax. We should just provide good alternative means. After all, for an application where we create the UI programmatically, we would want to do localization via our own string-table mechanism. If I wanted to localize just the Xt version of an application, I'd use X resources, but if I want to localize a program for three platforms, I'd want the application to just use it's own string table mechanism... I wouldn't want to have to localize it three times.
Note: Display and Screen are different things. A display corresponds to an X server instance. Ähh... Somewhere I read that the DISPLAY variable contains a number referring to the server and one referring to the screen... so :0.0 would be server 0, screen 0. Is it true, therefore, that $DISPLAY in fact refers to a single screen of a display?
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).
Seems like I've been taking something like Xinerama for granted since I first used a Mac with two monitors a little over ten years ago. How do you use a computer with multiple X screens? Is it possible to move a window from one screen to another? Do any programs support placing their windows on more than one screen? Can this reasonably be inside the scope of a cross-platform library? (We might still have platform-specific extensions for this, but that's none of my business).
Screens may have different bit depths and/or different visuals (e.g. you could have a colour screen and a grey-scale screen).
Just as on Mac OS. Only on Mac OS, I can have it Xinerama-style, with one window being half on an 8-bit-greyscale monitor and on a 15-bit color monitor... and then the user could go and change color depths, resolutions and the arrangement of the monitor on the fly. Therefore we can't attach any fixed color depth attributes to any widgets...
For the most part, it's possible to hide display format issues from the user.
I hope so.
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.
I see. Are you talking about manipulating images and perhaps about offscreen drawing? In that case, I agree that there are some problems there, but we can deal with that later. A few things that need working out are: a) What types and classes should be used to represent widgets in Haskell? b) How can we write those attribute getters/setters? c) How do we attach callbacks? I think we already had some results on that, but no vote... what disagreements were left? Cheers, Wolfgang