Not impressed with MacX

[John Coolidge]

[Crossposting to comp.unix.aux added, as MacX will be bundled with A/UX
 in the next release]

hrf900 at 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 at 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.