shf@well.UUCP (Stuart H. Ferguson) (05/09/89)
+-- hrlaser@sactoh0.UUCP (Harv R. Laser) writes: [ something I consider very telling ... ] | PathMaster is my absolute favorite file requester. I could name | a dozen (or 5 dozen) programs I use frequently whose file | requesters I'd like to rip out by their roots and replace with | PathMaster.... Yeah, and why not? File requesters seem to be a religious issue almost like editors (maybe not that bad :-). They are also very difficult to write well, which leaves developers with few alternatives. The end result is that almost everyone has almost no programs with file requesters they like. There are some PD file requesters -- but what if you don't like them? ARP provides a file requester in its shared library, which is nice for developers who don't want to write there own, and can be replaced. But replacing it requires SetFunction()ing the library, and hoping for no unexpected interactions. How about a "filerequester.library?" It could be spec'ed as having a known interface that anyone could write towards -- from both sides. Developers would have access to a generic file requester from within their programs, users would see a consistent interface, AND users could choose the requester they want from as many possible filerequester.library's as could be written. You could use the Dillon fr.library, or the Schwab fr.library, or the RJ ... There's been some talk on .tech about a requester interface already.... P.S. Personally, I'd still like to see a file requester that opened up like a Workbench drawer with the full functionality. Double-click other drawers to browse the directory and double-click your data file to select it. Or, shift-click to select multiple files. Why, when there's a graphic system interface, are there no graphical file requesters? P.Wishful.Thinking.S. Why, oh, why is there no workbench.library? Put some hooks in that black box, boys. I've got libraries one the brain tonight I gues .... -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/10/89)
shf@well.UUCP (Stuart H. Ferguson) writes: > How about a "filerequester.library?" Stuart, with all due respect, I would like to make one important point: 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. 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 1) save programmers a lot of work, 2) result in more efficient use of system resources since only one copy of the code will be shared among multiple applications, 3) Bring more UI standardization to Amiga programs, 4) Allow hackers to customize the "Standard" interface using SetFunction(), and 5) Allow the UI of all application programs on the system to be upgraded merely by upgrading the library. A bigger problem with the Intuition + graphics libraries is that the only text support outside the console device (which is basically terminal emulation) is Text(). A text.library which contained code to manage text buffers + the necessary display handling code which would allow you to attach a text object to a window or gadget would be a wonderful tool for application developers as well. I suspect the reason the Mac has such wonderful word processors and DTP packages is that the Mac OS (as it were) gives developers a lot of system support for text handling. A primary component of the Andrew Toolkit (a user interface toolkit for Unix + X11 that was developed here at the ITC) is its Text object. > Stuart Ferguson (shf@well.UUCP) > Action by HAVOC -- Michael Portuesi * Information Technology Center * Carnegie Mellon University INTERNET: mp1u+@andrew.cmu.edu * BITNET: mp1u+@andrew UUCP: ...harvard!andrew.cmu.edu!mp1u+ MAIL: Carnegie Mellon University, P.O. Box 259, Pittsburgh, PA 15213
golden@cps3xx.UUCP (golden james) (05/10/89)
In article <11583@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >to write well, which leaves developers with few alternatives. The end >result is that almost everyone has almost no programs with file requesters >they like. > >There are some PD file requesters -- but what if you don't like them? ... >How about a "filerequester.library?" It could be spec'ed as having a >known interface that anyone could write towards -- from both sides. >Developers would have access to a generic file requester from within >their programs, users would see a consistent interface, AND users could >choose the requester they want from as many possible ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >filerequester.library's as could be written. You could use the Dillon >fr.library, or the Schwab fr.library, or the RJ ... Or even a FileReq.device - who knows? Just drop your favorite in the right drawer, and you'll have an instant common user interface to all your favorite (participating) programs. Great Idea!! Mike Golden Physiology Undergraduate Michigan State University
cmcmanis%pepper@Sun.COM (Chuck McManis) (05/11/89)
In article <11583@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >How about a "filerequester.library?" It could be spec'ed as having a In article <2915@cps3xx.UUCP> golden@cps3xx.UUCP (golden james) writes: >Or even a FileReq.device - who knows? Just drop your favorite in the >right drawer, and you'll have an instant common user interface to all >your favorite (participating) programs. Great Idea!! How about ARP? You may not like the file requester in the ARP library but it is a) a shared library, b) a defined file requester interface. So every thing you need is in place. Just SetFunction() the requester code with your own requester if you want to change it. When I installed ARP 1.3 it didn't sink in, but when I brought up VlT and went to upload a file, the new requester was there and it was really neat. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
pds@quintus.UUCP (Peter Schachte) (05/11/89)
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
new@udel.EDU (Darren New) (05/12/89)
In article <1051@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >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 Alternately, have everything in the library (or most everything) be a stub that LoadSeg's another file and patches the stub. (Do I hear an echo? :-) Then replacing the stub file could change portions of the library and allow low memory overhead. Problems: what if I don't have the memory to do the LoadSeg? How to clean up when expunged? How to specify that more than one routine is in the same file (like open file requester and save file requester)? But these are fairly trivial things overall. - Darren New
peter@sugar.hackercorp.com (Peter da Silva) (05/12/89)
In article <UYNn=hy00VsfE2FI4k@andrew.cmu.edu>, mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > To me, Intuition's biggest problem is that it doesn't provide enough > support for a lot of higher-level UI stuff. I started working on an X-windows-esque widget library, but nobody seemed interested and I dropped it. Maybe it's time to reconsider it? I was originally going to just have a text-pane and some fancy scrollbar with readout widgets... -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
shf@well.UUCP (Stuart H. Ferguson) (05/12/89)
+-- 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
shf@well.UUCP (Stuart H. Ferguson) (05/12/89)
+-- cmcmanis@sun.UUCP (Chuck McManis) writes: | In article <11583@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: | >How about a "filerequester.library?" It could be spec'ed as having a | In article <2915@cps3xx.UUCP> golden@cps3xx.UUCP (golden james) writes: | >Or even a FileReq.device - who knows? Just drop your favorite in the | | How about ARP? You may not like the file requester in the ARP library | but it is a) a shared library, b) a defined file requester interface. | So every thing you need is in place. Just SetFunction() the requester | code with your own requester if you want to change it. Objection! SetFunction(), I my opinion, is a hack. And a pretty poor one at that. It locks the library in memory, even when it's not in use, and it requires the USER to correctly nest the setfunctioning and un-setfuntioning of nis tools. The first is a bad limitation, but the second is unacceptable from a user's point of view. If they get the nesting wrong - Boom! | When I installed | ARP 1.3 it didn't sink in, but when I brought up VlT and went to | upload a file, the new requester was there and it was really neat. | --Chuck McManis Yeah, there are great advantages to this shared code thing -- we're just so used to the "monolithic" program approach that it's hard to see. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
shf@well.UUCP (Stuart H. Ferguson) (05/12/89)
+-- pds@quintus.UUCP (Peter Schachte) writes: | shf@well.UUCP (Stuart H. Ferguson) writes: | > How about a "filerequester.library?" | | In article <> mp1u+@andrew.cmu.edu (Michael Portuesi) replies: | >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. | | [...] 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. My reasoning exactly -- that's the purpose of putting the requester in a library by itself. | 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. This is a neat idea which I've been thinking about for a while now. There are several problems, technical and social. The technical problems revolve around selecting a message-passing scheme. My first thought was to use the library structure itself as a dipatch table to enumerated methods. This is very fast since all "messages" are really just library calls at hard-coded offsets. It's limited, however, in that classes are strictly hierarchical and methods have to be nested. Another approach would be to use symbolic message codes and have each "message" to an object involve some sort of string or ID which would be searched for by the object and passed on if unrecognized. This is not nearly as fast and is a lot more complex, but it is fully general with regards to building subclasses and extending your superclasses. This scheme can be made fast, but at a price of complexity. It also has a giant global namespace which I'm not so hot about. Any ideas on that Peter? The social problem is making it catch on. I suppose if it is useful enough people would use it, but for commercial applications ... It's actually the social concerns that have me suggest a filereq. library. a) It can be done reasonably quickly. b) It's small and unobtrusive -- you don't have to buy a whole philosophy to use it. c) It encuurages the gifted "utility" writers to make their own. d) If widely used, it shows off the advantage of having your application broken up into lots of little cooperating bits. (Once that idea is sold, it's easier to sell a full-blown O-O system.) Oh well, I'll leave the social aspects to another group -- this is comp.sys.amiga.TECH! -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
usenet@cps3xx.UUCP (Usenet file owner) (05/12/89)
In article <15219@louie.udel.EDU> new@udel.EDU (Darren New) writes: >In article <1051@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >Alternately, have everything in the library (or most everything) be a stub >that LoadSeg's another file and patches the stub. (Do I hear an echo? :-) Instead of LoadSeg directly, how about "IntuitionTools.library" which has a bunch of standard functions. Each function when called, does an additional OpenLibrary("functionname.library",x), and then Calls it and Closes Library. This eliminates SetFunction kludges, and is much simpler. That sounds like a lot of overhead, but for things like file requesters, things are slow anyways. This is an example of a short .signature jap@frith.cl.msu.edu
jimm@amiga.UUCP (Jim Mackraz) (05/13/89)
In article <11636@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes:
)| 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.
)This is a neat idea which I've been thinking about for a while now.
)There are several problems, technical and social. The technical problems
)revolve around selecting a message-passing scheme. My first thought
)was to use the library structure itself as a dipatch table to
)enumerated methods. This is very fast since all "messages" are really
)just library calls at hard-coded offsets. It's limited, however, in
)that classes are strictly hierarchical and methods have to be nested.
I don't know what exactly you mean by nested, but the "array of
function pointers" does single inheritance rather nicely: a subclass
starts out with a copy of the array of its superclass, extends
and replaces some entries. You might want to pass the message
up the inheritance chain, for example when initializing a new object
instance.
)Another approach would be to use symbolic message codes and have each
)"message" to an object involve some sort of string or ID which would
)be searched for by the object and passed on if unrecognized. This is
)not nearly as fast and is a lot more complex, but it is fully general
)with regards to building subclasses and extending your superclasses.
)This scheme can be made fast, but at a price of complexity.
)It also has a giant global namespace which I'm not so hot about.
The namespace is the the blessing and the curse. It's not hard to code
up a system using technique 1, compile and link it as a module.
Use nested include files to define consecutive method IDs and object
data structure, and if you add a method to class A, your makefile makes
sure you recompile all descendants of A. And all clients of A.
On the other hand, if some classes are implemented in the system, some
by aftermarket class vendors, and even a third source for the application
program, you clearly can't recompile when you add a method to a system class.
So, for a solution to fly as system code, you MUST have a global namespace.
So, once you do that, you're looking up methods in id tables, plus any
tricks you want to pull.
To suitably manage a global namespace, it helps to have partitions.
A manageable group of people is responsible for uniqueueness within
the partition, and partitions are handed out by a higher authority.
Objective C does this by partitioning on something they call Packages
or Categories or something (I think the name changed between Cox's book
and the NeXT relealse.)
Brad Cox's book, by the way, describes (evangelizes) Objective-C, his
product. It's sort of the glorified version of lots of "object-oriented
programming in C" articles that you see everywhere.
I can't remember why I thought that might not be so cool. Oh, yeah,
it means that classes are members of categories or packages based
mainly on what vendor they came from, not what type of function they
perform (or, for example, who their parent class is!).
There is a different precedent around in network address naming. You
are granted a group of id's from a higher authority. You may grant
a subset to anyone you choose.
Now, you only need a mess of include files for every language in the
world that will want to implement or make use of the classes. And just
because you have unique id's, it doesn't mean you have unique symbol
to assign them to for programming purposes ...
)The social problem is making it catch on. I suppose if it is
)useful enough people would use it, but for commercial applications ...
)It's actually the social concerns that have me suggest a filereq.
)library. a) It can be done reasonably quickly. b) It's small and
)unobtrusive -- you don't have to buy a whole philosophy to use it.
)c) It encuurages the gifted "utility" writers to make their own.
)d) If widely used, it shows off the advantage of having your application
)broken up into lots of little cooperating bits. (Once that idea is
)sold, it's easier to sell a full-blown O-O system.)
I think you hit the nail on the head, as usual, Stu: it's a big machine
to get people to buy off on. The position I've advocated has been to
make the filerequester interface particularly "thin:" not a lot of customization
and special features, so that when a more comprehensive system implements
a file requester, the callers to the interim system will start getting
the cool one.
There are some other interesting questions in the object/class UI discussion:
The big issue is language independence. I don't read the right journals,
but I am not aware of any system that doesn't bow to a language. I'll
be interested in seeing how they implement classes in other languages on
the NeXT box. But on the Amiga, clearly a system needs to support
the arbitrary reasonable programming language.
Composition of objects into groups is important. How do you arrange
for an up arrow button tell a slider to click up one page? I've done
it a couple of ways, but I think I missed out on the Smalltalk style
Model-View-Controller business. Gotta get the right journals from
now on ... (No, you don't send a REXX message ...)
How do you "reach into" a composite object to establish a parameter for
one of its sub-components?
What kind of user-interface object layout/placement machine do you want?
After you get to a certain high level, your views on inheritance can change.
While I was perfectly happy defining a class ScrollSliderWithButtons as
a subclass of ScrollSlider (no, I don't use names like that really, and it
wasn't quite like that ...), you get a little sick of making a subclass
of windows with ScrollingWindows to have ScrollingWindowsWithExtraButton.
Making little extensions to large classes is what leads people to such
odious things as "multiple inheritance." I figure if I read some more
of those damn journals, there'd be some alternatives to inheritance
which still give you polymorphism (the ability to say: "Delete You"
without knowing to whom).
Also, here do you want to keep all the .library (or .class) files?
jimm
--
Jim Mackraz, I and I Computing "He's hidden now, but you can see
{cbmvax,well,oliveb}!amiga!jimm The bubbles where he breathes."
- Shriekback
Opinions are my own. Comments are not to be taken as Commodore official policy.cmcmanis%pepper@Sun.COM (Chuck McManis) (05/13/89)
In article <11635@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >Objection! SetFunction(), I my opinion, is a hack. And a pretty poor >one at that. So, are you agree that something like ARP library is the way to go? I agree that SetFunction() is a hack, and like Bart's system Wedges much better. As for leaving the Library open, that is true, but as long as the routine is setfunctioned, one must assume that the application needing it is still around. Maybe we could use wedges, and put a "wedge identifier" in the handle (xxxBase) so that on a CloseLibrary() call any wedges that this application had in force would be removed. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
hummel@m.cs.uiuc.edu (05/13/89)
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: lhummeldillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/14/89)
: - Asynchronous directory scans, allowing a selection to be : made while still reading in a directory. I agree, but displaying the files as the directory is being scanned is quite distracting to me and I usually end up waiting for it to settle down before looking at what is available. Perhaps allow the user to change the directory name string gadget and or file name while scanning asynchronously (i.e. abort the scan and start it over the moment he hits return on the directory, and abort the scan and return from the requester the moment he hits return on the file string gadget) : - Keyboard filename completion. Typing "m" will highlight : the first file/directory beginning with "m", and so on. That would be nice... as the person is typing continuously restrict the list being displayed to what matches the input string*. This would be extremely useful. Have another character, ESC, automatically complete the filename for you (it should not be done automatically when the routine determines only one unique name exists because the user will still be typing!) : - Responds to Intuition insert/eject messages. For the master volume list, you mean? yah. : - Wildcards and multiple file selection where appropriate. As a restricting mechanism. It would be nice to be able to type "*/*" and then page through the list of files before making your final selection(s). :Any thoughts? Any answers? Any tee ell ay en dee? : : < Lionel -Matt
elg@killer.Dallas.TX.US (Eric Green) (05/15/89)
in article <42700012@m.cs.uiuc.edu>, hummel@m.cs.uiuc.edu says: > 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. I think some of the existing requesters already do this. In fact, I'm almost certain that the ARP requester does. > - Responds to Intuition insert/eject messages. Justin McCormick's does (at least, in its File Injector incarnation). The main problem is that Justin's code is NOT publically available :-( (but I can sympathize... he spent an entire summer hacking on that file requester, after he'd already finished most of the rest of PixMate). > - Wildcards and multiple file selection where appropriate. Hmm... how about multiple filename buckets? On the right side of the string gadget for the filename, perhaps an up/down arrow gadget pair, to allow you to scroll to other buckets? Sort of like in Preferences for the printers, or the way Justin scrolls his devices when there's more devices than buttons? > - 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. Depends on your definition of BIG. Justin's does most of this already, and is maybe 8K long (of course, to get it that small he had to write it about 4/5ths assembler... everything has its price). Hmm, that does seem big enough to deserve its own library, though. Forget the folks saying put it with Intuition stuff.... (Me? I'm using arp.library's file requester. Life's too short...). -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | // Join the Church of HAL, and worship at the altar of all computers | |\X/ with three-letter names (e.g. IBM and DEC). White lab coats optional.|
golden@cps3xx.UUCP (golden james) (05/15/89)
In article <UYNn=hy00VsfE2FI4k@andrew.cmu.edu> mp1u+@andrew.cmu.edu (Michael Portuesi) writes: >shf@well.UUCP (Stuart H. Ferguson) writes: >> How about a "filerequester.library?" > >Stuart, with all due respect, I would like to make one important point: > > Graphical UI != File Requester in a Library > I don't believe that he ever said it was... [...] >3) Bring more UI standardization to Amiga programs, 4) Allow hackers ^^^^^^^ >to customize the "Standard" interface using SetFunction(), and 5) [...] That's exactly the point. You shouldn't have to be a hacker to get a filerequestor that works well for you. I guess your saying that only people with technical expertise deserve to have file requestors that they like. Mike Golden Physiology Undergraduate Michigan State University
ranjit@grad2.cis.upenn.edu (Ranjit Bhatnagar) (05/15/89)
In article <2977@cps3xx.UUCP> golden@cps3xx.UUCP (golden james) writes: > >That's exactly the point. You shouldn't have to be a hacker to get a >filerequestor that works well for you. I guess your saying that only >people with technical expertise deserve to have file requestors that >they like. > >Mike Golden OK, then - who's gonna be the first to write a file-requester in structured, well-documented AREXX code? Make it pleasant enough that the average BASIC novice can understand it, and even a newcomer can modify things like the size, position, color of the windows, whether to ignore case in alphabetization, and such. (Put all these in variable assignments at the top of the file.) This would make it embarassingly easy to add your favorite goodies. Sort by file-extender? Highlight .info files in blue? Automatically format any disks whose names start with 'v'? No problem. (Note that this approach makes it easy for people to trade their favorite file-requester code, and it also makes it relatively easy for novices to detect nasties like the v-disk formatter.) By the way, whaddya think about a REQ: device? An OPEN call on REQ:foo:bar brings up a requester with caption 'foo' in dir bar, and returns a lock on the file the user selects. This would add requesters to even all-text programs, and, in fact, could be used in scripts to add a bit of friendliness to all-text programs. script file fastfont: ff "req:Please choose a font to become the system font:fonts:" AnyProject.info: default tool = req:Pick your favorite application. script file easyzoo: zoo e// "req:Which file do you want to unzoo?:*.zoo" (note the new feature I just thought of.) -ranjit (well, SOMEBODY has to have the wild ideas) "Trespassers w" ranjit@eniac.seas.upenn.edu mailrus!eecae!netnews!eniac!... Near the sides of tall buildings, how dare they kiss goodbye? Those buildings that saw the airplanes that kiss the air in their fantasy.
ecphssrw@roger.csun.edu (Stephen Walton) (05/16/89)
In article <11126@netnews.upenn.edu>, ranjit@grad2 (Ranjit Bhatnagar) writes: > >OK, then - who's gonna be the first to write a file-requester in >structured, well-documented AREXX code? Here's one: Call Addlib('rexxarplib.library',0,-30,0) filename = GetFile(x, y, 'dir', 'file', 'title') where x and y are the coordinates of the upper right corner of the requester, 'dir' is the name of the starting directory, 'file' is the default file in the flie gadget, and 'title' is the title to appear in the title bar of the requester. Steve Walton P.S. 1/2 :-) Seriously, rexxarplib is the only sensible way to get at Intuition functions, including gadgets, requesters, etc., from ARexx.
mp1u+@andrew.cmu.edu (Michael Portuesi) (05/16/89)
golden@cps3xx.UUCP (golden james) writes: > ^^^^^^^ > >to customize the "Standard" interface using SetFunction(), and 5) > [...] > > That's exactly the point. You shouldn't have to be a hacker to get a > filerequestor that works well for you. I guess your saying that only > people with technical expertise deserve to have file requestors that > they like. > First of all, once a "hacker" creates a new style of user interface component, anyone can take advantage of it, not its creator. And the cold reality is that you're going to have to have some programming experience to build new graphical UI components, at least with the software technology we have today. Second, various proposal have been made in other messages that would allow the "look and feel" of various UI pmponents to be changed merely by replacing files in LIBS:. I don't have much time to think about the issue right now, since I have my final exam as an undergraduate student tomorrow and I really should go and prepare for it. Hopefully I'll have more to say later. -- Michael Portuesi * Information Technology Center * Carnegie Mellon University INTERNET: mp1u+@andrew.cmu.edu * BITNET: mp1u+@andrew UUCP: ...harvard!andrew.cmu.edu!mp1u+ MAIL: Carnegie Mellon University, P.O. Box 259, Pittsburgh, PA 15213
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (05/16/89)
In <2977@cps3xx.UUCP>, golden@cps3xx.UUCP (golden james) writes: > That's exactly the point. You shouldn't have to be a hacker to get a > filerequestor that works well for you. I guess your saying that only > people with technical expertise deserve to have file requestors that > they like. As it stands now, I can only get a file requester that works for me when I run one or two programs. A 'standard' FR call, with well defined parameters and return values, easily replacable, will give us the best of all possible worlds. What programmer wouldn't welcome a simple FR call? If the programmer doesn't like the supplied one, he supplies on of his own. If the user disagrees, he replaces it with one he has written, one his friend has written, or one he has purchased either standalone or as part of another package. Saying that you shouldn't have to be a hacker to get a FR that works for you is rather like saying that you shouldn't have to be a mechanic to have a souped up engine or racing suspension. The main problem, as I see it, is to define the program interface to the FR. There must be enough there to do the minimum required functions of a FR, certainly, and there should probably be enough there to allow the programmer to supply a default directory, a title for the FR, perhaps filename filters, perhaps whether a filename pointer or lock should be returned, and so on. Once that is defined and implemented, we would be virtually deluged with FRs, ranging in quality form good to worse than bad (witness the current crop of FRs, replacement commands, pallette tools, and so on). The main point, however, would be that you, as a user, could define the good for yourself, and that need not be the same as the FR I define as good. In either case, with my good FR, and your not so good FR :-), we would each have consistency within our own environment for all the programs that made use of the system call. -larry -- - Don't tell me what kind of a day to have! - +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
ddave@pnet02.cts.com (David Donley) (05/16/89)
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >: - Asynchronous directory scans, allowing a selection to be >: made while still reading in a directory. > > I agree, but displaying the files as the directory is being scanned > is quite distracting to me and I usually end up waiting for it to > settle down before looking at what is available. > > Perhaps allow the user to change the directory name string gadget > and or file name while scanning asynchronously (i.e. abort the scan > and start it over the moment he hits return on the directory, and > abort the scan and return from the requester the moment he hits > return on the file string gadget) > >: - Keyboard filename completion. Typing "m" will highlight >: the first file/directory beginning with "m", and so on. > > That would be nice... as the person is typing continuously restrict >the list being displayed to what matches the input string*. This would be >extremely useful. Have another character, ESC, automatically complete the >filename for you (it should not be done automatically when the routine >determines only one unique name exists because the user will still be >typing!) > >: - Responds to Intuition insert/eject messages. > > For the master volume list, you mean? yah. > >: - Wildcards and multiple file selection where appropriate. > > As a restricting mechanism. It would be nice to be able to type >"*/*" and then page through the list of files before making your final >selection(s). > >:Any thoughts? Any answers? Any tee ell ay en dee? >: >: < Lionel > > -Matt People who are still using floppy drives will be very upset at having to wait for the directory to finish... People who have hard disks can wait for the directory if they want it to settle down... :-) Call the Bug Eyes BBS at (213) 372-4494 ddave@pnet02.CTS.COM killer!gryphon!pnet02!ddave
wade@pnet01.cts.com (Wade Bickel) (05/17/89)
I assume this topic will be discussed at the developers confrence next
month. Who will be in charge of the topic?
Thanks,
Wade.
UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!wade
ARPA: crash!pnet01!wade@nosc.mil
INET: wade@pnet01.cts.commwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (05/24/89)
I give up - I've been trying to catch up before commenting, and not
getting anywhere. So let's answer a question of Jimm's, and then give
my (right, of course :-) answer to the question of UI libraries
In article <3828@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes:
< Making little extensions to large classes is what leads people to such
< odious things as "multiple inheritance." I figure if I read some more
< of those damn journals, there'd be some alternatives to inheritance
< which still give you polymorphism (the ability to say: "Delete You"
< without knowing to whom).
I think you're talking about "mixins" (name from the flavors system,
of course). You create a class (say window), and it gets to use mixins
(borders, scroll bars, etc). Think of them as "not-quite-classes" that
you can multiple-inherit from. I haven't explored all the variations
(running from "each class has it's own mixins" through multiple
inheritance), but somewhere in there there ougtha be an answer.
Now, for my suggestion in the UI area. What we really need is _two_
levels. A components level, and an objects level. The components
would be a library that provides simple gadgets/requesters/etc, all
with the same look (and feel?). Up-arrow, down-arrow, string (either
text or numeric) requesters, one & two-d sliders, even the
ever-popular "scrolling text box" gadget (calling itself, of course).
Call this "components.library" or some such.
On top of this, we build _real_ objects. Requesters and other things,
or libraries of them. You have "requesters.library" which includes the
common requesters: files, color requesters, devices, anything else you
can think of. These are built of components from the components
library.
Both should have well-defined interfaces. You can change the looks
(and some of the feel) of your requester at will by changing the
components library - but it will still have the same basic layout and
behavior. You can change the layout and behavior by changing the
requesters library - but all the components will still look (and act)
the same.
In addition, if a program rolls it's own requesters from the
components library, they still come up looking (and acting, to some
degree) like the standard requester types.
I've got load libraries that do part of this, for menus & requesters.
They work, and I use them. But I don't do enough intuitionified stuff
to warrant completing them and turning them into real libraries. Also,
I just tossed the file requester in with the rest of the requesters
library; not much point in seperating it out of load libraries.
The problem, of course, is deciding just where to put the line between
the "components" and the "requesters" (or "windows" or whatever)
libraries. Like the "mixins" problem, finding the right point is
critical for making it a success.
As for making it a social success, I can only see two ways: 1) give it
away so everybody can use it, and charge developers bucks for support
and documentation, or 2) get CBM to put it in 1.4 (or whatever). And
#2 has a lot better chance of working than #1.
<mike
--
I know the world is flat. Mike Meyer
Don't try tell me that it's round. mwm@berkeley.edu
I know the world stands still. ucbvax!mwm
Don't try to make it turn around. mwm@ucbjade.BITNETjimm@amiga.UUCP (Jim Mackraz) (05/26/89)
In article <24769@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: )In article <3828@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes: )< Making little extensions to large classes is what leads people to such )< odious things as "multiple inheritance." I figure if I read some more )< of those damn journals, there'd be some alternatives to inheritance )< which still give you polymorphism (the ability to say: "Delete You" )< without knowing to whom). ) )I think you're talking about "mixins" (name from the flavors system, )of course). Hmmm, maybe. I think there are some other ones out there. One easy answer is to use components (such as a "group object") instead of multiple inheritance ("the button panel class is a subclass of both button and group."). Now, onto some rabid agreement. )Now, for my suggestion in the UI area. What we really need is _two_ )levels. A components level, and an objects level. The components )would be a library that provides simple gadgets/requesters/etc, ... )On top of this, we build _real_ objects. Very much the plan for V1.4. I've got "Custom Gadgets" in there now. You can do dials, ... Perhaps more importantly, there is a uniform interface to a set of components. It still needs work. At this level, the components, you need some mechanism for connecting components together: not just grouping but hooking up up-arrow to scroll bar slider. I've done this in oop deals at home, but it's kind of another problem with gadgets. Gadgets don't issue forth when triggered, giving a notice that might be directed at a sensor of a separate component. All they do is turn on mouse messages and say "I'm done." Anyway, suppose we figure it out, and there's a nice class of gadgets, including scrolling lists, etc. Of course, we need to make a set of them "standard" but save that problem. Now, the "objects" level. What I HOPE is that you could use these Intuition constructs to implement a fancy-schmansy UI object system above them. I'm trying to determine what the components must bring to the party. I know that inheritance is at the object level. I think connections are at the component level. Polymorphism, for defined operations on components" should be at the component level (at least for "delete", "remove," "refresh," ...). So, pieces: 1) Intuition support for "custom gadgets" and provisions for their connection. 2) Standard set of useful components (besides converting over the bool/prop/string, the only one I've written is a useless "dial gadget.") 3) Higher level system which includes font and resolution sensitive layout, perhaps file/font functions for requesters, interface-builder stuff, rexx ports, blah blah ... )As for making it a social success, I can only see two ways: 1) give it )away so everybody can use it, and charge developers bucks for support )and documentation, or 2) get CBM to put it in 1.4 (or whatever). And )#2 has a lot better chance of working than #1. I think #1 rarely works. I'm working bottom-up. Action will happen starting next developer release of V1.4 software. jimm -- Jim Mackraz, I and I Computing "He's hidden now, but you can see {cbmvax,well,oliveb}!amiga!jimm The bubbles where he breathes." - Shriekback Opinions are my own. Comments are not to be taken as Commodore official policy.
scot@amigash.UUCP (Scot L. Harris) (05/30/89)
>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.]
MJB@cup.portal.com (Martin J Brown-Jr) (06/02/89)
There has been one very obvious design flaw that has, regrettably, shown up
in all/most windowing system file requesters. The flaw is separating the
scroll arrow gadgets, putting them at opposite ends of the slider gadget.
IMHO, this is just plain bad design.
First, it seems to me a user is going to use either the arrows or the slider,
in any one instance of useage. When the user grabs either one of the arrows,
then overshoots the mark he/she is going to want to correct the situation
by using the other arrow. And as we all know, the other arrow is just about
as far away as possible, at the opposite end of the requester. And if the
requester has been sized to max_height to show a lot of files, the user ends
up moving the mouse just about the max_distance to get from one arrow to the
other. DUMB DUMB DUMB DUMB!
(don't give me that "just use a mouse accelerator" crap either, I use one)
IMHO, the two arrows would be in the best position if they were toegether,
one just above the other. That way shifting from one to other couldn't be
easier or quicker, with little chance for the horizontal positional error
to occur over such a short distance (h error much easier to get when
moving over longer distances). This short distance reduces the attention for
aiming that is needed.
The remaining question is whether to put the two arrows at the top or bottom
of the slider. Since 99% of the boolean gadgets that will be needed to be
used after selecting the file are at the bottom, it seems obvious to me that
the two arrows should be below the slider.
If the requester designer puts the arrows together below the slider, and
puts the next most likely bool gadget ("OK", "LOAD", etc.) below the arrows,
and the user scrolls his/her selection to the bottom of the scroll area,
next to the arrows, about 99% of the most common action ever to occur with
this requester will occur within about a radius of inch or two (ok 2.5",:->)
no matter how tall the requester gets.
This sure seems logical, ergonomical, and .`. the most proper way to incorpora
these arrow gadgets.
- MJB -