Wolfgang Thaller wrote:
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.
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 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?
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 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?
No. The program would have to destroy the window and re-create it on the new screen.
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).
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.
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:
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.
--
Glynn Clements