Re: State, Attributes and Some basic widgets

> 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