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