Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!bbn!rochester!spot!uffa!mayer
From: mayer@uffa.wbst128.xerox.com (Jim Mayer)
Newsgroups: comp.windows.x
Subject: Re: Why is resouce manager property only set on Screen 0 ?
Message-ID: <231@spot.wbst128.xerox.com>
Date: 28 Sep 89 11:48:39 GMT
References: <8909261901.AA16950@prometheus.think.com> <8909261934.AA23735@expo.lcs.mit.edu> <3240@arisia.Xerox.COM>
Sender: news@spot.wbst128.xerox.com
Reply-To: mayer@uffa.UUCP (Jim Mayer)
Organization: WRC, XEROX
Lines: 85

We have (or have on order) about seven machines in two headed
configurations in all pairwise combinations of [19" 1152x900 color,
16" 1152x900 color] x [19" 1152x900 b&w, 19" 1600x1200 b&w].  The
current way the resouce manager property is set up is a real pain.

We like the two headed configurations because:

(1) Monochrome monitors, particularly the 1600x1200 variety,
are still far superior to color monitors for long term readability.
Even very good color monitors have noticably fuzzier spots than good
black and white monitors.  Having two monitors lets us do color work
while developing in the environment of our choice.

(2) We can develop applications on one screen while writing/debugging
them on another.

(2a) Extra desktop space never hurts.

Interestingly, this is not the first time this has come up.  I posted
a similar note back in April (but got only one reply, by a fellow
sufferer).  I assume I was not the first.

I would like to point out some aspects of the problem:

(1) defaults need to be BOTH screen AND visual dependent.  In
particular, resolution, depth, and visual type are all independent
properties.  In the X protocol, resolution is defined to be a property
of the screen.  For each screen, the server provides a list of depths,
and for each screen/depth combination, the server provides a list of
visuals.  Note that the protocol document (mine is dated 10 Sep 1987)
states that:

	A given visual type might be listed for more than one depth,
	or for more than one screen.

			[Section 9, Connection Setup]

(2) It is also, unfortunately, true that there is no simple way, in
general, to associate properties (eg. default colors) with a single
type of attribute (eg. visuals); I really need to be able to specify
the full screen x depth x visual-type combination.  I also want to be
able to default things in a reasonable way.  For example, I might want
to specify resolution independent size properties once for windows
that understand them (eg. Large, Small, Medium, 12pt [typographic]
font, etc.), pixel sizes on a per screen bases, some colors on a
visual (or even color vs. b&w basis), and other colors on a screen x
depth x visual basis.

(3) Despite (1) and (2) above, I think that implementing a general
associative database in the server would probably be a mistake.  I
would be tempted to push the nasty details of defaulting and
inheritance into either the xrdb program, or the resource manager, or
both.  In particular, I don't think the problem can be solved by
making the RESOURCE_MANAGER property screen specific (since a single
application can use multiple visuals, and can have windows on multiple
screens).

(4) One thought I had was to extend the resource manager so that
database entries were effectively prefixed by
"screen.depth.visual_type".  The usual resource manager disambuguation
rules could then be applied.  The extra qualification would be derived
at run time from the source of the property default.  One cute feature
of this approach is that it is compatible both with having multiple
RESOURCE_MANAGER strings, and with a scheme that uses an xrdb like
program to merge screen specific information into a single resource string.

(5) Finally, one can (at least on a Unix system) use the XENVIRONMENT
environment variable to provide a crude workaround for now.

-- Jim Mayer

Member Research Staff
Systems Sciences Laboratory

Xerox Webster Research Center
800 Phillips Road, 0128-29E
Webster, New York 14580

Phone: (716) 422-9407 (8*222-9407)
Fax: (716) 422-2126
EMail: mayer.wbst128@xerox.com (James L Mayer:wbst128:Xerox)
-- Jim Mayer

Member Research Staff
Systems Sciences Laboratory