Path: utzoo!attcan!uunet!husc6!rutgers!apple!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga.tech Subject: Re: Standard File Requesters Message-ID: <11634@well.UUCP> Date: 12 May 89 05:24:55 GMT References: <0914.AA0914@amigash> <941@sactoh0.UUCP> <11583@well.UUCP> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Distribution: na Organization: The Blue Planet Lines: 51 +-- 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