While I can see the advantage of providing your own i18n mechanism (potentially less work), it would be a "second best", IMHO. For the Xt version, allowing the user to customise it via X resources is the "native" approach. In order for that to work, it's necessary that the application doesn't override the X resources programmatically.
But surely we shouldn't limit what applications can do. I have no problem with placing a note in the documentation that says "don't change labels programmatically, you'll prevent Xt users from customizing your App the way they like".
Do any programs support placing their windows on more than one screen?
It's most common with graphics software, e.g. allowing a monochrome screen to be used for the UI to free up space on the colour screen for the graphics.
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).
Yes; a platform which has no concept of separate screens will only ever have screen 0 (i.e. like most of the boxes which run X).
Well, it looks like platform-specific extension to me... You'd have myWindow <- window DocumentWindow [... attributes ...] ... which uses the default screen for Xt, and for Xt only, you'd have something along the lines of myWindow <- windowOnScreen_XT 2 DocumentWindow [... attributes ...] which, on X, will use screen 2. (We could still provide a stub implementation of this function for other platforms, to allow compilation everywhere...) The reason why I prefer to have that clearly marked as an extension is that I, for one, would have been thoroughly confused by a window creation function that expects me to specify a screen number. And I would especially have had problems with understanding the notion that my dual-monitor Mac only has one "screen".
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. [...] [...]
Okay, I see the problem. Discussion topic number one for the chapter "Images and Drawing" :-).
A few things that need working out are:
a) What types and classes should be used to represent widgets in Haskell?
Even if you have specific types for specific widget classes, you definitely need a generic Widget type, and any operation which could reasonably be expected operate on any widget should.
Probably. The question is, to what extent do we use type classes to achieve this, etc... I would advocate specifc types for specific widget classes (e.g. Button, ScrollBar, etc.), just because it's the Haskell Way ;-) . If we also have a general Widget type, we could have functions like fromWidget :: Widget a => Widget -> Maybe a and toWidget :: Widget a => a -> Widget That's all for now, Cheers, Wolfgang