🚀 go-pugleaf

Huh?  I don't see your line of reasoning here....

One might just as well provide two different shared libraries, with
the same programming interface.  Putting things in the server
does not follow as the only way to solve the problem of different
"look and feels".

The real problem here is that OpenLook and Motif provide different
programming interfaces, not where they are implemented....
				

>One thing that occures to me is that this Open Look versus Motif thing
>would be easier to deal with under NeWS. It would be reasonable to implement
>most of the UI in the server, and have the *user* choose Open Look or
>Motif, with NeWS. It's not really reasonable to do this under X.

Unless:

	1) you do it under V.4 or other OSes that support dynamic
	   linking (OSF/1 will do so, right?);

	2) the idea of a single API for both Motif and Open Look 1) is
	   possible and 2) gets done;

and

	3) the APIs are binary compatible;

in which case you might be able to install a Motif window
manager+toolkit libraries to get Motif behavior, or an Open Look window
manager+toolkit libraries to get Open Look behavior, or install them
both and let users set LD_LIBRARY_PATH or its moral equivalent to get a
choice of behaviors.

> >One thing that occures to me is that this Open Look versus Motif thing
> >would be easier to deal with under NeWS. It would be reasonable to implement
> >most of the UI in the server, and have the *user* choose Open Look or
> >Motif, with NeWS. It's not really reasonable to do this under X.

> Unless: [dynamic linking] + a single API for both Motif and Open Look +
> [binary compatible interface]

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.
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

peter@ficc.uu.net (Peter da Silva) writes:
>> Unless: [dynamic linking] + a single API for both Motif and Open Look +
>> [binary compatible interface]
>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? 

Yes, someone is working on this.  There is a project at AT&T called N3
(last time I checked up on it) that's trying to define a single API that
will produce either OpenLook or Motif look-and-feel, depending on which
library you link with at runtime.  Unfortunately, it's an Xt-based
programming model (unfortunate if, like me, you don't like the Xt model
in the first place), but at least it's an attempt to do the right thing.

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 |
+-----------------------------------------------------------------------------+

In article <:8S1SU7xds13@ficc.uu.net>, peter@ficc (Peter da Silva) writes:
>> Unless: [dynamic linking] + a single API for both Motif and Open Look +
>> [binary compatible interface]
>
>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.

Solbourne has a C++ package that supports both OpenLook or Motif.


I saw a flyer from some vendor who has a high level toolkit that
supports both Motif and Open Look. I can post a follow-up with the
companies's name if people want.(I'm home right now).

The problem with this is that it would be difficult to design a
well-tuned application that really makes use of the UI. A good
application pays attention to layout, common actions, screen
management, etc. Assuming several commercial products are available,
the best ones will be the ones that really make use of the UI to the
fullest extent.

--
Bruce G. Barnett	<barnett@crd.ge.com>   uunet!crdgw1!barnett

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"