hrf900@fac5.anu.oz.au (Hugh Fisher) (11/28/90)
There've been a lot of postings about X on the PC, so I thought people might be interested in the Apple side of personal computing. Here is a quick review of MacX. MacX is an X11 Release 4 server by Apple, which comes with MacTCP for the actual networking. It will run on any Macintosh with System 6 and requires 2M of RAM. I tried it on an SE/30 with an EtherNet adaptor.It costs $A275, which I guess is $150-$200 in the US of A. MacX is not the same as the X Windows development tools available for A/UX - it is just a server for users of X clients. Installing is easy enough: drag everything onto your hard disk and reboot so that the communications INITs are working. After that you just launch MacX like any other application. You connect to a client program by issuing a 'Remote Command', filling in a dialog with details of the host, your userid, and the command itself, eg "xterm -display "Opus:0" -sb". This is a bit tedious, but once set up you can save the lot and it becomes a regular menu option, so now I just choose "xterm" from the menu and the connection is made automatically. Once you've got xterm open you can start other clients yourself. The server seems quick enough on the SE/30, with response time on tasks such as xeyes tracking and pop up menus comparable to a Sun 3/80. The main problem was the tiny screen. So much for the good points, on to criticism which is more fun. 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... Next is window management. Using the Apple window manager, you have a choice of Mac-style window adornment, document without grow box, document with grox box and zoom, etc. You can choose these from the menu at any time, but Apple have thoughtfully allowed you to specify these on the command line as well. How? With the -borderwidth option, of course! Isn't it obvious that -bw 2 means round cornered rectangle window? Then there are the multiple screens. The default in MacX is that there is no root window, all your X stuff just floats on the desktop and is managed by the Mac Toolbox like the others. To run an X window manager, you need a root window, which is one big Apple window which all the others get put in. You also have to specify that the clients be added to this root window, by using screen number 1 (3 for color) instead of the default. If you really do have multiple screens attached to your Mac, they are treated as one big screen and cannot be referred to individually. 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, and all the programmers I asked this, expected some sort of command-shift option as you press the button. What you actually do is press the option and left arrow keys to simulate the middle button and and option-right arrow for the right (You can change this to just left arrow or right arrow, but then those keys don't work normally.) So, to get the middle button menu in twm you hold down the option and left arrow keys with one hand, move the mouse down the menu with the other, and release the keys when the mouse is over the item you want. ACK! In conclusion, I think that MacX would be good value if you just wanted to look at the output from X clients, but I wouldn't recommend it as a substitute for an X terminal. Disclaimer: these opinions are entirely my own, not my employers.
coolidge@cs.uiuc.edu (John Coolidge) (11/29/90)
[Crossposting to comp.unix.aux added, as MacX will be bundled with A/UX in the next release] hrf900@fac5.anu.oz.au (Hugh Fisher) writes: >So much for the good points, on to criticism which is more fun. >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'm not sure I understand this: do you like, or dislike, this feature? It's certainly appreciated by me: I use MacX under A/UX and keep the preferences file in an NFS volume. With the (R)display option I can use the same MacX setup no matter which machine I'm logged into, instead of having to switch setups for each mac. >Next is window management. Using the Apple window manager, you >have a choice of Mac-style window adornment, document without >grow box, document with grox box and zoom, etc. You can choose >these from the menu at any time, but Apple have thoughtfully >allowed you to specify these on the command line as well. How? >With the -borderwidth option, of course! Isn't it obvious that >-bw 2 means round cornered rectangle window? I agree that borderwidth is not an intuitive option; however, how would you have specified the window style from Unix? The set of command-line options to X programs is already established, and there isn't a window-style option; on the other hand, the border width option doesn't make any sense when describing Mac style windows, which already have a set appearance. On the whole I find this a fair if unappealing compromise. An alternative might have been to require a '.windowstyle' declaration in the resources database or a per-client setting in MacX; however, that doesn't address setting style from the command line. It also doesn't address having clients with multiple window styles (I'm running epoch with two different styles, for instance). >Then there are the multiple screens. The default in MacX is >that there is no root window, all your X stuff just floats on >the desktop and is managed by the Mac Toolbox like the others. >To run an X window manager, you need a root window, which is >one big Apple window which all the others get put in. You also >have to specify that the clients be added to this root window, >by using screen number 1 (3 for color) instead of the default. >If you really do have multiple screens attached to your Mac, >they are treated as one big screen and cannot be referred to >individually. Again, how would you prefer things to be arranged? There are clearly at least two required screens: rooted and rootless. Color and B/W are useful options as well. Making b/w rootless the default (0.0) seems to be reasonable to me; that's almost the only mode I ever use (on color machines I'll occasionally use 0.2). While it would be nice to address multiple physical screens directly, the utility of having the different display modes easily selectable outweighs it for me. >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, >and all the programmers I asked this, expected some sort of >command-shift option as you press the button. What you actually >do is press the option and left arrow keys to simulate the >middle button and and option-right arrow for the right (You >can change this to just left arrow or right arrow, but then >those keys don't work normally.) This is the X11 way of mapping middle and right buttons on the Mac keyboard. The MIT X11 server uses the same system; thus, MacX is not to blame for the policy. It might be nice to have the option of using modifiers and the mouse button; however, how would you represent shift-left, control-left, etc. in that case? My only gripe about the keyboard is the brain-damaged policy of putting meta on the uparrow key instead of on option (where it is in the MIT server); this causes me no end of grief with emacs. It would be very nice if this were a configurable option instead of the only game in town. I'd rather have to go over to the arrow keys to find options than go over there to find meta... >In conclusion, I think that MacX would be good value if you just >wanted to look at the output from X clients, but I wouldn't >recommend it as a substitute for an X terminal. It depends on your application. I like to be able to use mac tools, CommandShell, etc. I can't do that with full-screen X11R4 and I can't do it on an X terminal, and there's only so much real estate on my desk what with the piles of manuals, papers, CD's, disks, etc... :-). MacX is a very good compromise between not having X and not having the mac as a mac --- and I'd be quite unhappy without epoch and a few other X tools :-). --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1990 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well.
cwilson@NISC.SRI.COM (Chan Wilson [Animal]) (11/29/90)
In article <1990Nov28.150000.3600@csc.anu.oz.au> hrf900@fac5.anu.oz.au (Hugh Fisher) writes: >There've been a lot of postings about X on the PC, so I >thought people might be interested in the Apple side >of personal computing. Here is a quick review of MacX. [....] >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, >and all the programmers I asked this, expected some sort of >command-shift option as you press the button. What you actually >do is press the option and left arrow keys to simulate the >middle button and and option-right arrow for the right (You >can change this to just left arrow or right arrow, but then >those keys don't work normally.) I think awful is a bit harsh for the mouse button kludge. I've been using MacX and X11R4 constantly for about 3 months now, and I would much rather see the current setup than some seriously derranged command-shift hack. After using X for a while, there actually begins to be a glimmering of logic behind the layout. The mousebutton itself is the first button. <- is the second button. -> is the third button. All in a nice row. But hey, it's obviously a matter of taste. Me myself, this topic will become irrelivent as soon as my 3 button mouse comes in. Then I just need to unpatch the server so I've got the arrow keys back and option is enabled. For those of you interested in 3 button mice for Macs running X windows, contact Advanced Gravis at 800/663-8558. The only 3 button mouse for Macs running X windows. (yah, i'm aware of the 3 button mouse for macivory.) Enjoy! --Chan Chan Wilson Chief Hard-Question Answer Person SRI Intl. Network Information Systems Center 333 Ravenswood Ave., EJ287 Internet: cwilson@nisc.sri.com Menlo Park, CA., 94025 Phone: (415)859-4492 "If I want to be a surfer this month, I bloody well will be."
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (11/29/90)
> MacX is [...]. > So much for the good points, on to criticism which is more fun. Ain't it though? :-) > [T]he 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 know this was a rhetorical question, but I can't resist answering it anyway. I wouldn't simulate them. I would have the X server provide a pointer device with only one button. That's what you have, after all. Kludges to support broken clients that blindly assume the presence of (at least) three buttons on the pointer device only ensure that said broken clients don't get fixed. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (11/29/90)
[ re MacX ] >> 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'm not sure I understand this: do you like, or dislike, this > feature? Well, he *did* put it under "criticism", and the wording is a bit overblown. I think he's criticizing. 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). > It's certainly appreciated by me: I use MacX under A/UX and keep the > preferences file in an NFS volume. With the (R)display option I can > use the same MacX setup no matter which machine I'm logged into, > instead of having to switch setups for each mac. 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.... >> Next is window management. Using the Apple window manager, you have >> a choice of Mac-style window adornment, document without grow box, >> document with grox box and zoom, etc. You can choose these from the >> menu at any time, but Apple have thoughtfully allowed you to specify >> these on the command line as well. How? With the -borderwidth >> option, of course! Isn't it obvious that -bw 2 means round cornered >> rectangle window? > 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! >> Then there are the multiple screens. The default in MacX is >> [rootless - X windows are Mac windows]. To run an X window manager, >> you need a root window, which is one big Apple window which all the >> others get put in. If you really do have multiple screens attached >> to your Mac, they are treated as one big screen and cannot be >> referred to individually. > Again, how would you prefer things to be arranged? 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. (Multiple monitors should be separate screens. If the hardware differs, they should offer visuals with different capabilities.) >> 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. > The MIT X11 server [...]. There's an MIT X11 server for the Mac? Where and how can one get it? > My only gripe about the keyboard is the brain-damaged policy of > putting meta on the uparrow key instead of on option (where it is in > the MIT server); this causes me no end of grief with emacs. It would > be very nice if this were a configurable option instead of the only > game in town. Good heavens, can't you xmodmap it back to something saner? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
x@springer.Apple.COM (Steve Peters) (11/30/90)
In article <9011290206.AA00343@lightning.McRCIM.McGill.EDU>, mouse@LIGHTNING.MCRCIM.MCGILL.EDU writes: |> I wouldn't simulate them. I would have the X server provide a pointer |> device with only one button. That's what you have, after all. |> |> Kludges to support broken clients that blindly assume the presence of |> (at least) three buttons on the pointer device only ensure that said |> broken clients don't get fixed. We thought about this, briefly, very briefly. A quick poll of our field convinced us that we we would never again sell an X product if we were to adopt such an approach. The hard, ugly, X reality ( ;-) ) is dressed with 3 buttons. -- Steve Peters X Project Leader Apple Computer, Inc. peters@apple.apple.com
zimmer@cod.NOSC.MIL (Thomas L. Zimmerman) (11/30/90)
>complaints about the way MacX treats the display variable, window boarders >rooted vs. non-rooted windows, etc. The folks doing the complaining seem to be missing the whole point of MacX. It is not intended to be a consistent X environment like that on a UNIX workstation. For that you can run A/UX and real X11R4. In that environment X Windows works exactly like it does on my Sun (except for the stupid one button mouse). MacX does do some things different than a normal X Server, but I consider these to be valid enhancements or compromises - especially when you consider that the majority of Macintosh users are not "power users". MacX is an excellent attempt at bringing the ability to run X Windows to the "rest of us". It should be easy to use and primarily it should complement the MacOS environment. Thus the preference for rootless windows, default display variable passing, and the rest of the differences cited. I have both a MacFX and a SPARCStation. The mac normally runs the normal MacOS and I make heavy use of MacX to talk to the Sun. The Sun runs X Windows all the time. I move back and forth regularly and have no problems (exceptt the mouse :-)). I love being able to mix up the X windows clients with my favorite Mac applications. If MacX worked like many of you seem to think it should all I would have is a very expensive X terminal. (I know, some people think that would be an improvement :-)) I suspect we will see this same issue when the X Servers for Windows become generally available and I predict that the poor braindead people who like DOS and Windows ;-) aren't going to want to give up their applications just to run X either. -------------------------------------------------------------------------- Lee Zimmerman zimmer@nosc.mil Naval Ocean Systems Center, Advanced Concepts and Development Branch -------------------------------------------------------------------------- -- Lee Zimmerman, Naval Ocean Systems Center, Code 421, San Diego, CA, 92152 {arpa,mil}net: zimmer@nosc.mil uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!zimmer
barmar@think.com (Barry Margolin) (11/30/90)
In article <1990Nov28.234514.9078@julius.cs.uiuc.edu> coolidge@cs.uiuc.edu writes: >hrf900@fac5.anu.oz.au (Hugh Fisher) writes: >>Isn't it obvious that >>-bw 2 means round cornered rectangle window? >An alternative might have >been to require a '.windowstyle' declaration in the resources >database or a per-client setting in MacX; however, that doesn't >address setting style from the command line. It also doesn't >address having clients with multiple window styles (I'm running >epoch with two different styles, for instance). Standard Unix X clients accept an argument (I think it's "-rm") that allows arbitrary resource settings to be specified for that client. Wouldn't that address setting style from the command line and having clients with different styles? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
barmar@think.com (Barry Margolin) (11/30/90)
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:<whatever>"). 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
erc@pai.UUCP (Eric Johnson) (11/30/90)
Problem: The Macintosh has a one-button mouse, but far too many X programs require a three-button mouse. That's also why PC X terminal emulators and HP (both of which extensively use two-button mice) emulate the "middle" mouse button (button 2) by having the user hold down both physical mouse buttons at once. Der mouse, who usually gives great advice, doesn't want to emulate "missing" mouse buttons: In article <1990Nov29.110947@springer.Apple.COM>, x@springer.Apple.COM (Steve Peters) writes: > In article <9011290206.AA00343@lightning.McRCIM.McGill.EDU>, > mouse@LIGHTNING.MCRCIM.MCGILL.EDU writes: > |> I wouldn't simulate them. I would have the X server provide a > pointer > |> device with only one button. That's what you have, after all. > |> > |> Kludges to support broken clients that blindly assume the presence > of > |> (at least) three buttons on the pointer device only ensure that said > |> broken clients don't get fixed. Unfortunately, from xterm on, just about every client that uses the mouse uses more than one button. Most Athena wdiget-based programs, such as xterm, use button 1 to select and button 2 to paste (they could probably do without button 3). Most window managers, including twm, use more than one mouse button for various purposes. Twm also has an extensive set of Meta-button functions--although twm is much better than uwm in this regard. (Mwm seems better in using mouse buttons.) Now, I know all this can be configured, but it's a mighty pain. And, just try to explain all this mess to new users. Ugh. I agree that the programs should be changed to provide simpler interfaces that use the mouse in a less confusing manner (new users typically have a hard time determining which mouse buttons do what). But, will these X clients change? Probably not. Even if I were to volunteer :-), I have a feeling that the X Consortium has a lot more say about programs like xterm and the Athena widget set than I do. Same with the OSF for Motif and AT&T/Sun for Open Look. The bottom line: we're stuck with three-button mice. If you don't have a three-button mouse (which I don't when using a PC as an xterm under Hummingbird's software), you have to emulate a three-button mouse, or else you won't be nearly as productive using X, as you would be using a three-button mouse. ("Won't be nearly as productive" is a euphemism for "life will be hell.") > We thought about this, briefly, very briefly. A quick poll of our field > convinced us that we we would never again sell an X product if we were > to adopt such an approach. The hard, ugly, X reality ( ;-) ) is dressed > with 3 buttons. > Steve Peters > X Project Leader > Apple Computer, Inc. > peters@apple.apple.com By the way, with Macintosh emulations of X, I've had a much better time using the large Apple keyboard, often called the "Saratoga" keyboard (named after the aircraft carrier because of the large size). I didn't like my arrow keys being eaten up since I use text editors a lot. (The standard Mac scheme was that the <- and -> keys, I believe, act as mouse keys, while [SpecialKey]<- and [SpecialKey]-> gets you the real arrow keys. I personally like arrow keys that act as arrow keys.) The "Saratoga" keyboard looks a lot like a PC-style keyboard, although many Mac folks would hate to admit that. Have fun, -Eric -- Eric F. Johnson phone: +1 612 894 0313 BTI: Industrial Boulware Technologies, Inc. fax: +1 612 894 0316 automation systems 415 W. Travelers Trail email: erc@pai.mn.org and services Burnsville, MN 55337 USA
rmtodd@servalan.uucp (Richard Todd) (11/30/90)
mouse@LIGHTNING.MCRCIM.MCGILL.EDU writes: >> It's certainly appreciated by me: I use MacX under A/UX and keep the >> preferences file in an NFS volume. With the (R)display option I can >> use the same MacX setup no matter which machine I'm logged into, >> instead of having to switch setups for each mac. >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.... Well, MacX was written for MacOS, which by the standards you and I use doesn't even come close to being an advanced operating system :-). It is interesting that, even for those using MacX under A/UX, they don't have some sort of xinit equivalent (or just have the standard xinit with a config file setup to launch MacX, since it *is* possible to start up MacOS programs under A/UX from the shell prompt...) >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! Alas, they seem to be providing by default that is just as configurable as is the standard window management facilities of MacOS -- i.e., not at all. >>> Then there are the multiple screens. The default in MacX is >>> [rootless - X windows are Mac windows]. To run an X window manager, >>> you need a root window, which is one big Apple window which all the >>> others get put in. If you really do have multiple screens attached >>> to your Mac, they are treated as one big screen and cannot be >>> referred to individually. >> Again, how would you prefer things to be arranged? >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. >(Multiple monitors should be separate screens. If the hardware >differs, they should offer visuals with different capabilities.) Ah. Well, they obviously could have done this that way, but evidently one of the design goals of MacX is that it *doesn't* take over the screen--you still have access to those MacOS applications that are still running and can "see" them (and, if necessary, click on their windows and interact with them). (Rumour has it that they even manage to support cut-and-paste between X applications and MacOS ones properly; that sounds like a decidedly non-trivial bit of programming...) This simultaneous access pretty much demands that you have the individual X windows appear as MacOS windows and handled by a MacOS-style window manager; the "root window" approach is evidently a concession for those Wrong Thinkers who stubbornly prefer to use twm, etc., instead of the MacOS style of window management. >> The MIT X11 server [...]. >There's an MIT X11 server for the Mac? Where and how can one get it? Same place as you get MIT X11 for a Sun, etc. : expo.lcs.mit.edu or other friendly archive site that has the X11R4 distribution. Of course, the X11R4 distribution only will compile under Unix (A/UX) and not MacOS, and can't share the screen with MacOS. But if (like me) you think a Mac without Unix is just an overpriced paperweight, and you only use MacOS applications on rare occasions, it's terrific. (As it happens, I'm running MIT X11R4 and writing this message with Epoch right now on my Mac IIx....) I should mention here that Apple also sells their own X11R4 package for A/UX, which reportedly includes some internal Consortium bug fixes that won't make it out publically until X11R5 (whenever that materializes) plus assorted speedups; it's also a good deal for those who aren't up to or don't have the disk space to compile MIT X11R4 themselves. >> My only gripe about the keyboard is the brain-damaged policy of >> putting meta on the uparrow key instead of on option (where it is in >> the MIT server); this causes me no end of grief with emacs. It would >> be very nice if this were a configurable option instead of the only >> game in town. >Good heavens, can't you xmodmap it back to something saner? Dunno, but I will add a small correction of fact: meta isn't mapped to the option key under MIT X11R4; it's mapped to the "Command" key, whose function is already spoken for under MacOS. In summary, I'd like to say this: MacX certainly looks like it has a good deal of what we Unix X types would call braindamage. But given that it has to work under a thouroughly braindamaged operating system, and that the design goal was to make X applications fit in well with the MacOS environment, they probably did as good a job as one has any hope to expect. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Cancelling a posted message means posting a cancel message."-Maarten Litmaath
liam@cs.qmw.ac.uk (William Roberts) (12/01/90)
My only "purist" complaint about MacX is that it tells lies: the information returned when you make a connection always claims to support colour (and may even lie about the screen size). The Mac system knows the truth, so why doesn't MacX? My non-purist complaint is that MacX doesn't seem able to use the fonts already installed in the System, requiring you instead to duplicate everything. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)
abm@alan.aux.apple.com (Alan Mimms) (12/01/90)
In article <1990Nov29.230100.18696@Think.COM>, barmar@think.com (Barry Margolin) writes: |> In article <1990Nov28.234514.9078@julius.cs.uiuc.edu> coolidge@cs.uiuc.edu writes: |> >hrf900@fac5.anu.oz.au (Hugh Fisher) writes: |> >>Isn't it obvious that |> >>-bw 2 means round cornered rectangle window? |> >An alternative might have |> >been to require a '.windowstyle' declaration in the resources |> >database or a per-client setting in MacX; however, that doesn't |> >address setting style from the command line. It also doesn't |> >address having clients with multiple window styles (I'm running |> >epoch with two different styles, for instance). |> |> Standard Unix X clients accept an argument (I think it's "-rm") that allows |> arbitrary resource settings to be specified for that client. Wouldn't that |> address setting style from the command line and having clients with |> different styles? I hope to be able to correct this and a few other things at which people are sniping about MacX in a future release (can you say "2.0"?). Good suggestion, and it's one that was obvious from approximately the day AFTER the last possible date that such things could be changed in MacX 1.0 during the "now I've got time to catch my breath" stage just before MacX shipped. Such is life when products are produced by too few people working too hard. |> -- |> Barry Margolin, Thinking Machines Corp. |> |> barmar@think.com |> {uunet,harvard}!think!barmar -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Bonzai "Never rub another man's rhubarb" -- The Joker in BatMan
abm@alan.aux.apple.com (Alan Mimms) (12/01/90)
In article <2776@redstar.cs.qmw.ac.uk>, liam@cs.qmw.ac.uk (William Roberts) writes: |> My only "purist" complaint about MacX is that it tells lies: the information |> returned when you make a connection always claims to support colour (and may |> even lie about the screen size). The Mac system knows the truth, so why |> doesn't MacX? Because MacX can display output from color-only clients (of which there are a FEW) on a monochrome screen (either depth converting or not) it is pretty reasonable to lie about this. Especially since MacX is set up to permit choice of color or monochrome visuals by choice of "screen number". |> |> My non-purist complaint is that MacX doesn't seem able to use the fonts |> already installed in the System, requiring you instead to duplicate everything. I would suggest you RTFM. MacX has full support of the System file's fonts, available and reorderd into ISO-Latin/1 for you as you like. You can assign them X-style names using the Font Director's alias functionality or use them using the normal MacX naming convention for the (i.e., "Chicago-12"). |> -- |> |> William Roberts ARPA: liam@cs.qmw.ac.uk |> Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP |> Mile End Road AppleLink: UK0087 |> LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533) -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Bonzai "Never rub another man's rhubarb" -- The Joker in BatMan
mikey@sgi.com (Mike Yang) (12/02/90)
In article <9011290206.AA00343@lightning.McRCIM.McGill.EDU> mouse@LIGHTNING.MCRCIM.MCGILL.EDU writes: >I wouldn't simulate them. I would have the X server provide a pointer >device with only one button. That's what you have, after all. > >Kludges to support broken clients that blindly assume the presence of >(at least) three buttons on the pointer device only ensure that said >broken clients don't get fixed. I'm sorry, but this is just getting silly. While I understand your attempt to accomodate the "lowest common denominator" the sad fact is that almost all X configurations have three-button mice. Unfortunately, most Macintoshes do not. Where do you draw the line? Motif tries to handle the case on configurations with no mice at all. Do you propose that all non-Motif applications which assume that there is a mouse "fix" themselves so that they no longer do? Some applications can get by quite easily with using only the left mouse button. However, for those that can't, hindering those users with a "standard" configuration is unacceptable. Special handling of the rare case in the application itself is also wrong, since the extra work needs to be duplicated among all applications, and will most likely be done in an inconsistent manner. It is unfortunate that the Mac has a one-button mouse as a standard, just as HP systems have a two-button mouse. However, their X server designers made the right decision in providing a "standard" method of simulating the extra buttons. The users may not like it, but the solution was the best. Thankfully, I work for a company where the LCD system has 8-plane color and a three-button mouse. ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (12/02/90)
In article <1990Dec1.200407.17688@relay.wpd.sgi.com> mikey@sgi.com (Mike Yang) writes: >It is unfortunate that the Mac has a one-button mouse as a standard, >just as HP systems have a two-button mouse. WRONG! HPs have whatever I/O devices you order them with. Before X, HP promoted a two-button mouse. With the advent of X, three button mice were made available, and there's all sorts of other devices that you can throw onto HP's Human-Interface Loop (HIL) as well, e.g. trackballs, pucks, styluses, knob boxes, button boxes, or whatever. I personally dislike mice, so I use a three button trackball instead (HP Part # M1309A). There's also an HIL-to-quadrature adaptor available that will allow you to interface to PC input devices that you can find at your local/mailorder microcomputer supplier. (PS: Don't ask me for part numbers and more info -- call your HP sales rep) ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (12/03/90)
> Problem: The Macintosh has a one-button mouse, but far too many X > programs require a three-button mouse. [That's why servers using > mice with fewer than three buttons often fake the "missing" ones.] > Der mouse [...] doesn't want to emulate "missing" mouse buttons: >>> I wouldn't simulate them. I would have the X server provide a >>> pointer device with only one button. That's what you have, after >>> all. Kludges to support broken clients that blindly assume the >>> presence of (at least) three buttons on the pointer device only >>> ensure that said broken clients don't get fixed. > Unfortunately, from xterm on, just about every client that uses the > mouse uses more than one button. That doesn't mean they aren't broken. To pick an analogy in another realm, NULL is traditionally defined as 0, and much of the X code uses it in contexts where integer 0 is desired. Does this then mean that NULL must always be 0? No, it means that there's a lot of broken code around. See also the "all the world's a VAX" syndrome (which is now, mercifully, beginning to fade away (to be replaced by "all the world's an 8086 :-)). (Try building X on a machine which has NULL defined as (void *)0 and you'll see what I mean.) For that matter, I have seen at least three X clients that break if you don't use PointerRoot focus, in that if the mouse is not inside their window they ignore keystrokes, even if the window manager has given the keyboard focus to the window in question. Shall we therefore require all window managers to use PointerRoot focus? Just because a given brokenness is widespread doesn't make it any less broken. And since I, unlike >> We thought about this, briefly, very briefly. A quick poll of our >> field convinced us that we we would never again sell an X product if >> we were to adopt such an approach. The hard, ugly, X reality ( ;-) ) >> is dressed with 3 buttons. >> X Project Leader >> Apple Computer, Inc. don't have a customer base that must be catered to no matter how unreasonable they get, I can refuse to support such brokenness. My X11R4 on the NeXT presents a pointer device with only two buttons. I have received two different patches to implement the "missing" button by chording the two existing buttons. Neither one will go in (though I will distribute them with the thing, once I get around to rebuilding the distribution.) In another note, someone from SGI said that it had the luxury of always being on an 8-bit PseudoColor server with a 3-button mouse. I can just see programs from such a person[%] blindly assuming an 8-bit PseudoColor visual as the default. Does this then mean that all servers must provide an 8-bit PseudoColor visual? No, it means that such programs are broken! X has always promised the existence of a pointer device. I'm not sure whether it promises the existence of at least one pointer button. It has never promised more than one button. [%] I don't remember who this person was, and don't mean this personally - I have no basis for judging the portability of your code, never having seen any of it. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
raveling@Unify.com (Paul Raveling) (12/04/90)
In article <1990Nov29.110947@springer.Apple.COM>, x@springer.Apple.COM (Steve Peters) writes: [About 1-button mice] > ... The hard, ugly, X reality ( ;-) ) is dressed > with 3 buttons. My view is that the ugliest part of reality is that some [Apple] systems have a mouse with only one button. Given a choice of using additional buttons or modal coding via multiple clicks or shift keys, extra buttons are easier to use. In fact, sometimes I even wish for a 5-button mouse -- and X is ready for it, even if "normal" clients aren't. BTW, the one-button mouse was a key factor in my decision a few years ago to buy a PC-AT clone instead of a Lisa. Since then Apple's attempt to claim look & feel as its private property has become a bigger reason to avoid an otherwise decent product IM[H?]O. ------------------ Paul Raveling Raveling@Unify.com
mls@cbnewsm.att.com (mike.siemon) (12/04/90)
In article <1557@pai.UUCP>, erc@pai.UUCP (Eric Johnson) writes: > > Problem: The Macintosh has a one-button mouse, but far too many X > programs require a three-button mouse... Der mouse, who usually > gives great advice, doesn't want to emulate "missing" mouse buttons: I didn't read der Mouse that way, but rather as encouraging X programmers to code at a level where functionality maps to hardware with SOME chance of remapping to fit reality. Let me point out (without, I hope, sounding too much like an ad, since my point here is more one of general software architecture) that OPEN LOOK provides (and compliant O.L. applications use) just this scheme -- one's prgram gets SELECT or ADJUST or MENU notifications, and the toolkit sees to mapping these from actual button pushes -- a user may configure to any of 3, 2 or 1 button mice (or can even configure a 3 button mouse to operate like MacX :-)). What OPEN LOOK provides as toolkit *can* be done -- with a bit more work -- by pure X applications. -- Michael L. Siemon In so far as people think they can see the m.siemon@ATT.COM "limits of human understanding", they think ...!att!sfsup!mls of course that they can see beyond these. standard disclaimer -- Ludwig Wittgenstein
mikey@eukanuba.wpd.sgi.com (Mike Yang) (12/04/90)
In article <9012030339.AA05092@lightning.McRCIM.McGill.EDU>, mouse@LIGHTNING.MCRCIM.MCGILL.EDU writes: |> In another note, someone from SGI said that it had the luxury of always |> being on an 8-bit PseudoColor server with a 3-button mouse. I can just |> see programs from such a person[%] blindly assuming an 8-bit |> PseudoColor visual as the default. Does this then mean that all |> servers must provide an 8-bit PseudoColor visual? No, it means that |> such programs are broken! |> |> [%] I don't remember who this person was, and don't mean this |> personally - I have no basis for judging the portability of your |> code, never having seen any of it. I wasn't claiming that applications which assumed 8-bit color are portable and aren't broken. I was just acknowledging the portability problem but pointing out that at SGI, when we develop software for our platforms which *don't* have to work on other vendor's hardware, we thankfully can assume simple things like color. I agree that applications which are meant to run across hardware platforms should work with some lowest common denominator. I just don't agree how with you on how low this should be. ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786
mouse@LARRY.MCRCIM.MCGILL.EDU (12/04/90)
[ MacX, one-button mice, and faking "missing" buttons ] > ... attempt to accomodate the "lowest common denominator" ... > Where do you draw the line? Motif tries to handle the case on > configurations with no mice at all. Do you propose that all > non-Motif applications which assume that there is a mouse "fix" > themselves so that they no longer do? No. X has always promised the existence of a pointer device. It has never promised the existence of at least three buttons on the pointer. (I am not sure whether it promises the existence of any buttons.) IMO, Motif goes overboard if it tries to accommodate servers with no pointer device. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
schoch@sheba.arc.nasa.gov (Steve Schoch) (12/05/90)
In article <9011290206.AA00343@lightning.McRCIM.McGill.EDU>, mouse@LIGHTNING.MCRCIM.MCGILL.EDU writes: |> I wouldn't simulate them. I would have the X server provide a pointer |> device with only one button. That's what you have, after all. |> |> Kludges to support broken clients that blindly assume the presence of |> (at least) three buttons on the pointer device only ensure that said |> broken clients don't get fixed. Related question: I'm using twm. I sometimes use it on a X server with a two-button mouse. Is there anyway to test for this in .twmrc and change the button mapping? Steve
erc@pai.UUCP (Eric Johnson) (12/05/90)
[A discussion regarding systems that have fewer than three mouse buttons
and what to do about it, since so many X programs wrongly assume three
mouse (pointer) buttons are available...]
lightning.McRCIM.McGill.EDU!mouse (der Mouse) writes...
>>> ...I wouldn't simulate them...
>>> ...[if you do simulate the "missing" mouse buttons, it would]
>>> ensure that said broken clients don't get fixed.
I wrote...
>> Unfortunately, from xterm on, just about every client that uses the
>> mouse uses more than one button.
lightning.McRCIM.McGill.EDU!mouse writes...
> That doesn't mean they aren't broken.
No offense, but I really don't care what's considered broken and what
isn't. What I worry about includes time and hassles. How much time and
how much hassle is it going to take to get a working system?
A real example: I tried to set up Interactive's 386/ix with a system
that had a two-button Microsoft mouse. The X version was a customized R3
that ISC delivered and it came with the uwm window manager. (This was a
few versions ago.) Uwm was essentailly unusable out of the box, because
you needed the third mouse button (which was NOT emulated).
The end system was intended for my boss, a new X user at the time. I'm
sorry, but it's rather hard to explain not only how to get X going but
that nothing will work as documented and that everything must be
reconfigured--using a very primitive and confusing configuration
mechanism (for a graphical interface, X is pretty hard to configure).
The ISC people seem to have changed their tune now, but originally they
followed your advice. Maybe you're correct. I don't care (again, no
offense intended). All I know is that the hassle level went way up. Maybe
I should have ported R4 (386 Unix vendors are only now offering R4 and
only some of them at that), because R4 twm is much better with these
issues, but frankly, I didn't have the the time. Again, I care about
time and hassles.
Another real example: Early versions of the Sun OpenWindows X/NeWS server
presented a StaticColor visual as the default, instead of the more common
PseudoColor visual. Technically, the Sun version was correct, and I'm sure
Rosenthal et al could quote all the religious dogma to that effect. I
really don't care. What it meant was that a lot of software (especially
the X contrib stuff) simply wouldn't work. At that point, it didn't matter
who was correct, just that I had to spend a lot of time getting things to
run. Now, I still see no good reason for the StaticColor default. Using a
PseudoColor default would have also been technically correct and would have
made my life a lot easier since I was using a lot of non-technically-
correct software. The bottom line: I was a lot less productive, I wasted a
lot of time and I dealt with a lot of grief (eventually I went back to the
MIT R4 since I only have 8 MB of RAM on my SPARC 1). Yes, that X contrib
stuff should have been "fixed" (and still should be for much of it). I'm
not holding my breath, though.
> For that matter, I have seen at least three X clients that break if you
> don't use PointerRoot focus, in that if the mouse is not inside their
> window they ignore keystrokes, even if the window manager has given the
> keyboard focus to the window in question. Shall we therefore require
> all window managers to use PointerRoot focus?
> Just because a given brokenness is widespread doesn't make it any less
> broken.
You're absolutely right. The problem is, what do you do today? Now, I'd
first like to say that I appreciate all the effort you spend trying to
help people on the net, and help them write "non-broken" X code.
But, when I see statements like "this is broken and should be fixed"
or "get a real computer" (not attributed to you) and the like,
warning flags go up.
I, and a lot of others (at least I suspect a lot) must live in a world
where we need to do work today. All the religious dogma just doesn't sit
well with me. Sure, all this "broken" stuff should be fixed. But, there's
nothing wrong with trying to make things continue to work out in the mean
time. HP, for example, now ships three-button mice. If you happen to have
an old two-button mouse, though, the nice HP folks have a means of emulating
the "missing" button. Is it elegant? I don't know. Is it broken? I don't
care. Is it convenient? Yes. That's the bottom line.
> And since I, unlike...[]...
> don't have a customer base that must be catered to no matter how
> unreasonable they get, I can refuse to support such brokenness.
I don't have this luxury. Furthermore, I don't find it unreasonable
to ask for a graphical environment that works. Our users, who are generally
reasonable, expect the whole system to work right. If it doesn't, it's
our problem. So, I generally don't have the luxury of laying blame either.
It doesn't matter if the problem is in the hardware, the operating
system, the networking interface drivers, the X server or our X clients,
the problem falls into our laps and we have to deal with it. In such
a situation, I don't care who (or what) is to blame, I just want to
get the problem solved.
> My X11R4 on the NeXT presents a pointer device with only two buttons. I
> have received two different patches to implement the "missing" button
> by chording the two existing buttons. Neither one will go in (though I
> will distribute them with the thing, once I get around to rebuilding
> the distribution.)
If I may make a suggestion, maybe then you'll want to "fix" various
pieces of common X software that seem to require a third button.
(I actually think this would be a good idea. Just watch new X
users for awhile and you'll see a lot of confusion when they try
to figure out which mouse button to use.)
> In another note, someone from SGI said that it had the luxury of always
> being on an 8-bit PseudoColor server with a 3-button mouse.
Having a homogenous hardware platform is a nice luxury, but another
luxury I don't have. Perhaps that person at SGI would like to
send me a loaner system?
> I can just
> see programs from such a person[%] blindly assuming an 8-bit
> PseudoColor visual as the default. Does this then mean that all
> servers must provide an 8-bit PseudoColor visual? No, it means that
> such programs are broken!
Encouraging people to write better code is a good thing, and you
seem to do this. Putting up with "broken" things is part of what
I have to do since I live in an imperfect world. Perhaps you don't.
> X has always promised the existence of a pointer device. I'm not sure
> whether it promises the existence of at least one pointer button. It
> has never promised more than one button.
> [%] I don't remember who this person was, and don't mean this
> personally - I have no basis for judging the portability of your
> code, never having seen any of it.
I take no offense at all and hope you don't either. I think, though,
that we come from rather different backgrounds, since our main
differences seem to be one of attitude. When we (BTI) needed to
port our software to UNIX, we knew two things: 1) that we had to
support a number of different architectures and flavors of UNIX and
2) that we absolutely required graphics--lots of graphics (our
package is designed for factory automation). Luckily, C programs are
fairly portable on UNIX-based systems. But, at the time, graphics
was the tough one. After looking around, we saw that our only hope
was using the X Window System (X10 originally). X was available on a
number of platforms and the source was also available, thus allowing
us to port X if the need arose (which it hasn't yet).
X was the only reasonable hope we had at writing graphics-intensive
code that could run on a number of platforms, without rewriting all
the code for each platform.
We didn't choose X because we thought the X model was the "right"
(or one true proper) way to do things. We didn't choose X because
of its network orientation (although that has proven to be a great
advantage). We choose X because it worked and it was the only thing
that worked (i.e., met our criteria).
If I were to look around today, I'd make the same conclusions. X
is still hard to learn. X is still hard to program. X is still hard
to use. But, X is still the only real choice. So, I'm willing to put up
with a lot of things that don't work completely right, so long as
they manage to get the job done.
Maybe now you can see where I'm coming from, even if you don't agree.
Don't take this personally, OK?
> der Mouse
>
> old: mcgill-vision!mouse
> new: mouse@larry.mcrcim.mcgill.edu
Have fun,
-Eric
P.S. Shouldn't it be der Maus (das Maus? -- I don't have my Deutsch/
English dictionary handy)?
--
Eric F. Johnson phone: +1 612 894 0313 BTI: Industrial
Boulware Technologies, Inc. fax: +1 612 894 0316 automation systems
415 W. Travelers Trail email: erc@pai.mn.org and services
Burnsville, MN 55337 USAmattf@cac.washington.edu (Matthew Freedman) (12/06/90)
So far in the discussion of Mac-X under MacOS nobody has mentioned anything about problems with the performance. For my application, the performance is so bad as to make Mac-X unusable. Since nobody else seems to be experiencing these difficulties, maybe I am doing something wrong (I hope so, I really want to be able to support MacX). I have developed a medium size Motif 1.0 application on a DecStation 3100. It has three seperate windows and a moderate number of pull-down menus, buttons, sliders etc. I recently ran it on a Macintosh IIci, under Mac-X, or more precisely ran it on the DecStation, but displayed it under Mac-X. Everything works, but it is *slow*. I mean real slow. It takes on the order of 5-10 seconds just to pull down a menu. And at least 10 seconds to expose a window. Other standard X clients seem to work reasonably fast, although I haven't tried too many. I can't think of any client with the same level of complexity in terms of the number of individual widgets to compare my program against. Does anybody have any ideas what the problem could be? Is it the large number of individual widgets/gadgets that X has to deal with in any application with a nice GUI? Is there something wrong with Motif? Is it just the layering that is going on with Mac-X under finder? Would moving to Motif 1.1 make a difference? Would not running in color make a difference? I haven't tried A/UX yet, has anybody had any experience with Motif displayed in that environment? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = Matthew M. Freedman = = U. of Washington Information Systems mattf@cac.washington.edu = = 4545 15th Ave. NE; 4th Floor (206) 543-5593 = = Seattle, WA 98105 = -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (12/06/90)
I think this has mostly been carried as far as is reasonable in a public list, most of which doubtless is muttering "shut up and stop wasting my bandwidth, already!". So I'll try to restrict myself.... > From: timbuk!cs.umn.edu!sialis!dmshq!com50!pai!erc@uunet.uu.net (Eric Johnson) Eric writes much stuff to the effect of "yes, it may be broken, but we still want something that mostly works today". This is a valid point, and for environments like his[%], faking the missing buttons may be the right thing to do. [%] I feel confident making gender assumptions based on a given name of "Eric". Please feel free to correct me if I'm wrong, Eric.... I suppose what I'm trying to do is to urge people writing new software to ensure that it degrades gracefully - falling back on function keys or double clicks[$] or shift/control/meta clicks or menus or some such. While I think that it would have been better if MacX (to get back to the example that started this) had provided only one button to clients, I certainly understand why they chose otherwise. And though I don't like it, I can see that from their point of view they made the right decision. But I wish it had been an option, turned off by default. [$] I'm trusting that R5 will provide something permitting proper multiple-click support. >> My X11R4 on the NeXT presents a pointer device with only two >> buttons. > If I may make a suggestion, maybe then you'll want to "fix" various > pieces of common X software that seem to require a third button. (Or a second button, for that matter.) That's a good suggestion. There are problems with it. One: I find I don't even have the time to fix the server, or my own clients, that I use, that make the same (invalid) assumption. The other: I do not consider myself competent to fix, say, twm; I would have to understand it first, which would take even more time. >> der Mouse > P.S. Shouldn't it be der Maus (das Maus? -- I don't have my > Deutsch/English dictionary handy)? If it were supposed to be German, I believe "die Maus" would be correct. But it's not; it's actually a contraction of a name my family uses for me. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jmw9681@USAV01.GLAXO.COM ("J. Michael Word") (12/11/90)
I recently had the fortune to witness a demonstration of Mac-X and I was very surprised at the slooooooow speed of the server running on a MacIIfx! Beside it was a 386 running the X server which comes with PCSA and the PC was running several times faster than the Mac. It didn't seem to help if we set the Mac to monochrome either... I'd love to see an explanation for why Mac-X is such a pig. (Given the circumstances, all I could really do to test the performance was run ico. Your mileage may vary.) Mike Word jmw9681@usav01.glaxo.com
mattf@cac.washington.edu (Matthew Freedman) (12/12/90)
In article <9012101615.AA21897@expo.lcs.mit.edu> jmw9681@USAV01.GLAXO.COM ("J. Michael Word") writes: >I recently had the fortune to witness a demonstration of Mac-X and I was >very surprised at the slooooooow speed of the server running on a MacIIfx! >... I'd love to see an explanation >for why Mac-X is such a pig. (Given the circumstances, all I could really do >to test the performance was run ico. Your mileage may vary.) I have been trying to get an explanation for awhile. I have large motif-based application, which we would love to make available to all of our Macintosh users on campus, but it is way to slow. Like 5-10 seconds to pull down a menu, 10 seconds minimum to redraw an entire window. Has anybody had any experience with eXodus from White Pine? Is it any better? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = Matthew M. Freedman = = U. of Washington Information Systems mattf@cac.washington.edu = = 4545 15th Ave. NE; 4th Floor (206) 543-5593 = = Seattle, WA 98105 = -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
abm@alan.aux.apple.com (Alan Mimms) (12/12/90)
In article <9012101615.AA21897@expo.lcs.mit.edu>, jmw9681@USAV01.GLAXO.COM ("J. Michael Word") writes: |> I recently had the fortune to witness a demonstration of Mac-X and I was |> very surprised at the slooooooow speed of the server running on a MacIIfx! |> Beside it was a 386 running the X server which comes with PCSA and the PC |> was running several times faster than the Mac. It didn't seem to help |> if we set the Mac to monochrome either... I'd love to see an explanation |> for why Mac-X is such a pig. (Given the circumstances, all I could really do |> to test the performance was run ico. Your mileage may vary.) |> Ok. This is something I've wanted to get off my chest for a LONG time. I am the one responsible for the pigginess of MacX 1.0's performance in color. Leave it at no one else's door but mine. I did it. It's slow because of a couple of things: (1) MacX works by keeping every top-level (immediate child of the root) rootless window as a separate offscreen pixmap and periodically (very often) copying the resulting (changed parts of the) pixmap using Quickdraw's CopyBits operation into the Macintosh window which is displaying the corresponding X11 window. This duplicated effort of drawing and then copying the bits onto the screen takes some time. (2) I was unaware of a special case in the Copybits call at the time MacX 1.0 shipped which makes it slower than it has to be. Better performance can be had by: making sure the depth and visual supported by the physical screen the MacX windows are on matches what MacX is advertizing to the X11 world (i.e., use an 8-bit color screen for 8-bit color X11 display). Since MacX has the ability to depth-convert on the fly, you may not be aware that this is happening -- and slowing you down big-time. Also, turn OFF the Smooth Animation option in the Miscellaneous Preferences dialog. This serves to batch together copy operations to the screen, improving many types of interactive performance several-fold. The "ico" program is particularly a bad example for MacX because it does a LOT of drawing operations overlapping the same area. If you have smooth animation on, which makes it look smoother but flickery, it slows down a lot. I submit that the cases we optimized for -- typical interaction and pulldown menus and the like -- are the ones you really care about. But they don't resemble ico very much. What all this apparent cruft get you is something which some people see as a mere convenience and other people scream for: the ability for the X11 world to live completely comfortably within the Macintosh windowing world, cutting and pasting text and graphics between the two worlds effortlessly, using Macintosh techniques for all window management things where possible, and generally making the X11 world a bit more familiar for the Macintosh user while also ending up with a very useful X11 server, window manager, font compiler, color management facility, and session manager. That was the goal, and I believe it has been achieved pretty well. I really wanted to spend a lot more time on optimization, but there comes a time when you have to ship SOMETHING or people begin to wonder why you're hanging around all the time without producing any revenue (get the drift?). MacX 1.0 shipped when we all felt that it had the fewest possible bugs (I only know of two even now) and the best feature set and corresponding documentation we could give it. Sure, it's not the ultimate be-all and end-all of X11 servers. Neither was the MIT X11R1 server. Or DECwindows 1.0. Or anybody else's 1.0 of anything I've ever used. Don't think that we're not aware of this: I've been sleeping less and working more because of it. And I have achieved some remarkable speedups in the last 6 months or so since MacX 1.0 shipped and I got back from my vacation. I personally am not that impressed with MacX 1.0's performance either. But it works and is fast enough for pretty much everything I've ever wanted to use it for (and I'm a speed freak). There: I feel better. While I can't really get up for apologizing to everyone for wasting their time (MacX 1.0 it DOES work -- and quite well, I might add), I personally wanted to say WHY. |> Mike Word |> jmw9681@usav01.glaxo.com -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Bonzai "Never rub another man's rhubarb" -- The Joker in BatMan
abm@alan.aux.apple.com (Alan Mimms) (12/12/90)
In article <12775@milton.u.washington.edu>, mattf@cac.washington.edu (Matthew Freedman) writes: |> In article <9012101615.AA21897@expo.lcs.mit.edu> jmw9681@USAV01.GLAXO.COM ("J. Michael Word") writes: |> >I recently had the fortune to witness a demonstration of Mac-X and I was |> >very surprised at the slooooooow speed of the server running on a MacIIfx! |> |> >... I'd love to see an explanation |> >for why Mac-X is such a pig. (Given the circumstances, all I could really do |> >to test the performance was run ico. Your mileage may vary.) |> |> I have been trying to get an explanation for awhile. I have large |> motif-based application, which we would love to make available to all |> of our Macintosh users on campus, but it is way to slow. Like 5-10 |> seconds to pull down a menu, 10 seconds minimum to redraw an entire |> window. Perhaps I can help? I wrote a good fraction of MacX. What communications setup do you have (i.e., are you using TCP on Ethernet or LocalTalk or what)? What kinda CPU? What kinda display device? Where's your client with respect to routers and your Macintosh? What kinda CPU is the CLIENT running on? Motif (especially 1.0) did a HUGE amount of round-trip client requests for practically every possible operation that you'd want to go fast. But for slow communications environments, this is not going to be fast. If you'll give me some more information, I'll try to help you out... |> Has anybody had any experience with eXodus from White Pine? Is it any |> better? I have. It's pretty good. You might want to try it. If you're trying to suck massive bits thru a tiny little 250kbit/sec straw, though, you'll encounter at least as much trouble. Also, I like mine better (sorry Terrell :->). |> |> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- |> = Matthew M. Freedman = |> = U. of Washington Information Systems mattf@cac.washington.edu = |> = 4545 15th Ave. NE; 4th Floor (206) 543-5593 = |> = Seattle, WA 98105 = |> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Bonzai "Never rub another man's rhubarb" -- The Joker in BatMan
stripes@eng.umd.edu (Joshua Osborne) (12/13/90)
In article <1557@pai.UUCP>, erc@pai.UUCP (Eric Johnson) writes: > > Problem: The Macintosh has a one-button mouse, but far too many X > programs require a three-button mouse. That's also why PC X terminal > emulators and HP (both of which extensively use two-button mice) > emulate the "middle" mouse button (button 2) by having the user > hold down both physical mouse buttons at once. [...] Which has got to be one of the worse was of emulating ever invented, or at least what is implmented on the RT. I can press MB1, release then press MB3 (well, the second one on the mouse), the server will send a single MB2 press event. (you have to do this at the right speed, so the whole thing seems flakey untill you figure out what is going on, then you forget all about using the RT for *anything*) Server writers: if you must lie about mouse buttons, fine. Just provide me a way to get the damm things *not* to lie. (other then getting a better mouse, which is also a good option) -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't over-comment" - p151 The Elements of Programming Style 2nd Edition Kernighan and Plauger
abm@alan.aux.apple.com (Alan Mimms) (12/15/90)
[... much stuff which is only very peripherally related to MacX concerning multi-button mouse emulation and flames about applications that assume multi-button mice and flames about flames and flames about the weather and other such stuff...] Do you folks think we could maybe change the SUBJECT LINE associated with this flamewar? I personnally AM impressed with MacX (sorry for lack of modesty). While I think multi-button mice are nice (I have three myself), this really is a somewhat misleading and depressing-to-me subject line for such a discussion :-<... Thanks, by the way, to all (about 10) of you who sent words of encouragement and ego-stroking. I REALLY appreciate it. All this "let's be professional" jive aside, it's nice to know there are SOME people who appreciate what I've done over the last 3 years. Thanks again. -- Alan Mimms (alan@apple.com, ...!apple!alan) | My opinions are generally A/UX X group | pretty worthless, but Apple Computer | they *are* my own... "Laugha whila you can, monkey boy..." -- John Whorfin in Buckaroo Bonzai "Never rub another man's rhubarb" -- The Joker in BatMan
jordan@morgan.COM (Jordan Hayes) (12/16/90)
Mike Word <jmw9681@usav01.glaxo.com> writes:
I recently had the fortune to witness a demonstration of Mac-X
and I was very surprised at the slooooooow speed of the server
running on a MacIIfx!
MacX is running concurrently with the Mac environment. Try running the
X11R4 MIT server (or Apple's raw server) and you'll see much better
performance. On a Mac IIfx running the MIT server, the machine feels a
whole lot faster than a Sun 3/60.
"ico -faces -colors ..." runs respectably even.
/jordanbobo@pecan15.cray.com (Bob Kierski) (12/20/90)
In article <1990Nov28.150000.3600@csc.anu.oz.au>, hrf900@fac5.anu.oz.au (Hugh Fisher) writes: |> |> So much for the good points, on to criticism which is more fun. |> |> 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 found this "Feature" rather to be nice. In a KSTAR environment where your IP address isn't static, it's a pain to have to figure out what your host name is "this week" and change all of your menu entries to match. This was ONE of the bright things Mr. Mimms did. |> ... A few things that you have forgotten to mention are 1) frequently the Apple window manager forgets which window events are supposed to go to and somehow they go to the wrong place. 2) The Apple Window manager isn't ICCCM compliant so it doesn't track IconPixmap, Icon Label, and Window Label properties. 3) Colors aren't represented correctly so if you tell (tv)twm to interpolate menu colors, they look funny. 4) There is no way to get it to listen on any port number other than 6000. |> 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, |> and all the programmers I asked this, expected some sort of |> command-shift option as you press the button. What you actually |> do is press the option and left arrow keys to simulate the |> middle button and and option-right arrow for the right (You |> can change this to just left arrow or right arrow, but then |> those keys don't work normally.) This is a real problem, but for $150 - $300 you can get a 3 button mouse. -- Have a day,