[GUI] State, Attributes and Some basic widgets

[Glynn Clements]

Wolfgang Thaller wrote:

> 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.

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.

> > Note: Display and Screen are different things. A display correspond=
s
> > to an X server instance.
>=20
> =C4hh...
> Somewhere I read that the DISPLAY variable contains a number referrin=
g=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 refe=
rs=20
> to a single screen of a display?

The number after the period specifies the *default* screen, as
returned by the DefaultScreen[OfDisplay] macros. It's possible to use
a different screen when creating shell widgets (top-level windows);
obviously, a shell's descendents have to be on the same screen as the
shell.

> > 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 acro=
ss
> > multiple monitors).
>=20
> 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?

No. The program would have to destroy the window and re-create it on
the new screen.

> Do any programs support=20
> 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=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=
).

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).

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

Well, if you want to display a true-colour image, you would typically
query the pixel format, generate an internal version which is
compatible that format, then use the internal version thereafter. You
wouldn't want to convert the image every time it was drawn.

Similarly, a GC's foreground/background colours are colour indices;
converting an RGB value to a colour index may involve searching the
colour map to find the closest colour, or may require allocating a new
entry in the colour map. You don't want to convert the same RGB colour
to its corresponding index for every operation.

It's possible that some of the details could be hidden by
demand-conversion and caching, although that's potentially wasteful
(internal representations could persist when they are no longer
required).

> A few things that need working out are:
>=20
> a) What types and classes should be used to represent widgets in Hask=
ell?

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.

--=20
Glynn Clements <glynn.clements@virgin.net>