salem@THINK.COM (09/24/89)
Currently, xrdb only sets the XA_RESOURCE_MANAGER property on screen 0 of the display. This seems like a mistake. Different screens may have very different characteristics (e.g. color vs. black and white) and thus need different resource defaults. Is there any way to handle this correctly in the current X ? Are changes planned for the future ? The "Resource Manager Convensions" section of the ICCCM version 1.0 document leaves quite a bit to the imagination (:-) -- jim salem@think.com
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (09/26/89)
Currently, xrdb only sets the XA_RESOURCE_MANAGER property on screen 0 of
the display. This seems like a mistake. Different screens may have very
different characteristics (e.g. color vs. black and white) and thus need
different resource defaults.
Is there any way to handle this correctly in the current X ? Are changes
planned for the future ?
Not immediately. The problem is that you really need some of way of
classifying resources by visual since the "right" way (in our humble opinion
:-) to manage displays that have mono and color planes (or pseudocolor and
true color) is to have all of the visuals on one screen instead of two
virtual screens.garyo@Think.COM (Gary Oberbrunner) (09/26/89)
Someone asks (and I have the same question):
Currently, xrdb only sets the XA_RESOURCE_MANAGER property on screen
0 of the display. Is there any way to handle this correctly in the
current X ? Are changes planned for the future ?
Jim Fulton replies:
Not immediately. The problem is that you really need some of way of
classifying resources by visual since the "right" way (in our humble opinion
:-) to manage displays that have mono and color planes (or pseudocolor and
true color) is to have all of the visuals on one screen instead of two
virtual screens.
Well that's all well and good, but right now the MIT sample server uses two
screens. And believe it or not it's a fine way to get work done. It's a
lot like having a huge 2Kx1K screen. Yes, I know this has all been debated
before. But:
(a) I kind of like the two screens.
(b) I have to live with them since I'm running MIT's very own supposedly
blessed sample server. I need SOMETHING until you guys come out with the
magical solution you're envisioning. I mean, I've got work to do.
(c) When you open a display you can set the default *screen*, but not the
default *visual*. This seems to me to be a strong indication that the
resource defaults should be organized along the same lines. Or perhaps we
should invent a new way to specify default visuals as part of the display
name?? :-) :-) The relevant code is in XOpenDisplay, which takes a display
name and a screen number (as name:number, natch). How hard would it be to
make it look at the screen number rather than assuming 0 when it loads its
resources? Jeez, it looks easy to me. Shall I post diffs? :-)
As always,
Gary O
-----------------------------------------------------------------------------
Remember, Truth is not beauty; Gary Oberbrunner
Information is not knowledge; Beauty is not love; {ames,harvard}!think!garyo
Knowledge is not wisdom; Love is not music; garyo@think.com
Wisdom is not truth; Music is the best. - FZ (617) 876-1111 x265
--
As always,
Gary O
-----------------------------------------------------------------------------
Remember, Truth is not beauty; Gary Oberbrunner
Information is not knowledge; Beauty is not love; {ames,harvard}!think!garyo
Knowledge is not wisdom; Love is not music; garyo@think.com
Wisdom is not truth; Music is the best. - FZ (617) 876-1111 x265jim@EXPO.LCS.MIT.EDU (Jim Fulton) (09/27/89)
Well that's all well and good, but right now the MIT sample server
uses two screens.
And we still think this is more of a bug than a feature.... We'd love to
fix it, but beating on vendor-specific drivers is very low on our list.
And believe it or not it's a fine way to get work done.
Two of the reasons why it has been so useful in the past are:
1. The demonstration, portable color code that MIT was shipping was
basically useless for day-to-day use.
2. It simulated rooms.
Other people have solved the first problem themselves, and, as we noted
several weeks ago, so have we for R4 (i.e. if you need a high speed server
now, there are various vendors who would be glad to help you). As for rooms
and other ways of extending your screen space, that's one of the directions
in which many window managers (including gwm if you want one now) are moving.
It's not our intention to come off as twits on this issue (and yes we use a
cgfour), but this is case of trying not to fall into the trap of slapping
lots of band-aids on problems that require more serious treatment.
When you open a display you can set the default *screen*, but not the
default *visual*.
You set the default screen since different physical screens are likely to be
in different locations (even if side by side). The logical screen hack that
David Rosenthal implemented for the cgfour was very clever, but as he has
argued over and over again, there are much better solutions.
This seems to me to be a strong indication that the resource defaults
should be organized along the same lines.
Perhaps, but not necessarily. There are several schools of thought on how
the application should express its preferences for visuals and whether the
visual should be fit to the resources or the other way around. When you
include applications that use multiple visuals (which is actually a very
reasonable thing to do: an imaging application will probably want to use
Pseudo- or StaticColor for its user interface regions and Direct- or
TrueColor for its images) the problem gets thorny.
The relevant code is in XOpenDisplay, which takes a display
name and a screen number (as name:number, natch). How hard would it be to
make it look at the screen number rather than assuming 0 when it loads its
resources? Jeez, it looks easy to me. Shall I post diffs? :-)
No thank you, I think I can find my way around.... :-)
More importantly, ease of implementation is irrelevant in this case.
Another part of the problem is that the way in which resources are located is
part of the Xlib standard. Just changing it in MIT's sources isn't enough.
As someone pointed out several days ago (and which we've been trying to
get people to believe for a long time), MIT is just one player (admittedly,
one with a very loud mouth :-) in the X game.
Jimgaryo@THINK.COM (Gary Oberbrunner) (09/27/89)
Sorry if this gets to you twice, Jim. My mailer is not too bright. :-)
You write:
...we still think this [dual-screen hack] is more of a bug than
a feature... this is case of trying not to fall into the trap of
slapping lots of band-aids on problems that require more serious
treatment.
I note:
When you open a display you can set the default *screen*, but not the
default *visual*. This seems to me to be a strong indication that
the resource defaults should be organized along the same lines.
You set the default screen since different physical screens are likely
to be in different locations (even if side by side). The logical
screen hack that David Rosenthal implemented for the cgfour was very
clever, but as he has argued over and over again, there are much better
solutions.
Actually my point is independent of David's dual-screen hack. ANY server
with two screens, whether side-by-side, large and small, color & b/w,
logical or physical, will have this problem. Servers with a hi-res and a
lo-res screen will have a different variant of the same problem. And
resolution (I mean width & height in pixels) has nothing to do with
visuals, it's purely a screen issue. At some point you'll *have* to have
some way of specifying resources on a per-screen basis. You may also, as
you point out, need per-visual resource specification. However, the
current Xrdb/XA_RESOURCE_MANAGER method will have difficulty adapting to
per-visual resources, whereas it seems simple and useful to do per-screen
resources now. After all, you'll need them anyway, because visuals don't
capture some of the variables you might want to conditionalize on (like
screen size).
Another part of the problem is that the way in which resources are
located is part of the Xlib standard. Just changing it in MIT's
sources isn't enough. As someone pointed out several days ago (and
which we've been trying to get people to believe for a long time), MIT
is just one player (admittedly, one with a very loud mouth :-) in the X
game.
This is true, but if you take the lead people will follow. If you claim
that it's too hard to 'do it right' and so you're not going to do
*anything* about it until some later release, then nobody else will either.
As always,
Gary O
-----------------------------------------------------------------------------
Remember, Truth is not beauty; Gary Oberbrunner
Information is not knowledge; Beauty is not love; {ames,harvard}!think!garyo
Knowledge is not wisdom; Love is not music; garyo@think.com
Wisdom is not truth; Music is the best. - FZ (617) 876-1111 x265jim@EXPO.LCS.MIT.EDU (Jim Fulton) (09/27/89)
Actually my point is independent of David's dual-screen hack. ANY server
with two screens, whether side-by-side, large and small, color & b/w,
logical or physical, will have this problem.
Yup. However, solving this little piece now still leaves the larger issue to
deal with. Folks have been somewhat reticent about attacking the same
problem several times. Believe it or not, I've wanted to have have
per-screen resources that get merged on top of the XA_RESOURCE_MANAGER
resources for a while now, but haven't had enough answers to the other
problems to justify the issue.
If you claim
that it's too hard to 'do it right' and so you're not going to do
*anything* about it until some later release,
It's not that it's too hard, just that it hasn't been enough of a problem.
However, by being a squeaky wheel, you've undoubtedly gotten people to at
least start thinking about it.janssen@holmes (Bill Janssen) (09/28/89)
In article <8909261934.AA23735@expo.lcs.mit.edu>, jim@EXPO (Jim Fulton) writes: >However, by being a squeaky wheel, you've undoubtedly gotten people to at >least start thinking about it. Let me add a squeak. I run with two screens side-by-side, a color 1152x900 and a monochrome 1200x1600. This means that I cannot use xrdb and still get my fonts and/or colors right, as everything is read off one of the screens. Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
mayer@uffa.wbst128.xerox.com (Jim Mayer) (09/28/89)
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
dshr@SUN.COM (David Rosenthal) (10/04/89)
> You set the default screen since different physical screens are likely > to be in different locations (even if side by side). The logical > screen hack that David Rosenthal implemented for the cgfour was very > clever, but as he has argued over and over again, there are much better > solutions. > Just to re-inforce this point. The ONLY reason why the MIT server on Sun's CG4 displays uses the color and monochrome planes as separate screens rather than as two visuals of the same screen was that when I tried to implement the correct (visuals) approach during the beta-testing of X I found a number of problems in the server code of that time that made doing so too time-consuming. And that since that time I (at least) have not had the time or motivation to go back and do it properly. But it is clear that the two-screens approach is a hack that has outlived its usefulness, and that I was wrong in assigning a low priority to fixing it. David.