🚀 go-pugleaf

+-- mp1u+@andrew.cmu.edu (Michael Portuesi) writes:
| shf@well.UUCP (Stuart H. Ferguson) writes:
| > How about a "filerequester.library?"
| 
| 	Graphical UI != File Requester in a Library
| 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.  A File Requester, code to manage
| menus (I seem to remember you write some really fine menu management
| code that would go nicely into this library), tools to make building
| requesters easier, compound Intuition gadgets (such as scroll bars)
| built using Intuition's atomic gadgets, etc.

Yes, this stuff is needed.  I don't like the idea of just collecting
a grab-bag of tools in one big library, however.  The reason I suggest
a filerequester.library is so that it can be easily replaced.  Since
file requesters are a very atomic module, and they are required by 
programs that don't necessarily need other aspects of a graphical
toolkit, I think it would be justified to put it in a library by
itself.

I also think it makes sense if you look at the aspects of the Amiga
system design that have worked to make the system extensible.  The
two that come to mind immediately are input handlers and devices/dos
handlers.  Both are have well-engineered, highly modular interfaces,
which encourages people to write real tools under them.  (Ok, dos
handlers are a little gooey, but they *are* modular.)  The other way
to extend the system software, SetFunction, has produced some interesting
display hacks, but few real tools.

Building on this observation, I think a filereq.library would be an
idea that encourages innovation and diversity rather than relying on
a single approach.  Since it would be easy to replace, the user would
have a choice, just like you can choose between NEWCON: or ConMan,
VD0: or RAD: (or have both!), DMouse or Mackie ...

| To me, Intuition's biggest problem is that it doesn't provide enough
| support for a lot of higher-level UI stuff.  A shared library
| containing code to do a lot of this stuff will [ be a good thing ]

I agree.  But I would prefer it to be a rational, integrated set of
tools rather than a random assortment.

| A text.library which contained code to
| manage text buffers + the necessary display handling code which would
| [ also be a good thing ]

I agree again -- also as a well-integrated package.
-- 
		Stuart Ferguson		(shf@well.UUCP)
		Action by HAVOC