Date: Tue, 20 Dec 94 22:27:50 MST From: terry@cs.weber.edu (Terry Lambert) To: ulim@CoLi.Uni-SB.DE (Ulrich Mayring) Cc: hackers@freebsd.org Subject: Re: OpenStep for FreeBSD? Message-ID: <9412210527.AA29918@cs.weber.edu> In-Reply-To: <199412192252.XAA23127@coli-gate.coli.uni-sb.de>; from "Ulrich Mayring" at Dec 19, 94 11:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I heard yesterday that Sun, Dec and HP have licensed OpenStep, the GUI and
> API of NextStep, as far as I understand. This would mean that in one or
> two years Sun, Dec and HP workstations will look like the Next and all
> existing Next applications will run on these platforms. And with the
> three workstation-biggies behind it we can expect a lot of new software
> will be developped for OpenStep. So far, so commercial.
>
> But, reportedly, some guys from the FSF are working on a port of OpenStep for
> Linux and OpenStep seems to be looked upon by many as the successor to X.
> ("Unix functionality and Macintosh operability")
>
> I would be interested to hear comments about NextStep from any who have
> used it and if there will be a port for Linux, surely there must be one
> for FreeBSD as well?
The FSF project is well under way, and is in fact, marginally usable for
some things.
I don't buy off on OpenStep taking over. First of all, it's a set of
interface libraries, which implies that while you could implement it on
top of X or on top of Display PostScript, you would not, in fact, be able
to replace X with it. OpenStep still requires a display technology.
The primary benefit to NextStep as an application base is part of the
OS which is lacking elsewhere: MACH Domain sockets and other specifically
implied IPC mechanisms used to implement things like "live links" in the
FramMaker set of tools. Apart from that, it's Just Another Interface.
A big part of NeXTStep is the session management -- the implied browser
and the menu management.
Now anyone who has listened to my diatribe on moving the look-n-feel
enforcement into the window manager and having apps use IPC to talk to
it to instantiate interface objects, knows that I support the idea of
putting the switch between XView and Motif into the manager instead
of the application, but there is an implication here that the applications
must *all* "play ball" for it to work. Look at InputFocusLenience in
the OpenLook window manager to see how far this will get you.
Finally, the production guidelines for software and the tools to build
it (Interface Builder) are what truly cause applications to look as if
they were written specifically for NextStep. Without these tools, the
cohesiveness of the look and feel for applications will not be sustained.
Look at OSF/Motif, which has similarly strict implementation guidelines,
but guidelines which are not enforced by the tools. Look at NetScape,
probably the "Killer App" for the internet (I'd have preferred it as the
"Killer App" for a free UNIX clone, but you can't have everything). It
violates the OSF/Motif style guide with regard to Drag-n-Drop, and so it
screws up when you use the middle button to drag label or other text
around on the screen. It screws up when you enter the text into a dialog
(there are two drop zones which overlap in each dialog... drag a button
label text around over top of an "Open Location" dialog to see what I mean.
This is not the fault of the interface, it is the fault of people not
following the implementation guidelines.
I seriously doubt that there is great benefit to the technology without
a great deal of the infrastructure, which can't possibly be there in the
first or even the third revision of the FSF code.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9412210527.AA29918>