🚀 go-pugleaf

shf@well.UUCP (Stuart H. Ferguson) writes:
> How about a "filerequester.library?"

In article <UYNn=hy00VsfE2FI4k@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) replies:
>	Graphical UI != File Requester in a Library

True.  MUCH MUCH more is needed.  Stuart didn't go far enough.

>How about instead of a "filerequester.library", we create a shared
>library named "intuitiontools.library", which contains some high-level
>user interface tools for intuition.

But you're not going far enough, either.  By putting everything in one
library, you either restrict its scope or burden the whole system with
lots of code in memory when only a small part is needed.  Putting
everything in one place (or few places) makes it painful to replace
several parts of the system.  For example, you may want someone's scroll
bars, someone else's file requesters, someone else's popup pie menus,
etc.  If these thing are kept separate, rather than all stuffed into a
single library or a few, then it would be much easier to pick and
choose.

I think a better way to organize these things would be objects
(classes).  A program would just create objects and send messages to
them.  The methods (messages implementations) would be kept in something
much like a library, and each actual instance would keep a pointer to
its library.  Then, just by replacing the library, you would change the
implementation of a class.  Also, inheritance would be really helpful,
since, e.g., by replacing the ScrollingWindow class you would change
scrolling behavior for subclasses of ScrollingWindow as well.

Another really intriguing aspect of this approach is that many
applications would mostly be implemented as classes.  The main program
would just create a few objects and send them some messages.  If the
object system itself supplied code for handling the event loop, as does
Xtk and Sunview and others, the main program could just exit, leaving
the object system to handle things from there.  You could spawn as many
editors as you want, you'd still only have one process handling them,
and all code would be shared.

-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds