🚀 go-pugleaf

In article <:8S1SU7xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>That's a good point. If you can get the APIs together for Motif and Open
>Look it should be possible to let the user select them. So "unreasonable"
>isn't a fair description.
>
>Is anyone working on this, though? It looks like the "standard" for Motif
>and OpenLook is pretty much cast in stone. It seems as if NeWS gives you
>more leeway for getting around shortcomings in individual programs.

Yes people are working on this (IEEE P1201 in particular), frankly I wish
they would stop. By the time they make a decision the point will be moot
and they are only confusing the issue. I'm developing applications now,
if someone tells me that the toolkit I'm using right now will be replaced
by a "standard" one "real soon now" then my tendency is to go develop
applications on a PC where I *know* what the toolkit is going to be.  The
market place does not need yet-another-toolkit.  That's right up there with
telling me that Open Look is a standard; but that AT&T machines will support
one toolkit, while Sun machines will support two others.  I want a toolkit
that is vendor-supported on all machines.  That's all.

The second issue is technical.  You can tell me that a merged-toolkit will
solve the problems, but I've gone over the AT&T and Motif specs line by line
and I claim it won't work.  The only way you can make it work is to disallow
features in one or both of the toolkits, and majorly cut down on the overall
functionality. For esthetic reasons if nothing else (and there are other
reasons) the application needs to know what's on the screen, what it looks
like, and what the underlying functionality is.  What happens to the OL app
which tries to put a button in the Motif menu bar?  Or the Motif app which
accents an Open Look button by turning it red or giving it a big shadow? Each
toolkit and application expects functionality that isn't allowed in the other.
Oh sure, on an application by application basis I can write something high
enough level to work around the issues, but I claim that a toolkit that does
that for all applications will be too difficult to write, and too difficult
and/or useless to use. Now, if you first merge the L&Fs, and *then* write
a new toolkit (or expand an existing one), then you have something, but the
L&Fs can't be merged without breaking them, and Motif won't break because one
of the things it has going for it is those millions of PCs that have the same
behavioral interface. So at most you can extend Motif with some Open Look
features - like pushpins and property windows.  That's not a merge, that's
just evolution. 

As for NeWS.  Great concept, bad timing and bad attitude. X hit the streets
with too much power, and Sun was politically in a bad position to get any
major acceptance of NeWS. Furthermore they pushed NeWS from the Postscript(tm)
view. I went to a tutorial on NeWS at Usenix a year or two ago and walked
out in the middle. Why? It was a Postscript tutorial. Sure, if I'm doing
a drawing package or a text package then that's great, but I do user interfaces,
I want a good highlevel interface, and Postscript is not it. Furthermore,
the majority of graphics apps out there are written in fortran and do heavy
tricks with color maps and everything else you can imagine to get the performance
they need. Those fortran programers are not going to learn Postscript and
stencils. Don't get me wrong, the ability to download functions is really neat,
the ability to have an interpreted extension language is really nice, I know,
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.

							-kee
-- 
+-----------------------------------------------------------------------------+
| Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805     |
| 148 Scituate St.         | Smart fax, dial number. | BBS:  617/641-3722     |
| Arlington, MA 02174      | Dumb fax, dial number,  |                        |
| nazgul@alphalpha.com     | wait for ring, press 3. | BBS line is still dead |
+-----------------------------------------------------------------------------+