Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!albanycs!crdgw1!ge-dab!peora!rtmvax!amigash!scot
From: scot@amigash.UUCP (Scot L. Harris)
Newsgroups: comp.sys.amiga.tech
Subject: Standard File Requesters
Message-ID: <1106.AA1106@amigash>
Date: 30 May 89 02:53:22 GMT
Followup-To: comp.sys.amiga.tech
Distribution: usa
Organization: Private System (Amiga 1000) Scot Harris
Lines: 64


>From: hummel@m.cs.uiuc.edu
>Subject: Re: Standard File Requesters
>Date: 13 May 89 03:16:00 GMT
>
>A lot of the discussion on SFRequesters thus far has centered around
>HOW to provide the service to applications (e.g., SetFunction()'ing
>arp.library, placing it in a user-interface related library, setting
>it up as a server process, etc.).  On a slightly different tack, I am

This has been a very interesting discussion so far with a lot of GREAT
ideas.

>the practice of offering buttons for devices with filesystems (i.e.,
>df0:, vd0:, etc.), what rules can be applied to determine the "best"
>devices to assign to buttons, especially when there is likely to be
>more devices than buttons in an un-cluttered display?

I still think the best solution to the button problem is the one
used in Deluxe Photo Lab.  Group items by files, directories, and volumes
and allow the user to jump to these by pressing an F, D, or V.  This way
you never have to worry about running out of buttons for volumes and
directories are not mixed in with the files.  Also allowing a double 
click to perform the load or what ever action the requester was called
up for is a very nice feature.  


>Allow me to finish by tossing around some features and overall goals,
>some of which have already been mentioned, that might be present in a
>"perfect" file requester:
>	- Asynchronous directory scans, allowing a selection to be
>	  made while still reading in a directory.
>	- Keyboard filename completion.  Typing "m" will highlight
>	  the first file/directory beginning with "m", and so on.
>	- Responds to Intuition insert/eject messages.
>	- Wildcards and multiple file selection where appropriate.
>	- Scrolling in real-time.
>	- Visually appealing; good use of color/shading and gives an
>	  impression of depth.
>	- Function readily apparent from layout; well organized;
>	  sensitive to wide variations in system configurations. (i.e.,
>	  it doesn't offer "df1:" as a choice when there is no "df1:" :-)
>	- It's going to be BIG, so a shared resource (of some form,
>	  such as those being discussed in this string) is the way to go.
>
>Any thoughts?  Any answers?  Any tee ell ay en dee?
>
>				< Lionel
>----------
>Lionel Hummel                             404 W. High St. #6, Urbana, IL 61801
>University of Illinois, Urbana-Champaign  [H] (217)344-5303  [W] (217)333-7408
>hummel@cs.uiuc.edu       {pur-ee,uunet}!uiucdcs!hummel            BIX: lhummel

I for one like a lot of your ideas and hope they are translated to 
something useful RSN.



--
          _                                                                
    ///  /_\         	Scot L. Harris    !hoptoad!peora!rtmvax!amigash!scot 
  \XX/  /   \ M I G A   	    		    
[If you can keep your head when all about you are losing theirs, perhaps
 you have misunderstood the situation.]