Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!snorkelwacker.mit.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.windows.x Subject: Re: Not impressed with MacX Message-ID: <1990Nov29.234724.20829@Think.COM> Date: 29 Nov 90 23:47:24 GMT References: <9011290612.AA00580@lightning.McRCIM.McGill.EDU> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 104 In article <9011290612.AA00580@lightning.McRCIM.McGill.EDU> mouse@LIGHTNING.MCRCIM.MCGILL.EDU writes: >>> One of Apples 'enhancements' is that instead of typing in your host >>> name, display number, etc you put -display "(R)display" in the >>> command and the actual name will be substituted at execution. Gee, >>> that's wonderful - why can't Unix let you do that? Gosh us Apple >>> owners have an advanced system... >I tend to agree; it's a poor substitute for having a real operating >system with some analog to a DISPLAY environment variable (as an >example of such an analog, consider logical names under VMS). Even on "real" operating systems environment variables don't cross machine and OS-type boundaries. The problem this is trying to solve is that the user is issuing the command on one system (the Mac) but it will be executed on some other system, which could presumably be running any OS. What's needed is a standard protocol for running remote X clients in such a way that the display identity is passed along in an OS-independent manner. MacX is presumably using some de facto standard protocol such as the BSD rexec() mechanism; all this can do is pass the user name and a command line, so even if the Mac had environment variables it couldn't pass them. Substituting into the command line seems like a reasonable workaround for this missing protocol. Similar kludges are used in the Unix world. We have an "xrsh" shell script that invokes rsh but adds commands to the command line that set DISPLAY on the remote system (appropriate handling special cases such as "unix:"). It's no less a kludge than the mechanism MacX uses. >Seems to be xinit should put hostname:0 (or something similar) into the >DISPLAY environment variable. > >What, no xinit analog? No hostname either? No $DISPLAY analog, even? >Gosh you Apple owners have an advanced system.... What are you talking about? Of course there's a $DISPLAY analog: what do you think it replaces "(R)display" with? The problem is that the xinit analog is run on a different host from the clients. >> I agree that borderwidth is not an intuitive option; however, how >> would you have specified the window style from Unix? >I wouldn't expect to. That's a window manager function; I expect to >control it by telling the *window manager* things, not by telling the >*client* things! OK, so how would you tell the window manager these kinds of things? In general, it is done by telling the client (e.g. with the -geometry option), who then tells the window manager. I suppose it could be done interactively in a manner analogous to placement, but just as a client can provide defaults to the WM or ask it not to provide manual placement, it should be able to specify defaults and suggestions for border options. The problem here is that this window manager provides capabilities that clients aren't yet prepared to control. >How about the way everybody else does it? You start the X server, it >takes over your screen, keyboard, and mouse, and there you are. No >fash with a root window that is actually inside a Mac window, or is >partly invisible because of multiple monitors, or doesn't even exist. If the X server takes over the display completely, how do you use all your Macintosh applications? Maybe someday the Macintosh toolbox will be able to translate Window Manager calls into X operations while the X server has control of the display, but that day isn't here yet. Until then, the X server must coexist with the builtin window manager. >(Multiple monitors should be separate screens. If the hardware >differs, they should offer visuals with different capabilities.) That's a matter of opinion. The Macintosh OS designers decided to treat multiple monitors as pieces of a big virtual display. This allowed existing applications to make use of them immediately. >>> These are irritating, but the kludge on the mouse buttons is >>> downright awful. Given that the Mac mouse has one button, how would >>> you simulate the three usually found on Unix boxes? > >I've already addressed this in another post. In short: make the X >pointer device match reality - make it have only one button. You're right, by the "mechanism, not policy" rule. But at least admit that it is a hard problem. The actual situation is that most clients have an implicit expectation of minimal functionality from the X server. As far as these clients are concerned, an X server without less than three buttons is as crippled as one without an "A" key. Before we trash all the clients that expect three buttons, how about all the ones that require *color*, and don't fall back to patterns when confronted with a monochrome display. I'm getting sick of all these X-based network management packages that insist on using color, since I am not likely to be upgrading my Lisp Machine to color. >> The MIT X11 server [...]. >There's an MIT X11 server for the Mac? Where and how can one get it? I think assume he was referring to the one that runs under A/UX, which I think has been around for a while. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar