Re: State, Attributes and Some basic widgets

> 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