Xref: utzoo comp.unix.wizards:12249 comp.graphics:3576
Path: utzoo!attcan!uunet!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards,comp.graphics
Subject: Re: Look and Feel... a red herring (Re: UNIX Expo in NYC)
Message-ID: <2175@ficc.uu.net>
Date: 9 Nov 88 17:37:24 GMT
References: <10794@ulysses.homer.nj.att.com> <2113@ficc.uu.net> <742@m10ux.UUCP> <744@m10ux.UUCP>
Organization: SCADA
Lines: 68

In article <744@m10ux.UUCP>, mnc@m10ux.UUCP (Michael Condict) writes:
> Standardizing the programmer's interface does not guarantee that any
> particular user interface will be implemented by the programmer.

That's true. We don't want the programmer implementing the user interface.

> If the programmer has
> a powerful enough interface, s/he can make the windows and windowing
> operations look arbitrarily different from any user interface in use today.

Yes, but if the programmer interface is defined well enough, it will be
easier to just let the interface library stick with the defaults.

> As someone pointed out to me, this is or was a problem on Mac's, i.e.
> you had to restrict your use of the programming interface to just those
> operations that would lead to the standard Mac user interface, at least
> assuming that you wanted anyone to buy your software.

The idea is that this hypothetical programmer's interface will provide
all the capabilities needed by a large percentage of the programs, and
most of the capabilities needed by the rest. The trick is defining this
interface so it does the job right. This is, as a mathemetician might
say, an interesting problem.

> It is NOT guaranteed to operate under the Mac paradigm, however,
> if part of this paradigm is defined to be a particular user interface.  That
> is, not unless the programmer interface is so restrictive and abstract as to
> permit only operations that have a reasonable implementation within the bounds
> of the Mac user interface.

No, what I'm saying is that the programmer interface will provide a set
of capabilities. These capabilities are the greatest common factor between
the window systems it adresses, with some aesthetic and design decisions
that let the program look reasonably nice on all the systems it supports
built in.

> As an example, suppose the programmer interface has operations to deal with
> scroll bars, whereas the target user interface does not have any concept of
> scroll bars.

You mean like the AT&T 7300 UI which uses a pair of arrows, or a keyboard-
oriented interface that uses cursor keys? Then when the programmer says "put
a scroll-bar here" it'll put a couple of arrows on the 7300 and provide some
sort of mnemonic visuals on the keyboard system (like, a picture of the keys).

Of course, the variety of systems might be wide enough that a scroll-bar is
to low-level a model. Maybe a text pane would be a better level of
abstraction.

But what's your user-who's-never-seen-a-scroll-bar-before going to do if he
runs an OpenLook application on his DeskWindows machine?

> Summary: It is simply not true that the potential set of operations and rules
> for a windowing system are so well agreed upon that every thing in one such
> system has a clear analogue in another.  Although maybe we should move in that
> direction.

A certain subset of the screen objects are reasonably well worked out. An
interface that supported only 80% of the systems out there would not be a
disaster. I think that such an interface can be designed.

By the way, I wasn't attempting to hold up either the Mac or X as examples
of programmer interfaces to model this on. They are just examples people are
likely to have had some experience with.
-- 
Peter da Silva  `-_-'  Ferranti International Controls Corporation
"Have you hugged  U  your wolf today?"     uunet.uu.net!ficc!peter
Disclaimer: My typos are my own damn business.   peter@ficc.uu.net