[GUI] State, Attributes and Some basic widgets

[Wolfgang Thaller]

> 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=20=

toolkit out there supports changing style attributes of widgets at=20
runtime, so why shouldn't we?
I would just manage the "style" attributes and the "label" attributes=20
using exactly the same syntax. We should just provide good alternative=20=

means.

After all, for an application where we create the UI programmatically,=20=

we would want to do localization via our own string-table mechanism. If=20=

I wanted to localize just the Xt version of an application, I'd use X=20
resources, but if I want to localize a program for three platforms, I'd=20=

want the application to just use it's own string table mechanism... I=20
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.
=C4hh...
Somewhere I read that the DISPLAY variable contains a number referring=20=

to the server and one referring to the screen... so :0.0 would be=20
server 0, screen 0. Is it true, therefore, that $DISPLAY in fact refers=20=

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=20=

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=20
move a window from one screen to another? Do any programs support=20
placing their windows on more than one screen? Can this reasonably be=20
inside the scope of a cross-platform library? (We might still have=20
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=20
one window being half on an 8-bit-greyscale monitor and on a 15-bit=20
color monitor... and then the user could go and change color depths,=20
resolutions and the arrangement of the monitor on the fly.
Therefore we can't attach any fixed color depth attributes to any=20
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=20
offscreen drawing? In that case, I agree that there are some problems=20
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=20
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=20
disagreements were left?

Cheers,
	Wolfgang