🚀 go-pugleaf

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
wondering how best to approach the user-interface aspects of a
SFRequester.  My general tone is one of asking "how ought it to be"?
I think any good design would address these issues, and I am curious
about how these have been (or would be) addressed in the design of
SFReqeusters.

First, a technical question: What is the easiest way to tell if there
is a filesystem associated with a device?  If the device provides a
filesystem, then of course it should be possible to traverse it, else
it's a whole different ballgame (see below).  Now, when one adopts
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?

Next, how about stream-oriented devices such as SER: or PIPE:?  How
might these be offered as source or destination "files" without the
user resorting to typing into a string requester?  I'm talking
user-interface, here now - forget for the moment problems like no
random access.  Should there be a button that gives a scrolling list
of mounted devices for this purpose?  And then, how about letting the
user select logical devices...must that mean yet ANOTHER button, or
should those be thrown into some other category?

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