Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!news.rwth-aachen.de!news-koe1.dfn.de!news.k.shuttle.de!news.s.shuttle.de!news-stu1.dfn.de!news.belwue.de!swidir.switch.ch!news.grnet.gr!btnet-feed2!btnet!tank.news.pipex.net!pipex!feed1.news.innet.be|INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!hammer.uoregon.edu!arclight.uoregon.edu!nntp.primenet.com!netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: [tech pondering] Tck/Tk = portability in GUI?
Message-ID: <erkyrathE1398I.Fvp@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <wwad8xbiofq.fsf@bommel.math.ruu.nl> <erkyrathE12u0H.5x1@netcom.com> <Pine.LNX.3.95.961118134148.21446K-100000@adamant.res.wpi.edu>
Date: Mon, 18 Nov 1996 23:00:17 GMT
Lines: 84
Sender: erkyrath@netcom.netcom.com

George Caswell (timbuktu@adamant.res.wpi.edu) wrote:
> On Mon, 18 Nov 1996, Andrew Plotkin wrote:

> > I would point out, however, that the concept of "a nice interface" is not
> > portable. A Z-machine interpreter interface acceptable in X is not
> > acceptable on the Mac, and vice versa. (Remember, I've written both.) So
> > this whole concept is chasing a chimera, to some extent. 
> > 
>   Hm..  are you referring to just graphical look stuff, or the fact that all
> Mac interfaces conform to the system's 'standard', and that what's needed on a
> Mac would be unwelcome on Unix...?

Well, both. I don't know if I can explain it perfectly, because I'm not 
familiar with Tcl/Tk stuff. But go look at XZip, and then look at MaxZip. 
On the Mac there's a menu bar; not in X. There are subtle differences in 
the way cutting and pasting works, because XZip is ultimately based on 
the Emacs model. The Mac version has a tremendous amount of code for 
dealing with stand-alone apps and double-clicked game and save files; 
this is meaningless in any other OS. The way preferences are edited on 
the Mac is entirely done with Mac widgets, some of which probably don't 
exist anywhere else (for example, the system-generated popup menu list of 
available fonts; the color chooser dialog.) In X it's acceptable to make 
the user edit an .Xdefaults file, although it would be nicer to have some 
kind of interactive editing of the info.

There are just a lot of little wacky things. In the original TADS 
interpreter on the IBM, there are a couple of little data files 
(TADSERR.MSG, CONFIG.TR) which are expected to be installed in the same 
directory as the runtime executable. When I wrote MaxTADS, that went 
*away*. It is incredibly ugly to have such things on the Mac; an 
application should be complete unto itself. It is *not* ugly in MS-DOS; 
it's normal. And in Unix it's normal for there to be little data files, 
but they don't belong in with the application, they belong in some 
compiled-in "/usr/local/zip/" path, overridden by optional environment 
variables or dot files in the user's home directory.

For a compiler, it's worse. A compiler in Unix *should be* command-line 
oriented. Any kind of GUI is just getting in the way of the people who do 
everything with Makefiles, or do everything with Emacs, or do everything 
with Perl scripts.

On the Mac, I'd be pretty pleased if there was an Inform interface that 
looked like CodeWarrior. Project files, maybe even replacing the ICL 
language. Support for using BBEdit or Alpha as an external editor. 
Drag-n-drop of source files into the project.

What about Mac-specific preferences? Choosing the file type/creator of the
output file? 

I'm just picking random ideas here. I only programmed in Windows for eight
months, and I was, uh, unhappy. The Mac and Windows 95 GUIs disagree on a
*lot*. Order and meaning of standard menu items. User involvement in
preference and config files. Semantics of file types. The use of icons for
verbs as opposed to nouns. Approach to hotkeys, TAB, and other
mouse-alternative accelerators. Handling of user-selectable desktop themes
(which will change further on the Mac in upcoming OS releases.) Color
schemes of icons, for chrissake. 

Let's put it this way: I really, really hope I never have to use Visual 
C++ ever again in my life. I believe someone posted here (although it may 
have been a different group entirely) saying that they thought VC++ was 
the ideal programming environment, and CodeWarrior was awful. I believe 
we may take this as some kind of evidence about how different are the 
expectations of Mac and Windows users. :-)

BTW, I don't think this is a reason *not* to create a Tcl/Tk version of 
Inform or Zip. (Or the TADS interpreter and compiler.) I would rather use 
a Tcl version of Inform on the Mac than the command-line (MPW) version. 
And having several versions of tools means more flexibility, and faster 
detection of bugs and divergence-from-standards.

What I'm saying is that a Tcl/Tk version will not replace an OS-native 
version (of an interpreter or a compiler.) Some users will like it and 
use it; some won't.

(PS: Yes, I'm actually trying to *not* restart the OS advocacy argument. 
I'm describing variances, not saying which variant is superior.)

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
