Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!apple!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Standard File Requesters
Message-ID: <3869@amiga.UUCP>
Date: 26 May 89 07:00:54 GMT
References: <0914.AA0914@amigash> <941@sactoh0.UUCP> <11583@well.UUCP> <UYNn=hy00VsfE2FI4k@andrew.cmu.edu> <1051@quintus.UUCP> <11636@well.UUCP> <3828@amiga.UUCP> <24769@agate.BERKELEY.EDU>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Distribution: na
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 73

In article <24769@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes:

)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).

Hmmm, maybe.  I think there are some other ones out there.  One easy
answer is to use components (such as a "group object") instead of
multiple inheritance ("the button panel class is a subclass of both
button and group.").

Now, onto some rabid agreement.

)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, ...

)On top of this, we build _real_ objects.

Very much the plan for V1.4.  I've got "Custom Gadgets" in there now.
You can do dials, ...  Perhaps more importantly, there is a uniform
interface to a set of components.  It still needs work.  At this
level, the components, you need some mechanism for connecting
components together: not just grouping but hooking up up-arrow
to scroll bar slider.  I've done this in oop deals at home, but
it's kind of another problem with gadgets.  Gadgets don't
issue forth when triggered, giving a notice that might be directed
at a sensor of a separate component.  All they do is turn on
mouse messages and say "I'm done."  Anyway, suppose we figure it
out, and there's a nice class of gadgets, including scrolling lists,
etc.

Of course, we need to make a set of them "standard" but save that
problem.

Now, the "objects" level.  What I HOPE is that you could use these
Intuition constructs to implement a fancy-schmansy UI object system
above them.  I'm trying to determine what the components must bring to
the party.  I know that inheritance is at the object level.  I think
connections are at the component level.  Polymorphism, for defined
operations on components" should be at the component level (at least
for "delete", "remove," "refresh," ...).

So, pieces:
1) Intuition support for "custom gadgets" and provisions for their connection.
2) Standard set of useful components (besides converting over the
  bool/prop/string, the only one I've written is a useless "dial gadget.")
3) Higher level system which includes font and resolution sensitive
  layout, perhaps file/font functions for requesters, interface-builder
  stuff, rexx ports, blah blah ...

)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.

I think #1 rarely works.

I'm working bottom-up.  Action will happen starting next developer
release of V1.4 software.

	jimm
-- 
Jim Mackraz, I and I Computing	   	"He's hidden now, but you can see
{cbmvax,well,oliveb}!amiga!jimm          The bubbles where he breathes."
							- Shriekback
Opinions are my own.  Comments are not to be taken as Commodore official policy.