dana@dino.bellcore.com (Dana A. Chee) (08/19/88)
Is there a good reason why XOpenDisplay retrieves the
XA_RESOURCE_MANAGER property off of screen 0 as opposed to the default
screen and xrdb stores the XA_RESOURCE_MANAGER property on screen 0.
This causes much grief when running multiple screens since you often
want different setups for different screens (for example, on a Sun
3/60FC, you can have a color and a monochrome screen, needless to say,
the defaults for one don't work on the other).
Is this a fundamental X'ism, an oversight (that won't cause future
problems if I fix) or a bug that will be corrected in R3?
Thanks,
--
+*************************************************************************+
* Dana Chee (201) 829-4488 *
* Bellcore *
* Room 2Q-250 *
* 445 South Street ARPA: dana@bellcore.com *
* Morristown, NJ 07960-1910 UUCP: {gateways}!bellcore!dana *
+*************************************************************************+RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (08/20/88)
Date: 19 Aug 88 12:40:34 GMT
From: dana@bellcore.bellcore.com (Dana A. Chee)
Is there a good reason why XOpenDisplay retrieves the
XA_RESOURCE_MANAGER property off of screen 0 as opposed to the default
screen and xrdb stores the XA_RESOURCE_MANAGER property on screen 0.
This causes much grief when running multiple screens since you often
want different setups for different screens (for example, on a Sun
3/60FC, you can have a color and a monochrome screen, needless to say,
the defaults for one don't work on the other).
The issue seems a little complicated to me. In some sense, the idea of
a "color" screen is an "anomaly" of current low-end workstations. A
number of high-end machines are now providing multiple visual types
simultaneously on the same screen. The current Zaphod implementation on
the Sun 3/60 is "wrong"; a much better approach (and one that appears to
be relatively trivial to implement) is to provide a single screen with
two visuals instead.
The problem is that virtually no applications today try to cope with
choosing the "best" visual for their needs, they simply take the
default. This makes providing multiple visuals kind of boring, and is
why we haven't yet hacked the Sun server. In the thinking we've done on
this locally to date, it seems like widgets, etc. should be expressing
preferences on visuals (e.g., PseudoColor-depth-8 is better than
StaticGray-depth-1), and then (sets of) resources should be qualified by
those preferences. That way, more of the "right thing" is likely to
happen both on single-screen-multi-visual and multi-screen-single-visual
sytems, and the need for multiple resource properties doesn't seem quite
as important.
Is this a fundamental X'ism, an oversight (that won't cause future
problems if I fix) or a bug that will be corrected in R3?
I don't believe it will be changed in R3. Also, note that there are
such things a multi-screen applications; the Xlib interface does not
provide a way to distinguish which screen's resource should be used.