Newsgroups: comp.sys.mac.comm Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!ephraim From: ephraim@think.com (Ephraim Vishniac) Subject: Re: Review of MacX 1.1, X terminal software (long) Message-ID: <1991Apr26.142953.10358@Think.COM> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA References: <320@burr.cs.utexas.edu> Date: Fri, 26 Apr 91 14:29:53 GMT In article <320@burr.cs.utexas.edu> newton@cs.utexas.edu (Peter Newton) writes: > Review of Mac X 1.1 > Peter Newton (newton@cs.utexas.edu) >The opinions expressed herein are my own. I do not represent the >University of Texas. And I don't represent Thinking Machines Corporation, which just purchased a site license for MacX. > Actually, I know of two X-terminal programs for the Mac, eXodus, >and Mac X. The former is by White Pines Software (I think). I know >nothing more about it. Mac X is an Apple product. White Pine Software is located in southern New Hampshire. They make several communication-related products for the Macintosh. >This mostly from an Apple sales brochure... >Features: > - X 11.4 compliant. Usually spelled "X11R4." >Misc. Facts: > - Software installation is much more complex than usual for Mac > programs. If you do not know a little about networks and X-windows, > you could have a bad time. Are terms like IP address, domain, > subnet mask, xterm, client, and server meaningful to you? If > not, you may need to seek help. The installation documentation > is reasonably good. It leads you through the process in a step > by step manner and tells you what information you will need. Actually, it's the installation of MacTCP that's complex. If you've already got MacTCP and the Comm Toolbox installed (as I did), installing MacX itself is a breeze. >2. Our Configuration. My configuration: Mac IIfx with Cayman GatorCard, Radius TPD. No problems. I believe we've got it installed on every model of Mac II at this point, and no-one's complaining. Many users have ethernet cards, some are operating over AppleTalk and through GatorBoxes to reach the ethernet. > 4. User's View of Mac X. > Mac X provides its own window manager. You will not be running > something like twm. The Mac X window manager is nice. It's > Mac-like and works well in the Mac environment. Most X things > assume a 2 or 3 button mouse. Mac X circumvents this problem by > defining arrow keys to work as the second and third buttons. This use of the arrow keys to act as the second and third mouse buttons, combined with Apple's crazed keyboard design, is just excruciating. Some X applications (such as xterm) use the mouse buttons alone for common operations including text selection and pasting, and use control+mouse button for the menus. This probably isn't too bad in MacX if you've got an extended keyboard, which has control keys on both sides. But those control keys are both out of normal reach, so people who actually use the control key (i.e., programmers who run emacs or gnu emacs) do better with the standard keyboard. It has only one control key, placed as God intended :-) to the left of "A." So, picture this: The control key is at the extreme left edge of the keyboard. The arrow keys are slightly more than an octave reach to the right. The mouse can be almost anywhere, but still requires a third hand. This is terminally stupid design. Obviously, nobody at Apple ever used MacX with a standard keyboard. APPLE ARE YOU READING THIS? Give users some *intelligent* choices for the second and third mouse buttons. Remember that not everyone has the poorly designed extended keyboard. How about command-mouse and option-mouse for the other buttons? Lord knows there's no shortage of modifier keys on the Mac keyboard. >5. Performance. > X graphics speed in our setup is adequate. On a IIfx, it's very snappy. On a IIcx, it's certainly adequate. Other observations: In a week of use, I've come across only one major glitch, which I haven't been able to reproduce. After running and quitting a number of applications, I noticed that the processes running on my host didn't match up with my remaining windows. There was one host process (client) with no window, and one window with no client. That window was unkillable, except by quitting MacX. I'd like to define commands which don't specify a host, and be prompted for the host when I execute the command. With well over a hundred Unix hosts in the building, it's not practical to set up separate commands even for the ones I use frequently. This feature might be present, but I haven't figured out how to do it. OOPS! I just gave it another stab while composing this, and bombed MacX. Here's how: 1. Compose a new command. You can't execute or set the command until you've pushed the Host... button and interacted with the dialog, but even cancelling from the Host dialog without picking a host seems to satisfy MacX. Save the new command. 2. Execute the command. I got an alert saying The connection tool "MacTCP tool" does not support the "RemoteAddress" macro used in the command "Random Xterm". 3. Edit the command. Push the Host... button. At this point, I landed in Macsbug with a message about an attempt to free an invalid or corrupt block. -- Ephraim Vishniac ephraim@think.com ThinkingCorp@applelink.apple.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142 One of the flaws in the anarchic bopper society was the ease with which such crazed rumors could spread.