Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!bloom-beacon!EXPO.LCS.MIT.EDU!jim From: jim@EXPO.LCS.MIT.EDU (Jim Fulton) Newsgroups: comp.windows.x Subject: Re: Why is resouce manager property only set on Screen 0 ? Message-ID: <8909261831.AA17431@expo.lcs.mit.edu> Date: 26 Sep 89 18:31:27 GMT References:Sender: daemon@bloom-beacon.MIT.EDU Organization: X Consortium, MIT Laboratory for Computer Science Lines: 65 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. Jim