🚀 go-pugleaf

I give up - I've been trying to catch up before commenting, and not
getting anywhere. So let's answer a question of Jimm's, and then give
my (right, of course :-) answer to the question of UI libraries

In article <3828@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes:
<    Making little extensions to large classes is what leads people to such
<    odious things as "multiple inheritance."  I figure if I read some more
<    of those damn journals, there'd be some alternatives to inheritance
<    which still give you polymorphism (the ability to say: "Delete You"
<    without knowing to whom).

I think you're talking about "mixins" (name from the flavors system,
of course). You create a class (say window), and it gets to use mixins
(borders, scroll bars, etc). Think of them as "not-quite-classes" that
you can multiple-inherit from. I haven't explored all the variations
(running from "each class has it's own mixins" through multiple
inheritance), but somewhere in there there ougtha be an answer.

Now, for my suggestion in the UI area. What we really need is _two_
levels. A components level, and an objects level.  The components
would be a library that provides simple gadgets/requesters/etc, all
with the same look (and feel?). Up-arrow, down-arrow, string (either
text or numeric) requesters, one & two-d sliders, even the
ever-popular "scrolling text box" gadget (calling itself, of course).
Call this "components.library" or some such. 

On top of this, we build _real_ objects. Requesters and other things,
or libraries of them. You have "requesters.library" which includes the
common requesters: files, color requesters, devices, anything else you
can think of. These are built of components from the components
library.

Both should have well-defined interfaces. You can change the looks
(and some of the feel) of your requester at will by changing the
components library - but it will still have the same basic layout and
behavior. You can change the layout and behavior by changing the
requesters library - but all the components will still look (and act)
the same. 

In addition, if a program rolls it's own requesters from the
components library, they still come up looking (and acting, to some
degree) like the standard requester types.

I've got load libraries that do part of this, for menus & requesters.
They work, and I use them. But I don't do enough intuitionified stuff
to warrant completing them and turning them into real libraries. Also,
I just tossed the file requester in with the rest of the requesters
library; not much point in seperating it out of load libraries.

The problem, of course, is deciding just where to put the line between
the "components" and the "requesters" (or "windows" or whatever)
libraries. Like the "mixins" problem, finding the right point is
critical for making it a success.

As for making it a social success, I can only see two ways: 1) give it
away so everybody can use it, and charge developers bucks for support
and documentation, or 2) get CBM to put it in 1.4 (or whatever). And
#2 has a lot better chance of working than #1.

	<mike
--
I know the world is flat.				Mike Meyer
Don't try tell me that it's round.			mwm@berkeley.edu
I know the world stands still.				ucbvax!mwm
Don't try to make it turn around.			mwm@ucbjade.BITNET