Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!intercon!news From: amanda@mermaid.intercon.com (Amanda Walker) Newsgroups: comp.windows.misc Subject: Re: Open Look versus Motif, and it's effect on NeWS vs. X. Message-ID: <1990Feb20.171452.15371@intercon.com> Date: 20 Feb 90 17:14:52 GMT References: <2935@auspex.auspex.com> <:8S1SU7xds13@ficc.uu.net> <1990Feb18.172615.10355@alphalpha.com> Sender: @intercon.com Reply-To: amanda@mermaid.intercon.com (Amanda Walker) Organization: InterCon Systems Corporation, Sterling, VA Lines: 51 In article <1990Feb18.172615.10355@alphalpha.com>, nazgul@alphalpha.com (Kee Hinckley) writes: > I designed a window-system extension language back in '83. It's a great way to > get the kind of resource-extension ability you get on the Mac, and then some. > But Postscript is not at the right level for that. > > When it finally comes down to the wire; as an application designer I have > to write to what is out there, and that's X and Motif - no question. I want to address these issues in reverse order :-). As an application designer, it's easier (by some metrics) to write to what is out there, but it is by no means necessary. I can think of at least one company doing applications that has its own toolkit, which provides a uniform API to several kinds of look & feel, on a number of different platforms. It can look like a Mac, or Motif, or whatever. It can run under X, the Mac toolbox (I think), SunWindows, or whatever. This gives them much more leverage for their applications, since they are not constrained to X. They've since standardized on Motif, but since it's part of their toolkit they can provide Motif look & feel on machines which don't have libXm.a... The higher-level your API, the better off you are, I think. Back to extensibility. NeWS and the Macintosh (along with many Lisp machines, of various sorts, to some extent) share a characteristic which X lacks, and which I think is the basis for the positive gut reaction many people have towards them. They include a virtual machine for specifying the details of interacting with the user. In NeWS, this virtual machine is a PostScript engine with tail fins. On the Macintosh, it's a 68000. However, in both cases every user interface element is defined by a frob of code that actually manages the interaction with the user. Xt simulates some of this, but it ends up being much more unwieldy, since the class inheritance and callback mechanisms are not particularly well separated from the application. On NeWS or a Mac, it really doesn't matter much where the code that draws stuff and tracks the mouse is located. Under X, if it's not part of the original protocol, it *has* to be in the application. Maybe it's in a shared library somewhere, but they are still tightly bound together. The more loosely they are bound, the better you can distribute the processing load (and thereby improve performance) and the higher level you can make the API (see above). Now, neither PostScript or a 68000 are really tuned for low-level UI work, but neither is all that bad, either. I'm prejudiced and think that Lisp is the way to go, but I know I'm in a minority here. -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"