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