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.
