c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) (02/20/88)
#define CONSTRUCTIVE FLAME Go figure- The Amiga is multitasking. Workbench is single tasking. Try opening a disk drawer. One drive spins for a while. On the Amiga, it is a VERY long while with some drawers, and the user is forced to BUSY WAIT while watching a ZZ-cloud. (Is it done yet? No, move the screen up and down a few times, move a couple of windows to pass the time. Is it done yet?) In my opinion, the WB software is COPPING OUT. Deleting, snapshotting, copying- all these and more bring up the dreaded cloud. WRONG SOLUTION: Don't put all .info files in one .info file. That makes it hard to manipulate icons (like on the Mac.) Leave it to the fast file system (I think) to store directories in a reasonable structure so we can get them in a reasonable amount of time. RIGHT SOLUTION: Modify the workbench program. Total rewrite unnecessary. Let WB fork out into different tasks whenever a drawer is opened, files are SNAPSHOTTED, DELETED, etc. And while we are at it, Add ability for name-based directory listings sorted alphabetically, by date, etc. like on the Mac. Add numerous conveniences like SELECT ALL within a drawer, etc. for snapshotting. Or, better yet, a SNAPSHOT WHOLE DRAWER option. Provide the same programmer interface so nothing breaks. While we are at it, provide a programmer interface. In short, look for every call to SetZZCloud() in Workbench and replace it with CreateProc() and the appropriate code. If you agree, put this bumper sticker on your .signature. *** BAN THE CLOUD *** Or just honk if you have any comments. *&(Jonathan Dubman)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (02/20/88)
>Try opening a disk drawer. One drive spins for a while. On the Amiga, it is a >VERY long while with some drawers, and the user is forced to BUSY WAIT while >watching a ZZ-cloud. (Is it done yet? No, move the screen up and down a few >times, move a couple of windows to pass the time. Is it done yet?) > >In my opinion, the WB software is COPPING OUT. Deleting, snapshotting, copying- >all these and more bring up the dreaded cloud. > >WRONG SOLUTION: Don't put all .info files in one .info file. That makes it >hard to manipulate icons (like on the Mac.) Leave it to the fast file system >(I think) to store directories in a reasonable structure so we can get them >in a reasonable amount of time. Actually, that is exactly the *right* solution. If it weren't for the fact that all those .icon files clutter up my directories, I would actually use the workbench. Putting the icons in a single file fixes all the delay problems, makes the directories quite a bit cleaner, and certainly does not make it anymore difficult to manipulate them. Also, such a file need not be large at all, since you only need to keep one image for the N icons that use that image. Manipulation is not difficult either. The workbench would handle all manipulation, and have additional commands to create/delete/modify icons and bind them to files manually. It would automatically delete icons for files which have been deleted manually, etc..... > Let WB fork out into different tasks whenever a drawer is opened, > files are SNAPSHOTTED, DELETED, etc. And while we are at it, > Add ability for name-based directory listings sorted alphabetically, by date, etc. like on the Mac. > In short, look for every call to SetZZCloud() in Workbench and replace > it with CreateProc() and the appropriate code. > This is unrealistic. You obviously have no concept as to the hardships of writing multiple-cooperating-data_structre_sharing-processes. Worse, such a change is not needed. The *real* solution is to speed up the workbench by removing the idiotic scanning of directories, and idiotic openning/reading of multiple files. -Matt
bryce@eris (;;;;0000) (02/20/88)
In article <> c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) writes: > >WRONG SOLUTION: Don't put all .info files in one .info file. That makes it >hard to manipulate icons (like on the Mac.) Leave it to the fast file system.. No matter how fast, having hundreds of .info files is slower than a single ".icons" file. A single file is EXACTLY the right solution. Fast read even on the old slow file system, small size, low overhead, no clutter. If there are several icons all with the same image data, it gets saved once, not many several times. Standard "generic" images could be kept in the single file, for use as any icon (the generic images would be user editable). Just thinking of the overhead for separate .info files boggles the mind. The overhead is about 1K** per file. Now count all the files on your disk. Multiply by 1K. Subtract this from your available space. Gack! ** Assuming 512 byte blocks. Includes space for header. > Let WB fork out into different tasks... Yes. WB should be multitasking internally. |\_/| . ACK!, NAK!, EOT!, SOH! {o o} . Bryce Nesbitt (") BIX: mleeds (temporarily) U USENET: bryce@eris.berkeley.EDU -or- ucbvax!eris!bryce
john13@garfield.UUCP (John Russell) (02/22/88)
In article <8802192003.AA29265@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> Let WB fork out into different tasks whenever a drawer is opened, >> files are SNAPSHOTTED, DELETED, etc. And while we are at it, >> Add ability for name-based directory listings sorted alphabetically, > by date, etc. like on the Mac. > > This is unrealistic. You obviously have no concept as to the >hardships of writing multiple-cooperating-data_structre_sharing-processes. Forget that -- just think of the hardships on your drive of opening two drawers simultaneously :-( ! Or snapshot while a program load is going on. As for the other part, the name-based directory listings ability, did Peter da Silva's "browser" program ever get posted? Our site received part 1 of 2, or 2 of 2, but that was only the docs. John -- "Fanaticism is all right... as long as you're ALONE! HAHAHAHA!" -- Pat Robertson shares a gem of wisdom told to him by Richard Nixon, and thus becomes the first politician to whom I can honestly apply the term "scares the willies out of me"
mp1u+@andrew.cmu.edu (Michael Portuesi) (02/24/88)
c162-fe@zooey.Berkeley.EDU (Jonathan Dubman) writes: > Let WB fork out into different tasks whenever a drawer is opened, > files are SNAPSHOTTED, DELETED, etc. And while we are at it, > Add ability for name-based directory listings sorted alphabetically, > by date, etc. like on the Mac. > Add numerous conveniences like SELECT ALL within a drawer, etc. for > snapshotting. Or, better yet, a SNAPSHOT WHOLE DRAWER option. > Provide the same programmer interface so nothing breaks. > While we are at it, provide a programmer interface. I agree with every one of the above suggestions, with the exception of forking up new tasks to handle user commands. I think if the performance of Workbench were improved, the cloud would become a non-issue. People have flamed about the performance of Workbench in the past, so I won't belabor the point. I used to be a staunch CLI user because even though Workbench is not a fundamentally bad program to deal with, there are enough features missing from Workbench to make it a truly usable program. Right now, I am in limbo between the two environments. I use the Workbench to run things that can be started by clicking on an icon, but I still use the CLI for most other tasks. The above suggestions are a very good start for improving Workbench. Some things I would like to see: * Shift-selection is nice, but there should also be a method to "box" up a group of selections, ala the Mac Finder. * Zoom gadgets on Workbench windows (click and window fills screen, click again -> original size and placement) would be nice (again, ala the Finder). Of course, standard support for Zoom and Iconify in Intuition would be a nice idea too. * A more useful Info function for files would be keen. Specifically, it should also indicate the timestamp on the file, what volume it lives on, and what percentage of that volume is being consumed by the file. Using a smaller font, making the window smaller (so that it doesn't obscure the entire screen), and allowing multiple Info windows would also be a big help. * Some method must be provided for every file to be visible on the Workbench, no matter what it is. I want to use the Workbench as a general file manipulation tool, and I can't do that if every program doesn't have an Icon by default. The finder on the Mac lets you do this; I would like to do the same on my Amiga. To ease user shock, perhaps a toggle for this option could be included in Preferences. To the C-A staff: I'm not trying to flame Workbench, I would just like to see some improvements. Workbench is probably the most important program that runs on the machine, since it is the one a novice user will first use when the machine turns on and to a large extent will determine the machine's friendliness. For an experienced user like myself, Workbench should offer a relatively painless way to perform simple tasks without spilling a deluge of commands to the CLI. I would be happy to toss DirUtil (and its ilk) into the Trashcan if the Workbench were everything it could and should be. I look forward to improvements in Workbench for 1.3. -- Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas *** BAN THE CLOUD ***
peter@nuchat.UUCP (Peter da Silva) (02/27/88)
In article <4507@garfield.UUCP>, john13@garfield.UUCP (John Russell) writes: > As for the other part, the name-based directory listings ability, did Peter > da Silva's "browser" program ever get posted? Our site received part 1 of 2, > or 2 of 2, but that was only the docs. I don't understand this. I only sent one uuencoded arc file to the moderators. Where did this "two part" business come from? On occasion (back to ban the cloud, or in my case ban the hourglass) I have run two copies of browser to avoid the noid. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
shf@well.UUCP (Stuart H. Ferguson) (02/28/88)
*&(Johnathan Dubman) suggest forking a new process for each drawer on the Workbench. Actually, I was considering a design that would fork a new process for each -icon-. Whoa -- what the hell for, you ask? For a vanilla Workbench this would be major overkill, but it would provide great hooks for expandability. The Workbench environment would be a graphical representation of an object oriented system, with the objects running concurently and passing messages among themselves and the Workbench. Such a system could be expanded by programmers adding new types of icons (objects, that is) such as the "suspended-process" type icon (to handle the much saught after "iconification" of a process in a totally Workbench- compatable way). Since all the parts would be modular, someone could write their own drawer window code to display files any way they liked. Lots of other neat things would be possible as well, and probably things I've never even considered. The idea appeals to me at some abstract level too, although the programming would probably be a pain (at first). Perhaps if I have a few free weeks I'll build a prototype. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (02/29/88)
In article <YW8SaQy00Xo4yUc05z@andrew.cmu.edu>, mp1u+@andrew.cmu.edu.UUCP writes: > * Some method must be provided for every file to be visible on > the Workbench, no matter what it is. I want to use the Workbench > as a general file manipulation tool, and I can't do that if every > program doesn't have an Icon by default. How about displaying the filename if there is no .info file associated with the file. Although there are some times when one wants to manipulate filename without affecting filename.info (or, more commonly, to work on filename.info without changing filename) they are rare. Most of the time one's use for an icon is to refer to the file it identifies. It would be easy enough to have Workbench display the name of a file as a default icon if it can't find a .info file for it. A menu option might control this by allowing "Show hidden files". That would allow experienced users to manipulate all the files on their disks while showing a simpler picture to the novice users. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
backstro@silver.bacs.indiana.edu (Dave White) (03/01/88)
Why not just have a menu item which when when selected would display all the files on the current disk which don't have a .info file? The program could allow the files to be selected, moved, etc - much like Peter's Browser program (maybe a modified version of this program could be installed on workbench?)... Sorry if this is a stupid idea.... "And I get on my knees and pray...WE DON'T GET FOOLED AGAIN" Won't Get Fooled Again --The Who
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/02/88)
In article <1030@silver.bacs.indiana.edu> (Dave White) writes: > Why not just have a menu item which when when selected would > display all the files on the current disk which don't have a .info file? The > program could allow the files to be selected, moved, etc - much like Peter's > Browser program (maybe a modified version of this program could be installed > on workbench?)... > Sorry if this is a stupid idea.... It's not a stupid idea, in fact there are many people who complain because you can't do exactly this. The question I have is, "What is the problem we are trying to solve?" There are a couple of things that have been bandied about in this forum since day one, and one of them was the 'all icons in a file' idea to speed up displaying and accessing files via icons. This works if your program wants to read or write a specific disk object, but seems to have problems when you want to read 'all' icons in a drawer. There doesn't seem to be the equivalent of GetFirstDiskObject(), GetNextDiskObject(). [If I am mistaken somebody please enlighten me since I need it for a program I have been writing] The other thing, has been making Workbench useful to the 'expert' user so that anything that the CLI can do, the workbench can do as well. This is somewhat more difficult although not impossible. Every user interface I have used has been based on an action -> (object | group) concept. The user is provided with a naming scheme (FILENAME.EXT in CP/M. Filename in the CLI, ICON in the workbench) and some way of specifying an action, like Copy, Type, Delete, or Rename. The Amiga's workbench uses sort of a 'reverse polish notation' in that you specify the object by clicking on it, and then specify the action. Usually the action is implied by some metaphorical action on the object such as moving it from one drawer to another, other times the action is explicitly defined by selecting a menu item such as 'Rename'. For new users this interface can be more 'intuitive' than typed commands. Where it falls down, as many have pointed out, is when there is an object that the user interface cannot name. And I contend that this is the problem we (in the editorial sense) would like to see solved. Some difficulty arises because AmigaDOS adopts a 'feature' of UNIX that is not as applicable as one might hope. And that is, that a file is a file is a file, and no one but the person using it knows what is in it. When it comes time to display these files with psuedo icons attached to them, it would really help to know just what the heck they were. Doug Fortunately, two types, IFF files and executables, are fairly easily recognized by the data in them. Text file and data files are not so easily spotted. So, the first thing on my suggestion/idea list is : o Provide some level of file type identification. This can be as simple as IFF/Binary/Text/Unknown (2 bits) to something more sophisticated. The other difficulty that the workbench faces is an incomplete implementation of the concept of a 'default' icon. The idea being that when you have a disk with no associated disk.info file, the workbench uses it's default disk icon, however when you have a tool there is no 'default' tool icon. Which leads to suggestion/idea number 2 : o Provide a default Icon for files of the above types, additionally a default 'drawer' icon should be available as well. The latter brings up the third difficulty in Workbench, which is the means provided for getting around the filesystem. If a directory has no icon associated with it, you can't look into it even if it contains icons. This can be eliminated by the use of default drawer icons. Of course there is a *lot* of stuff on the workbench floppy and having all these icons pop up could make a royal mess of the very limited space that is available. Therefore we need the following : o Provide a menu item to enable and disable the display of 'default' icons. The other reason this is beneficial is that if you do enhance the speed of icon lookup with an .icons file you can't cache the icons for files that don't have them. Displaying default icons will still be just as slow as the current system. Of course default icons always have the DEFAULTX, DEFAULTY co-ordinates and cannot be snapshotted. Finally the list of actions that are possible from the CLI but not the workbench need to be made available. Often additional menu items can provide this capability so the final suggestion would be : o Add menu items that include all of the actions one might associate with the CLI. So, the questions for the gallery are : o Did I miss any of your favorite gripes? o Do you see anything you *couldn't* do with a workbench like this? o Be aware that these changes encompass the Workbench, DOS, info.library and the Filesystem. Ta Ta for now... --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.
pds@quintus.UUCP (Peter Schachte) (03/04/88)
In article <43704@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > o Provide some level of file type identification. This can be as simple > as IFF/Binary/Text/Unknown (2 bits) to something more sophisticated. > o Provide a default Icon for files of the above types, additionally a > default 'drawer' icon should be available as well. > o Provide a menu item to enable and disable the display of 'default' > icons. > o Add menu items that include all of the actions one might associate with > the CLI. > > So, the questions for the gallery are : > o Did I miss any of your favorite gripes? Yup. How about: o Make COPY look inside an .icon file for a specific copy program to run in order to copy that icon. Not finding one, copy as usual. Similarly for delete, rename, etc. This would make WB more object-oriented, and would allow icons to represent more than a single file, for example. o To get REALLY fancy with this idea, allow a file (or it's .icon) to specify methods for opening, writing a buffer to, reading a buffer from, seeking in, etc., that file. This would allow some really WONDERFUL things, e.g., files to be stored in compressed form, but still be read and written by ordinary programs oblivious to the storage technique. Or source code files could be stored in pre-parsed format, and be greped, printed, etc., as usual, but editors and compilers could have special knowledge about reading them in as pre-parsed files. The possibilities are endless. I know it sounds pretty radical, but I have some ideas on how to implement it. I think it could make the Amiga about the best-integrated microcomputer environment going. o Provide a mechanism to allow users to add items to WB menus, and to allow users to add new WB menus. And a mechanism for associating keyboard bindings for these items. o Provide some mechanism for specifying flags (or, more generally, any arguments other than files) to a tool. I don't have any good ideas of how to do this. o Allow ASSIGNment of paths of directories to names. This may not sound like a workbench issue, but it does affect how an icon specifies its default tool. Having available a global path would make that so much easier, and would allow users to move tools around without worrying about whether projects will be able to find their tools. I assume CA would also provide a standard name for the execute search path (what we now refer to as the PATH). Path ASSIGNs give more than that, though. Since they would be global, they allow tools to search paths for things other than executables, e.g., devices, libraries, includes, etc. We could move our most frequently referenced such things to ram: for speed, without having to move them all. o Allow dropping an icon into a tool to fire up that tool. o Allow snapshotting tools (or projects, I suppose) onto the background. o CA should supply preference-type tools (probably accessed through preferences) to set up assigns, specify background programs to run on startup, which keymap to use, that sort of thing. Try to minimize the user's need to hack his startup-sequence. Leave startup-sequence around, for generality, but try to minimize the need to hack it in order to do anything interesting. That's enough for now (:-). Actually, I think if we had all that, we would find some REALLY fancy things showing up taking advantage of the generality. I believe all these are things that have to come from CA, unless we talk about replacing WB and DOS. BTW, not all of my suggestions are original, and they are in addition to those copied from Chuck. So how about it, CA, and all you Amiga hackers out there? Any interest in any of these for 1.9 (:-)? What great tools could you have for us if you had these things to build on? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
rogerh@arizona.edu (Roger Hayes) (03/05/88)
Two more (not original): Make the "Please insert..." requestors display the name of the thing they're looking for! Use PATH more generally, particularly when searching for the default tool on a Workbench open. Roger Hayes rogerh@arizona.edu By the way, see IEEE Transactions of Software Engineering, SE-13(12), Dec. 87 pp 1254-1264 for our solution to the IPC problem.
rodney@pyr.gatech.EDU (Rodney Ricks) (03/06/88)
I haven't been on the net for a couple of weeks, so excuse me if this
has already been said, but...
I believe Workbench SHOULD multitask. It is irritating to go into info from
the workbench menu, and click the screen to the back, and not be able to see
what was under it!
On the subject of multitasking in reading in icons from disk, Workbench
should multitask, but it should not schedule the tasks in a traditional sense.
The tasks should be scheduled LIFO, as an extension on some of the more
modern file requesters, i.e. as the disk icons are coming up on the screen,
when the one that the user wants comes up (for example, a drawer), then the
user should be able to double click on it. Workbench should then stop reading
the current drawer, and open the window for, and read in icons for the new
drawer. Then the user could select the program to run (as icons are still
coming up). Workbench should have the system load and start the program, then
return to reading icons from the the chosen drawer, then from the original
when that one is done.
How does that sound?
Oh, by the way, I just remembered a peculiarity about Workbench that I found
a LONG time ago, and meant to post, but never did. Try this from Workbench:
double-click on a disk with icons in its drawer, and move it the window from
where it originally opened. Run loadwb again from the CLI. Double-click on
the same disk icon, to open the window. Activate something in one window,
then (before Workbench "recovers" from the previous action), activate
something (maybe the same thing) in its duplicate. The result is simply
workbench mulitasking with itself. (A copy of itself, that is.)
And if you like my idea, I have a LONG list of suggestions for improvements
to my favorite computer that I will post soon. Don't you feel lucky! :-)
Disclaimer: I speak for myself, and myself only.
Rodney Ricks
UUCP: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!rodney
or : !gatech!gt-oscar!rodney
Mail: 4265 Hidden Valley Dr.
College Park, Ga. 30349fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (03/07/88)
This thread is really about making Workbench useful to experienced users.
The Workbench approach offers several advantages over the CLI. Icons are
more fun than filenames. The graphic display they offer is more interesting
than one made up of pure text. Identifying an object by pointing to its
icon is faster and easier than typing its name. We want to "point and
click" too. OK, what CLI features are missing from Workbench?
(1) Workbench doesn't show all the files on a disk. I think this is
(2) Workbench lacks many of the commands available under the CLI.
(3) You can't extend Workbench by adding a new program to the C:
directory.
(4) Workbench doesn't have the CLI's provisions for I/O redirection.
(5) Workbench doesn't have a default console window for standard input,
standard output, and standard error.
(6) Workbench doesn't handle wildcards in filenames.
(7) It isn't easy to run a program against a file in a different
directory.
(8) Workbench takes longer to display the contents of a directory.
(9) You can't terminate Workbench when you are through with it. You
have to reboot.
Does Workbench offer anything that isn't available in the CLI (besides the
"point and click" mode of operation)? I can think of two things. You can
scroll around in a Workbench window to see more files than will fit in the
window. In the CLI text that scrolls off the screen is lost. Workbench
also gives you the ability to start a new process before its predecessor is
complete. To do that under the CLI you must either have PopCLI or execute
a "NewCLI" or "Run" command.
Although Workbench is generally considered to be more intuitive for naive
users it uses a more complex approach. Instead of just one way to describe
operations it has three. Under the CLI you type commands which take the
form
verb [redirection] [object(s)] [option(s)].
Under Workbench you specify the object(s) by pointing and clicking. You
specify the action one of three ways: (1) clicking again, (2) moving the
object, or (3) making a menu selection.
Now lets look at each of Workbench's deficiencies.
(1) Workbench doesn't show all the files on a disk. I think this is
Workbench's most serious defect.
What would it take to fix this? Obviously we need some way to have
Workbench display something for files that don't have a .info file. We
could use a default image and build an icon or we could just use the
filename. It has to appear on the screen anyway. I am in favor of using
the filename. If it is a directory it should be followed by "(dir)". It
takes less space to display the filename without an icon.
We want to be able to do everything to this icon we can do with a regular
one. We can't, though, because the .info file is where we save the type
(project, tool, drawer, disk, etc.), default tool, and tool types. Only
projects have default tools, so that isn't much of a loss. We already know
it isn't a disk because they already have default icons. We can identify
directories without a .info file, so we can tell if it is a drawer. We
really don't lose much by being unable to distinguish between a tool and a
project. If necessary we can create a .info file. Remember, the CLI
doesn't distinguish between projects and tools until you try to execute a
data file. If you double-click on a data file for which there is no default
tool defined Workbench can display the error message "Unable to load [file]:
file is not an object module" in the screen's title bar. Of course, if you
double-click on a program it will start to run.
One thing we want to think about is whether we should mix real icons and
default icons. If we use filenames as the default icons, maybe we want this
menu option to suppress all icons and display filenames. That would allow
us to manipulate the .info files separate from their main files. One
application for that would be to duplicate a .info file and rename the copy
to create an icon for a file that didn't have one.
(2) Workbench lacks many of the commands available under the CLI.
If we provide default icons for the files in the C: directory we
automatically bring all the CLI commands to Workbench. Of course, some of
those commands weren't designed to work with Workbench. They need a console
window for I/O. We don't want Workbench to automatically open a console
window everytime we run a program, though. Also, we need some way to pass
parameters to the commands.
It's not too hard to pass file names as parameters. Just drag them to the
program and drop them. Extended selection would allow passing more than one
file to a program. The problem is with passing options or other parameters.
Three solutions come to mind.
(1) Forget options. If you want something other than the defaults use
the CLI. This one's simple but you lose the advantage of being
able to point to the files you want.
(2) Put an alphabet of letter icons on the screen. Let the user
include them in his extended selection. I don't like this because
it's a kludge. Besides, options aren't always letters.
(3) Have a "Set options" item on the menu. When you select it a
string requester appears and you type your option list. The string
stays there until you change it (perhaps to a null string) with the
"Set options" item. I like this better. It's still pretty simple
to implement. It's not perfect, but I can't think of anything
better right now.
(3) You can't extend Workbench by adding a new program to the C:
directory.
The solution to (2) solves this problem as well. If you can execute any
program by dropping a file on it you eliminate this problem.
(4) Workbench doesn't have the CLI's provisions for I/O redirection.
How about two special icons on the Workbench screen: "<" and ">". The names
under them are "Stdin" and "Stdout" (or "Standard Input" and "Standard
Output" if you think that would be more user friendly). Drop a file on one
and I/O is redirected to or from that file. The name under the icon would
change from "Standard Input" (or "Standard Output") to the name of the file.
If you want to reset them just double-click on "<" (or ">").
If you don't like the idea of special icons how about menu items that say
"Set Standard Input" and "Set Standard Output". They would work like the
"Set Options" item described above. Menu items make for a cleaner Workbench
screen but the special icons would remind you of the redirection.
(5) Workbench doesn't have a default console window for standard input,
standard output, and standard error.
If we adopt the menu Item solution described above for redirecting I/O we
can allow the user to specify a special sub-option "Console". If that
option is set Workbench will open a console window and execute the program
from there. The user has to know whether a program he wants to run requires
I/O. I don't think that's a problem, because we're talking about making
Workbench useful for experienced users.
(6) Workbench doesn't handle wildcards in filenames.
I don't think there is any way to handle wildcards with a graphic user
interface. So our choices are to open a CLI window and enter the command or
provide a menu item for entering parameters that the graphic interface can't
handle. Call it "Set parameters".
(7) It isn't easy to run a program against a file in a different
directory.
The scheme I described earlier of running a program by dropping a file on it
solves this problem. The current directory would be the one in which the
file resides. That's the way Workbench works now. When you click on a file
that becomes our current directory. But you can now drag the file to a
program anywhere in the file system and start it running.
(8) Workbench takes longer to display the contents of a directory.
I think we have to live with this. By putting all the icons in a single
file you save a little time on file opens. But you still have to read the
image data for each icon for which a .info file (or entry) exists. One of
the nice features of the Amiga is that I can design my own images for icons
instead of having to use a standard one. And it does seem a lot simpler to
me to have a separate .info file for each icon. Putting everything in one
file amounts to creating a separate mini-file system just for .info files.
You have to duplicate all the file management stuff that the regular file
system is already doing for you. That looks like a lot of work, disk space,
and memory for very little increase in speed.
(9) You can't terminate Workbench when you are through with it. You
have to reboot.
This is easy to fix. Put an option on the menu that says "Exit Workbench".
What does this do to the naive user? We have two ways to leave him
undisturbed. One is to have a menu option that turns the advanced features
on or off. The other is to have a separate "Advanced Workbench". Put
"LoadAWB" in your Startup-Sequence file instead of "LoadWB". The Advanced
Workbench shouldn't be any harder to write than a shell, should it?
--Fabbian Dufoe
350 Ling-A-Mor Terrace South
St. Petersburg, Florida 33705
813-823-2350
UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3 theo@xenlink.UUCP (Theo deRaadt) (03/07/88)
In article <727@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > o To get REALLY fancy with this idea, allow a file (or it's .icon) > to specify methods for opening, writing a buffer to, reading a > buffer from, seeking in, etc., that file. This would allow some > really WONDERFUL things, e.g., files to be stored in compressed > form, but still be read and written by ordinary programs oblivious > to the storage technique. Or source code files could be stored in > pre-parsed format, and be greped, printed, etc., as usual, but > editors and compilers could have special knowledge about reading > them in as pre-parsed files. The possibilities are endless. I > know it sounds pretty radical, but I have some ideas on how to > implement it. I think it could make the Amiga about the > best-integrated microcomputer environment going. > -Peter Schachte > pds@quintus.uucp > ...!sun!quintus!pds I was wondering about something almost the same, but in shell files, since I still think that shell has a place in the world. I think that we need some way of specifying what execution environment a program is supposed to run in. Take Unix for example. If the first 2 bytes work out to "#!" it will parse the rest of that line for a program name, and pipe (maybe -c it?) the rest of the file into that program. [ for non-Unix types, #!/bin/sh shell commands... will run /bin/sh and make it read this file, and execute it. ] This seems like something that we could use, in a future release. A friend who is more familiar with ADOS says that this could be built in by having another '#!' hunk? Matt, or a DOS person, care to comment? Does this sound reasonable? Makes running special programs a lot easier. I can just see it now, a makefile that starts out with #!make..... apply the same to C source, and a simple program that compiles from it's stdin, and then executes the output. :-) Sorry.. that's just too weird. I think that the point I am trying to establish is, that this could be used so that various shell scripts of ANY type, could run in ANY environment. The file would know it's environment. ----------------------------------------------------------------------------- Theo de Raadt. ..!ihnp4!alberta!calgary!xenlink!theo -----------------------------------------------------------------------------
morgan@brambo.UUCP (Morgan W. Jones) (03/08/88)
In article <43704@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > o Provide some level of file type identification. This can be as simple > as IFF/Binary/Text/Unknown (2 bits) to something more sophisticated. Don't do that! I happen to think that the Unix approach is right. If you want some way to determine what is what, adopt a convention of .iff, .txt, .bin, .wp, etc. If people don't want to follow the convention, or want to process a file as something other than what it is, they can do so at their own risks. Workbench could even strip off the suffixes. >The other reason this is beneficial is that if you do enhance the speed of >icon lookup with an .icons file you can't cache the icons for files that >don't have them. Displaying default icons will still be just as slow as >the current system. Of course default icons always have the DEFAULTX, DEFAULTY >co-ordinates and cannot be snapshotted. Why not just have a .files file in every directory that is simply a listing of all of the files in the directory and maintained by the system. Whenever the system accesses the directory, it compares the date of the .files file to the date of the directory to see if the file needs to be rebuilt, and if so does. Naturally, whenever the system makes a change to the directory it would update the .files file. Also, the .files file could contain the block address of the file block. This scheme allows for quicker access of directories, bypasses the directory scan if you know what you're looking for (which is something that AmigaDos does very well now), and is totally transparent to anything that already exists. And it seems to me that if there is a default icon and someone takes a snapshot of it, it should be made into a real icon. >--Chuck McManis -- Morgan Jones - Bramalea Software Inc. morgan@brambo.UUCP ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan "These might not even be my opinions, let alone anyone else's."
pds@quintus.UUCP (Peter Schachte) (03/09/88)
In article <209@xenlink.UUCP>, theo@xenlink.UUCP (Theo deRaadt) writes: > I think that > we need some way of specifying what execution environment a program is > supposed to run in. Take Unix for example. If the first 2 bytes work > out to "#!" it will parse the rest of that line for a program name, and > pipe (maybe -c it?) the rest of the file into that program. Sounds useful. So you could start a file #! execute for DOS files and #! shell for cshell scripts. Sort of a default tool, a la workbench, non? Sure, sounds good. Except for two things. First, we already have the workbench default tool, why invent another thing (assuming that we have merged .icon files for time and space savings)? And secondly, this facility assumes that whatever program is being invoked recognizes # as a comment character. Not everything does. The C compiler, for example. AmigaDOS, if I'm not mistaken. You could change it from # to whatever you want, but all programs to be invoked by this program would have to share a comment character, and that seems pretty much impossible. Unless you work out a way to skip the first line when passing the file to the program. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
page@swan.ulowell.edu (Bob Page) (03/09/88)
morgan@brambo.UUCP (Morgan W. Jones) wrote: >the Unix approach is right ... adopt a convention of .iff, .txt, .bin, Yuk. Sounds more like some DEC operating systems, or MS-DOS. I happen to like naming files usenet.info, except that I'm always afraid some utility (like WB) is going to assume it's some file that it should be concerned with, so I end up with usenet-info instead. I just don't want to see suffixes (aka extensions) forced on users, we already have a very flexible naming scheme, and I'd like to keep it flexible. Any application program (including WorkBench) that assumes they own files with certain extensions should be changed. >Why not just have a .files file in every directory that is simply a >listing of all of the files in the directory and maintained by the Why not do it RIGHT and put the list in the directory header, so users can't muck with it? Sure it means a ROM change, but since FFS is going into ROM in 1.4 (by all accounts, anyway), why not change the directory headers to contain file names before 1.4? ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "I don't know such stuff. I just do eyes." -- from 'Blade Runner'
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/09/88)
In article <313@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes: >In article <43704@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >> o Provide some level of file type identification. This can be as simple >> as IFF/Binary/Text/Unknown (2 bits) to something more sophisticated. > >Don't do that! I happen to think that the Unix approach is right. If >you want some way to determine what is what, adopt a convention of >.iff, .txt, .bin, .wp, etc. If people don't want to follow the >convention, or want to process a file as something other than what it >is, they can do so at their own risks. Workbench could even strip off >the suffixes. Well this is probably a religous issue so I won't stand on my soapbox to long :-). The type information, provided by the filesystem/application is a *hint* to workbench exactly like the silly extensions. They need not be mandatorily enforced like VMS, and when you don't know you set the type to "Unknown" and treat them like you do today. As far as an application is concerned it can ignore these bits and read them any way it wants. The four states above could be easily implemented by the programs that create the files, (IFF programs create IFF files, BLINK and compilers create 'binary' files, editors create 'text' files.) It is more like the way 'magic numbers' are treated in UNIX files. Only the data is out of band. >And it seems to me that if there is a default icon and someone takes a >snapshot of it, it should be made into a real icon. That is an excellent idea, I have added it to my list. --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.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (03/09/88)
>for DOS files and >#! shell >... >workbench default tool, why invent another thing (assuming that we >have merged .icon files for time and space savings)? Because it doesn't have enough power! >And secondly, >this facility assumes that whatever program is being invoked recognizes ># as a comment character. Not everything does. The C compiler, for >example. AmigaDOS, if I'm not mistaken. You could change it from # to >... >Unless you work out a way to skip the first line when passing the file >to the program. Exactly! just pass it stdin Seek'd past the first line. The application (CLI, SHELL...) would never see it. If the file is not Seekable, use the default application. Unfortunetly, this will not work with BCPL files. I found out the hard way that BCPL doesn't like file handles passed to it which have been Seek()'d on. Don't ask me why. -Matt
steveb@cbmvax.UUCP (Steve Beats) (03/09/88)
In article <5328@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: > >Why not do it RIGHT and put the list in the directory header, so users >can't muck with it? Sure it means a ROM change, but since FFS is >going into ROM in 1.4 (by all accounts, anyway), why not change the >directory headers to contain file names before 1.4? > I'm not going to get into a religious war here, but just how do you propose to fit a theoretically infinite number of filenames into one directory header? If you say "use extension blocks" then I say "file headers ARE extension blocks". The Amiga file system (yes even the old one) is exceptionally good at looking up files by name. With all the path things you guys are adding, this is a good thing. Did you realise that the CLI looks in at least 2 places for any command typed at the keyboard? These are real Lock() requests. If you start putting lists of filenames onto the disk, you're gonna have to scan those lists, and boy is it going to slow down. I'd like to take this oppurtunity to state that the Amiga filing system, as it stands now, is a really well thought out item, kudos to Tim King on that one. However, I believe it fell down a little on the implementation, BCPL and such, rasberries to Tim for that :-) FFS was re-written to address the shortcomings of the old system and I think it does this quite well. Now we are compatible, it's time to look at suggestions like yours Bob, and start integrating the ones we want into the system before it hits ROM. I would love to try lotsa new schemes for directory management and read/write optimisation, but it's all too easy to fall into the 'second project syndrome' where perfection over- rides the deadline requirements. Unfortunately, real world constraints will preclude this and force us to build on what we have. Steve
cjp@antique.UUCP (Charles Poirier) (03/10/88)
In article <3440@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes: >In article <5328@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >> >>Why not do it RIGHT and put the list in the directory header, so users >>can't muck with it? Sure it means a ROM change, but since FFS is >>.... >I'm not going to get into a religious war here, but just how do you propose >to fit a theoretically infinite number of filenames into one directory header? >If you say "use extension blocks" then I say "file headers ARE extension >blocks". Pardon me? The big problem is that in the current filesystem, the file names are scattered all over the disk. Packing the filenames one per block is about the worst one can do in this regard. Packing as many filenames as will fit into each block, using extension blocks as needed, is about the best one can do. Are you implying these schemes are equivalent? The fact that they both use extension blocks seems quite irrelevant. >If you start putting lists of filenames onto the disk, you're gonna have to scan >those lists, and boy is it going to slow down. The time needed to scan a block of filenames is dominated by the time needed to get that block into memory. Scanning will be fast enough. Besides, you do not need to scan that list for every type of operation. Why not this: Keep the current hashing scheme, AND a compact filename- list scheme. The list form would only be scanned in two cases: when examining all filenames, and when deleting files. The former case is a big win, and the latter is not so bad. For deleting a file, you have to rewrite the extension block containing the deleted name. For creating a new file, you hash to see if the filename exists -- if not, just slap it onto the end of the filename list. In exchange for the trouble of maintaining filenames in two places, you get fast access to known files AND unknown filenames -- a real big win. >I'd like to take this >oppurtunity to state that the Amiga filing system, as it stands now, is a >really well thought out item, kudos to Tim King on that one. >However, I believe it fell down a little on the implementation, BCPL and >such, rasberries to Tim for that :-) Accessing files *by name* works great. But since Tim King stuck us with the "directory search" problem, he gets no kudos from me. BCPL is not the main problem. The problem, from the users' point of view, is that opening a window takes forever; doing a list takes forever; doing a dir takes forever; doing a pattern match takes forever. There are things like filename-completion that we can't even think about adding, because of the stupid directory design. >FFS was re-written to address the shortcomings of the >old system and I think it does this quite well. I obviously don't know how FFS works, especially if and when it is applied to floppies. But you now have me worried. I hope it's not a rehash of what was done for 1.2, just tweaking where on the disk the same old blocks are located. If the filenames are still stored one-per-block, they will end up all over the disk, and directory searching just isn't going to be fast enough. > Steve -- Charles Poirier (decvax,ihnp4,attmail)!vax135!cjp "Docking complete... Docking complete... Docking complete..."
cthulhu@athena.mit.edu (Jim Reich) (03/11/88)
In article <329@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > >(1) Workbench doesn't show all the files on a disk. I think this is > Workbench's most serious defect. It's up there... >What would it take to fix this? Obviously we need some way to have >Workbench display something for files that don't have a .info file. We >could use a default image and build an icon or we could just use the >filename. Why not use a default image? It would take all of (at most) 1/2K of space-- and that's for a big icon -- and could be kept resident in memory. Perhaps the type of icon could be set based on tooltype. Seeing these icons should be a preferences-settable option. Another thought -- it would be nice to be able to see and run most of these applications from workbench, but some things just aren't appropriate for workbench and would merely be confusing. Perhaps all filenames prefixed by a . or a _ could be ignored by the workbench, much like the UNIX invisible .files... >If we provide default icons for the files in the C: directory we >automatically bring all the CLI commands to Workbench. Do we really WANT the SKIP command on the workbench? How about endcli?!?!? > We don't want Workbench to automatically open a console >window everytime we run a program, though. True, but then again we might want one for CLI commands... >It's not too hard to pass file names as parameters. Just drag them to the >program and drop them. Don't drag them, select them. The Mac allows you to force projects upon applications they weren't designed for by selecting both and then selecting OPEN from the file menu... seems like a good idea to me. >(4) Workbench doesn't have the CLI's provisions for I/O redirection. >How about two special icons on the Workbench screen: "<" and ">". >... Drop a file on one and I/O is redirected to or from that file. Bad bad bad. Each program should be allowed to have its own output or input redirected from/to different sources. It would be nice to have a sort of bin to dump a file into so that it would go to standard output or input though. Perhaps it would be used as standard input for the active window? Any ideas, anyone? How about pipes? Tricky. >If we adopt the menu Item solution described above for redirecting I/O we >can allow the user to specify a special sub-option "Console". If that >option is set Workbench will open a console window and execute the program >from there. The user has to know whether a program he wants to run requires >I/O. I don't think that's a problem, because we're talking about making >Workbench useful for experienced users. Yes it is. There SHOULD be a way to do this properly, so that it will work for new users as well. Even experienced users shouldn't have to memorize what needs a console. Moreover, what happens if our hypothetical experienced user screws up? Anyway, it would be a pain for everyone. >I don't think there is any way to handle wildcards with a graphic user >interface. Sure there is -- a wildcard would be used for extended selection -- you enter the wildcard, it selects all appropriate files... >(7) It isn't easy to run a program against a file in a different directory. Yes, something should be done to give the workbench a proper search path to find tools from their projects. >(8) Workbench takes longer to display the contents of a directory. Two simple answers. FFS and single icon files. Believe it or not, the Amiga has FAST drives. It's the file system which is the loss. To read icons the system currently has to read the better part of THE ENTIRE DISK! I'm sure you would be seriously surprised by the speedup (if it ever happens!) >(9) You can't terminate Workbench when you are through with it. You > have to reboot. Anyone made an icon for CLOSEWB? Improving the Workbench would be a worthwhile project. The Amiga Workbench is now pretty much the equal of the MacFinder, but with intuition under the surface and all that power under the hood, we should be able to blow the Finder away entirely... This has been a pep talk to C= brought to you by... -- Jim cthulhu@athena.mit.edu
pds@quintus.UUCP (Peter Schachte) (03/11/88)
In article <8803090742.AA06118@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >for DOS files and > >#! shell > >... > >workbench default tool, why invent another thing (assuming that we > >have merged .icon files for time and space savings)? > > Because it doesn't have enough power! Agreed. I was kind of hoping CA would make it more powerful. Ok, skipping the first line of the file would work. It seems like a good idea. My hesitation in taking this approach is that it tends to widen the gap between DOS and WB. This discussion thread is about doing just the opposite. If there was a good way to put such a line at the top of a file other than by the program that generated the file, or a text editor, this would be good. Remember, the file may not be ascii. Worse yet, it may have internal pointers that could be messed up by adding bytes to the beginning of the file. Yes, I know using relative pointers would solve this problem, but we should be general here. There are advantages to having this information outside the file. Putting this info in the .info file doesn't have the problems I mention. But then care must be taken to make sure this info follows the file wherever it goes. Putting it in the file would do this trivially, and keeping it outside the file makes it harder. It seems that all of this would be so much easier if AmigaDOS had a facility for attaching arbitrary information to a file. Then we wouldn't need separate .info files. Everything would be so much easier. Implementation seems pretty easy. Why didn't they do this? What is wrong with this idea? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
peter@nuchat.UUCP (Peter da Silva) (03/11/88)
In article <329@jc3b21.UUCP>, fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > Does Workbench offer anything that isn't available in the CLI (besides the > "point and click" mode of operation)? You mean apart from a much cleaner and better documented method of starting programs up? > In the CLI text that scrolls off the screen is lost. The fix for this is a better console driver. > (1) Workbench doesn't show all the files on a disk. I think this is > Workbench's most serious defect. So use Browser. Version 1.3 is public domain. > Of course, some of > those commands weren't designed to work with Workbench. They need a console > window for I/O. We don't want Workbench to automatically open a console > window everytime we run a program, though. Also, we need some way to pass > parameters to the commands. It's a lot more complex than this. Have a look in the RKM and the AmigaDOS manual. The environments are radically different. > It's not too hard to pass file names as parameters. Just drag them to the > program and drop them. Extended selection would allow passing more than one > file to a program. That would be a better interface, but Workbench (and Browser) already support this with the shift-double-click procedure. You select all the files holding down the shift key after you select the first one, then (still holding down the shift key) you double-click the program you want to launch. Browser also allows you to put a program into a menu... > (1) Forget options. If you want something other than the defaults use > the CLI. This one's simple but you lose the advantage of being > able to point to the files you want. I'm working on this in Browser 2.0. If you try to launch a CLI program it puts up a string gadget and lets you edit the command line. You can also use the "info" selection in the workbench to modify the default behaviour of properly behaved tools, but modifying the file's "ToolTypes" array. > (2) Put an alphabet of letter icons on the screen. > (3) Have a "Set options" item on the menu. Not practical. There's no place in the startup message to put them. > (4) Workbench doesn't have the CLI's provisions for I/O redirection. Programs started under the Workbench don't have stdin and stdout at all, and I'm not sure there's any way of handling that. > (5) Workbench doesn't have a default console window for standard input, > standard output, and standard error. See above. > (6) Workbench doesn't handle wildcards in filenames. Browser 2.0 will have menu items for "Select all" and "Select matching". > (7) It isn't easy to run a program against a file in a different > directory. No problem. Just open both windows and shift-double-click. > (9) You can't terminate Workbench when you are through with it. You > have to reboot. Why would you want to? -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
jmpiazza@sunybcs.uucp (Joseph Piazza) (03/12/88)
In article <3624@bloom-beacon.MIT.EDU> cthulhu@athena.mit.edu (Jim Reich) writes: >In article <329@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: >Improving the Workbench would be a worthwhile project. Yes. >The Amiga Workbench >is now pretty much the equal of the MacFinder, When did this happen? Workbench 1.2 has been available for a decade or so while Apple releases a new System and FInder about every other week. :-) >but with intuition under the >surface and all that power under the hood, we should be able to blow the Finder >away entirely... Sounds good, but seems to me that Apple has more resources available than Commodore so the Amiga is likely to lag on some features. But then again, has anybody noticed the Mac's "extended menus" in the latest System? ;-) Flip side, joe piazza --- In capitalism, man exploits man. In communism, it's the other way around. CS Dept. SUNY at Buffalo 14260 BI: jmpiazza@sunybcs UU: ...{rocksvax|decvax}!sunybcs!jmpiazza CS: jmpiazza@cs.buffalo.edu GE: jmpiazza >Jim cthulhu@athena.mit.edu
pds@quintus.UUCP (Peter Schachte) (03/12/88)
In article <3624@bloom-beacon.MIT.EDU>, cthulhu@athena.mit.edu (Jim Reich) writes: > In article <329@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > >(4) Workbench doesn't have the CLI's provisions for I/O redirection. > >How about two special icons on the Workbench screen: "<" and ">". > >... Drop a file on one and I/O is redirected to or from that file. > Bad bad bad. Each program should be allowed to have its own > output or input redirected from/to different sources. It would > be nice to have a sort of bin to dump a file into so that it would go to > standard output or input though. Perhaps it would be used as standard input > for the active window? Any ideas, anyone? How about pipes? Tricky. How about this: Output redirection: When a WB-started task produces output (to stdout), a "magic window" is created. This window displays a scrolling view of the output of the task. You see the output as it comes out, and can scroll it at will. There would be a hidden file behind the window. The title bar would reflect which WB tool produced the stuff in the window, and would indicate when the task was complete. The user could then close the window (implicitly deleting the hidden file), or, say through a menu, create an ordinary (permanent, named) file. That way you don't need to decide whether to "redirect" the output of a task until after you see it. Input redirection: The files you select (while holding the shift key) before firing the WB tool are implicitly cat'd and sent to stdin of the task. No problem. Also, you should be able to select a "magic window" for input to a tool in the same way. Pipes: For starters, if you can select a "magic window" for input to a tool before the task that is generating it is finished, you have a kind of pipe. Also, you could close a "magic window" after feeding it to the stdin of a tool, and the bytes would still go from stdout of one task to stdin of the other, but you wouldn't see them. Not closing the window gives you a sort of unix tee. Shell scripts: It would be good if there were some way to create a new tool by composing existing tools, but I can't a way offhand. What's really needed is an iconic programming language, sort of a csh (or sh) that you program by moving and copying icons around. This starts getting hard, and I don't have any ideas on this. Implementation: Not too terribly hard. you have to modify AmigaDOS Write() to understand a new kind of file control block: one that represents an unopened output stream. This fcb (what is the AmigaDOS name for this, anyway?) would be created when WB started up a tool (so WB would have to be patched, too. Not sure how to do this. Anyone?). When Write() got the first request to send a bufferful to one of this fcbs, a file would be created in some temporary place (T:? remember this output may get big!), and a new task would be started to open the magic window and handed a read-only lock on the file. Not too bad, eh? With a good implementation, this could be powerful enough to make many uses of a CLI unnecessary. And with a scripting language and some sort of history mechanism, (and a lot of the other recommendations people have made here), it ought to be able to replace MOST uses of a CLI.-- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
ugpete@sunybcs.uucp (Peter Theobald) (03/13/88)
>> >(4) Workbench doesn't have the CLI's provisions for I/O redirection. >> >How about two special icons on the Workbench screen: "<" and ">". >> >... Drop a file on one and I/O is redirected to or from that file. >How about this: >Output redirection: When a WB-started task produces output (to >stdout), a "magic window" is created. This window displays a scrolling >view of the output of the task. >Input redirection: The files you select (while holding the shift key) >before firing the WB tool are implicitly cat'd and sent to stdin of the >task. No problem. Also, you should be able to select a "magic window" >for input to a tool in the same way. How about new Workbench menu choices: 'redirect' and 'new file.' When you select 'redirect', you then point the mouse at the input file 'click', then draw an arrow towards the application, 'click'. Voila! An arrow represents the input redirection. Or you point at the application, 'click' and drag an arrow to a file, 'click'. You have just redirected output. Or put an arrow from an application to another application. This pipes the output of one to the input of the other. You could have a chain of arrows piping output through an arbitrary number of files and applications. To redirect output to a new as-of-yet-uncreated file, the 'new file' menu choice would simply create a blank file with an icon. Peter Theobald SUNY/Buffalo Computer Science internet: ugpete@cs.buffalo.edu bitnet: ugpete@sunybcs.BITNET uucp: ..!{ames,boulder,decvax,rutgers}!sunybcs!ugpete csnet: ugpete@buffalo.CSNET
pds@quintus.UUCP (Peter Schachte) (03/15/88)
In article <9247@sunybcs.UUCP>, ugpete@sunybcs.uucp (Peter Theobald) writes: > When you select 'redirect', you then point the mouse at the input file > 'click', then draw an arrow towards the application, 'click'. Voila! An arrow > represents the input redirection. Or you point at the application, 'click' > and drag an arrow to a file, 'click'. You have just redirected output. > Or put an arrow from an application to another application. This pipes the > output of one to the input of the other. You could have a chain of arrows > piping output through an arbitrary number of files and applications. This is cute. I'd rather not have to select a menu item for this, though. I do like the idea of an arrow (which presumably goes away when the application starts up). There're a few details you'll have to work out, though. Firstly, how does WB know when you select a tool whether to wait for you to select another tool to pipe the output to? The basic idea is sound, but there are user interface ideas to be settled. > To redirect output to a new as-of-yet-uncreated file, the 'new file' > menu choice would simply create a blank file with an icon. It's better not to have to do ANYTHING to say where to put the output of a process. Firstly, that way you can't forget to do it. In your model, what happens when a process produces output but hasn't been told where to send it? In my model, this is quite clear. My model also allows you to see the output before deciding whether or not you want to put it in a file, send it to another process, or throw it away. I have no objection, though, to what you suggested above in addition to what I propose. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
gab@notecnirp.Princeton.EDU (Gavin Bell) (03/16/88)
In article <774@sandino.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >In article <9247@sunybcs.UUCP>, ugpete@sunybcs.uucp (Peter Theobald) writes: >> When you select 'redirect', you then point the mouse at the input file >> 'click', then draw an arrow towards the application, 'click'. Voila! An arrow >> represents the input redirection. >The basic idea is sound, but there are user interface ideas to be >settled. There's a rather nice tool environment that runs on Mega-$$ Silicon Graphics Iris workstations. It's called 'ConMan' (for connection manager- it has nothing to do with the Amiga program of the same name). The way it works: You run conman first. It puts up a very small icon on your screen somewhere. Then you run each of the tools you wish to use. They do initialization and each puts up its own window or icon, then waits. Now, the user pops up the conman menu, which has only three selections: 'show connections', 'hide connections', and 'get out of conman'. Choosing show connections will bring up lots of little menus, one for each tool. The connections for a tool performing 3-d transformations would be: '-->transformation in' and 'transformation out-->' -- for a tool to display a three-dimensional object: '-->object transformation in', '-->object in', 'bitmap out-->'. To hook up tools, you simple click on the in's and out's you want connected-- a line will be drawn between the entries. To remove a a connection, just click on the two ends of the connection you want removed. One output may be sent to many different inputs, although only one connection per input is allowed. Tools know when to write ouput because they have a menu entry of 'write', which will essentially execute the tool and send it's output down its connections (there are two sets of menus, the connection menus and a tools own private menus-- tools that produce output are written so that they wait for the 'write' menu option to be chosen, tools that always read input can just wait for it to magically appear). Anyway, this user interface works very well. It is easy to use and intuitive. But, the snag is that tools have to be re-written to do the conman calls, and the Unix kernal itself has to be modified. I think a similar workbench interface is possible for the amiga. The connections would be 'Stdin', 'Stdout', and 'Stderr'. The 'lines' inbetween programs would be pipes, and the manager of all this would have a big 'DoIt!' button, which would make it hook up everything and start everything going. Well, I have a few more ideas, but I'm going to wait and see how much discussion this idea gets...
pds@quintus.UUCP (Peter Schachte) (03/17/88)
In article <9324@princeton.Princeton.EDU>, gab@notecnirp.Princeton.EDU (Gavin Bell) writes: > To hook up tools, you simple click on the in's and out's you want > connected-- a line will be drawn between the entries. To remove a > a connection, just click on the two ends of the connection you want > removed. One output may be sent to many different inputs, although > only one connection per input is allowed. This sounds interesting. But the question remains: what happens if you fire a tool without saying where ouptut goes? It doesn't seem like a good idea to only allow users to fire tools when they've specified where stdout goes. What's the matter with having a scrolling window opened automatically when a WB process writes to stdout? My second complaint about this approach is that it is a static setup for a dynamic situation. What if I want to use the same tool in several different pipelines? You could start color-coding your arrows to allow different pipelines to be represented on screen at a time, but I imagine this would get confusing. How about having a menu item "Route Output." You would select a tool, then select "Route Output." This would be like firing the tool, except that its stdout would be piped to the next tool you selected. Of course, you could select "Route Output" before selecting the next tool, in which case ITS output would be piped to the NEXT tool selected. So you could build arbitrary pipelines. But the pipelines would be dynamic: you create them as you need them. For feedback, after you select "Route Ouput," a rubber-band line would emanate from the selected tool, and track the mouse until you selected another tool. For people who like modifier-key accelerations, if you hold the control key while double clicking on an icon, that could be the same as selecting the icon and then selecting "Route Output." It would be easy to use, if not easy to learn. The only remaining issue is how do you handle arrows when you put the same tool in a pipeline twice? E.g., grep | sort | sed | grep | .... And, of course, there's still the issue of shell scripts.... -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
peter@nuchat.UUCP (Peter da Silva) (03/17/88)
Several years ago I suggested a scheme for graphical user interfaces for UNIX. It sank without a trace. Then about a year ago it surfaced again briefly, but it seems to have gone away again. Here 'tis: UNIX pipelines are basically data flow programs. You can implement UNIX pipelines on the Amiga. So: you would have a window that you build your pipeline in. But because it's dynamic, you can do things that are more complex than pipelines... +------+ +------+ | FILE | | FILE | +---+--+ +--+---+ | | +--------+ +--------+ | | +-+---+-+ | CAT | +---+---+ | +---+---+ | XGREP | +-+---+-+ | | +--------+ +--------+ | | +--+---+ +---+---+ | FILE | | AWK | +------+ +---+---+ | +---+---+ | FILE | +-------+ This pipeline combines two files, and leads files matching one pattern into a file, and those matching another pattern into an awk script and thence into another file. Of course, if you prefer you could use ICON or REXX instead of AWK... -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (03/24/88)
In article <761@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > In article <3624@bloom-beacon.MIT.EDU>, cthulhu@athena.mit.edu (Jim Reich) writes: > > In article <329@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > > >(4) Workbench doesn't have the CLI's provisions for I/O redirection. > > >How about two special icons on the Workbench screen: "<" and ">". > > >... Drop a file on one and I/O is redirected to or from that file. > > Bad bad bad. Each program should be allowed to have its own > > output or input redirected from/to different sources. Perhaps I didn't make myself clear. The special icons "<" and ">" would simply pass the redirection instructions along when the program was started. Once one program was started you could use the icons again to start another program without interfering with the redirection that was already set up in the first case. In fact, the concept is the same as with the CLI. Under the CLI you use the redirection symbols "<" and ">" whenever you want them on a command line. You don't have to wait until that program is finished before you can use them on another command line (assuming you know how to use "NewCLI" or "Run". I agree that each program should be allowed to have its own output or input redirected from different sources. I believe my suggestion would provide for that. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (03/24/88)
In article <761@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > Output redirection: When a WB-started task produces output (to > stdout), a "magic window" is created. > Not bad. It seems complicated and I'm not sure how you solve the problem of knowing when a program wants to output to standard output but it might work. I don't like the idea of creating hidden files, though. Perhaps a logical device "StdOut:" could be assigned to RAM: and the files could be written there with a process ID number or some such. Of course, you might want you RAM for something else... Anyway, it's an appealing suggestion. > Input redirection: The files you select (while holding the shift key) > before firing the WB tool are implicitly cat'd and sent to stdin of the > task. > There is a difference between these commands: "pgm file1 file2 file3" and "pgm < file1" and "cat file1 file2 file3 | pgm" Your suggestion equates the first and third. I can think of times you might want to have a program open file1 for output and file2 and file3 for input. When you pass a group of files to the program through extended selection Workbench should cause the same thing happen as if you entered "pgm file1 file2 file3" on a CLI. You could open windows for stdin and stdout automatically and you could solve the output redirection problem by retaining the contents of the stdout window until it is closed or written to a file. But you still haven't solved the problem of redirection standard input, I don't think. > Implementation: Not too terribly hard. you have to modify AmigaDOS > Write() to understand a new kind of file control block: one that > represents an unopened output stream. You could write a new Workbench program along the lines of my suggestion without having to modify AmigaDOS at all. Since Workbench is just an application program sitting on top of AmigaDOS you could provide the new program as an alternative. The greatest difficulty I see it that the CLI and Workbench start programs differently. The program shouldn't know or care whether it was started from a CLI or from Workbench. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
pds@quintus.UUCP (Peter Schachte) (03/29/88)
In article <349@jc3b21.UUCP>, fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > In article <761@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > > Output redirection: When a WB-started task produces output (to > > stdout), a "magic window" is created. > > > Not bad. It seems complicated and I'm not sure how you solve the problem > of knowing when a program wants to output to standard output but it might > work. Do you mean complicated to the user, or complicated to implement. The attraction to me is that it seems simpler than pipes and redirection in unix, but seems (almost) as powerful. The way you work it is that when the program starts up, you create and pass it a special output stream which is defined so that any call to Write() on that stream creates the window, does all the necessary magic, and then patches up the stream (file descriptor) to make subsequent writes write into the temporary file. I think this could be done with a MAGIC: device (gurus correct me if I'm wrong; I've never written a device). > I don't like the idea of creating hidden files, though. The reason I want the file to be hidden is that I want it to go away cleanly unless the user does something with it explicitly. This is important to my model of how it will be used. The idea is that these magic windows represent (present) the output of a task. This data could be put into a file (redirection), or sent to another task (piping). But whatever I do, nothing I don't know about and haven't asked for will be left around when I close the window. Maybe I've misunderstood you. I did expect that the data would be stored in some ordinary file somewhere. The MAGIC: thing is just a way to make sure that a window views the file, and the file is deleted when the window is closed. That's all. The file isn't "hidden" from the OS. > > Input redirection: The files you select (while holding the shift key) > > before firing the WB tool are implicitly cat'd and sent to stdin of the > > task. > There is a difference between these commands: "pgm file1 file2 file3" > and "pgm < file1" and "cat file1 file2 file3 | pgm" Your suggestion equates > the first and third. Sort of. Actually, I didn't address the idea of arguments to programs started from the WB at all. Remember, not all command line arguments are files. Switches, text strings, etc., must be handled, too. I'm afraid I don't see any way to do this automatically for programs that didn't anticipate being used from the WB. Ideally, there would be a way to specify what arguments the program takes, and the super-WB would use this to prompt users for this info in some simple, consistent, and non-troublesome way. And at this level, you could specify a file by pointing to an icon. Any proposals for such a thing? > ... you could > solve the output redirection problem by retaining the contents of the > stdout window until it is closed or written to a file. I guess I did misunderstand you, because this is just what I meant. > But you still > haven't solved the problem of redirection standard input, I don't think. I think I have. What I haven't solved is the problem of command line arguments. > You could write a new Workbench program along the lines of my suggestion > without having to modify AmigaDOS at all. Whatever you do, I think you would have to at least modify WB. I'd hate to have to write it again. Perhaps there would be some way to patch it to set up stdin and stdout as I suggest (and do whatever we decide to do about command line args) before exec'ing the program. I now believe it wouldn't be necessary to do anything to the exec lib. > The program shouldn't know or > care whether it was started from a CLI or from Workbench. Agreed, almost. I think the tool types of the WB are a very useful facility (which should be extended). I wouldn't want them to go away. I also do believe that any program should be able to be started from either a command line or the WB, and that the program shouldn't know whether which. Therefore, I'd like all programs (in fact, all files) to have this sort of information (tool types) associated with them. Given this, I agree whole-heartedly. I do believe this could well be along an expansion path from where we are now without breaking old programs. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (04/01/88)
This continues a discussion of Peter Schachte's suggestion that Workbench be modified to create what he called "magic windows" for handling redirection of standard input and standard output. > Do you mean complicated to the user, or complicated to implement. I meant complicated to implement. I was concerned about the problem of knowing when to open the window. Your approach of creating a standard output file handle for the program and having the device open a window for the file only if data is written to it sounds good. > > I don't like the idea of creating hidden files, though. > > The reason I want the file to be hidden is that I want it to go away > cleanly unless the user does something with it explicitly. This is > important to my model of how it will be used. The idea is that these > magic windows represent (present) the output of a task. This data > could be put into a file (redirection), or sent to another task > (piping). But whatever I do, nothing I don't know about and haven't > asked for will be left around when I close the window. > > Maybe I've misunderstood you. I did expect that the data would be > stored in some ordinary file somewhere. The MAGIC: thing is just a way > to make sure that a window views the file, and the file is deleted when > the window is closed. That's all. The file isn't "hidden" from the OS. OK. That answers my objection. The file really exists, you don't have anything lying around on disk that the OS doesn't know about. Now I have another problem: what do you do if the system crashes before the file is deleted? If the file is confined to RAM: we wouldn't have a problem. Another option which might be simpler would be to simply write the data to a buffer in memory. The device could allocate the buffer and pass a file handle to the program. If the program used the file handle the device would open the window and display the buffer contents. Then the user could save the buffer to a file by a menu option if he wanted. When the program is through with the buffer is simply frees the memory. Nothing is left around unless the user asked that it be kept. What do you think about using a memory buffer instead of a disk file? If the program has a lot of output that approach would tie up a lot of memory. On the other hand, I have 2.5 MB of RAM and 880 KB + 880 KB + 440 KB (2.2 MB) of disk space. It would be a pain to have to swap floppies just because some background process was still writing to standard output. > ... Ideally, there would be a > way to specify what arguments the program takes, and the super-WB would > use this to prompt users for this info in some simple, consistent, and > non-troublesome way. And at this level, you could specify a file by > pointing to an icon. Any proposals for such a thing? No. I'm not sure that's the ideal, anyway. I think the programmer and the user have to know about the arguments the program takes. The programmer who writes for naive users needs to find some more friendly mechanism than command line options. If you use a program that accepts command line options you should be responsible for supplying them. All our super-WB needs to do is find a way of passing them along. The menu option that says "Set argument string" could do that. If the user selects it he gets a string gadget into which he types the arguments. The string gadget gets pasted on the command line after the program name and before the file names. > > But you still > > haven't solved the problem of redirecting standard input, I don't think. > > I think I have. What I haven't solved is the problem of command line > arguments. I still don't think so. You've just found another way to pass the files the user specified as command line arguments. Your "magic window" device could provide standard input by passing a file handle to the program at startup time. If the program tries to read from that file handle the device will open a window and accept input. If we can do it for an output window we can do it for an input window, I guess. But how do you redirect input? How do you tell the super-WB the file handle should point to a disk file instead of an input window? Selecting the files and dropping them on the program's icon (or using the present WB system for selecting the files and double-clicking on the program's icon should pass the names of the files as command line parameters. You still need something equivalent to "<" on your workbench screen. > > The program shouldn't know or > > care whether it was started from a CLI or from Workbench. > > Agreed, almost. I think the tool types of the WB are a very useful > facility (which should be extended). I wouldn't want them to go away. I'm not sure the tool types are that important. More important is knowing the default tool. There's no reason to do away with either, though. Just use the default tool to build a command line to pass to AmigaDOS. Tell me more about how you think the tool types should be used. Perhaps I'm missing something. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3
pds@quintus.UUCP (Peter Schachte) (04/06/88)
In article <357@jc3b21.UUCP>, fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > what do you do if the system crashes before the file is > deleted? If the file is confined to RAM: we wouldn't have a problem. > Another option which might be simpler would be to simply write the data to a > buffer in memory. This seems reasonable. Actually, what I had in mind was to create the file in ram:, but when that starts to fill up, to move it over T:. As you pointed out, many people have much more free memory capacity than free disk space. That's a good point, I've been assuming that before TOO long, most Amigas would have hard disks. This doesn't seem to be coming to pass (I don't have one yet), as the prices haven't fallen the way I'd expected them to. Anyway, I was mostly trying to describe the way the system would feel to the user, rather than how it could be implemented. How about this: the file would be written to MAGICSTORE:, which you could assign as you pleased. Not as efficient as your idea of allocating memory for the bytes, but easier to implement and customize. > Nothing is left around unless the user asked that it be kept. (...if the system crashes.) Good point. But there are advantages to having it remain around in MAGICSTORE:. Suppose when MAGIC: is mounted, it does a directory of MAGICSTORE:, and automagically opens a magic window viewing it. That way your intermediate data wouldn't necessarily be lost on a system crash. > > ... Ideally, there would be a > > way to specify what arguments the program takes, and the super-WB would > > use this to prompt users for this info in some simple, consistent, and > > non-troublesome way. > > I'm not sure that's the ideal. I think the programmer and > the user have to know about the arguments the program takes. The programmer > who writes for naive users needs to find some more friendly mechanism than > command line options. That defeats (part of) the purpose for the whole thing. My goal is that users be able to use more complex tools that are too intimidating now, not because of the tool, but because of its line-oriented interface. Therefore, there should be a language for programmers to specify the arguments their program expects, and their types, and supply help information for it, and the super-WB would have a part that could put up a panel to prompt you for this information, and give you help with it. If this were well-designed, it shouldn't be any slower to use than a command-line interface, and would save you from having to remember all those cryptic switches. > But how do you redirect input? How do you tell the super-WB the file > handle should point to a disk file instead of an input window? Selecting > the files and dropping them on the program's icon (or using the present WB > system for selecting the files and double-clicking on the program's icon > should pass the names of the files as command line parameters. You still > need something equivalent to "<" on your workbench screen. I think you're saying that we need a way to distinguish between passing a file on the command line (which you say is the equivalent of shift-double-click) and passing them as standard input. I was thinking of shift-double-click as specifying stdin, and not command args. I think the reason I didn't draw the distinction is that many (most?) unix tools will take either standard input or (a) file name(s) on the command line, and supplying file names is equivalent to piping them to stdin. For tools like this, the interface description (seems like a good name for the language that specifies the arguments and switches a command expects) would specify this fact, and then shift-double-clicked files would be piped to stdin. For programs that take several files as input, the interface description would specify which are specified by shift-double-clicking. For example, you might want diff to allow you to shift-click two files and then double click the diff icon in order to diff those two files. And lpr (let's call it print) would specify that it wants an arbitrary number of files, but doesn't want them piped to stdin (so that it can put the file name at the top of each page). I'm appealing to the interface description, which isn't even designed yet, to handle this problem. But I'm hopeful. > > > The program shouldn't know or > > > care whether it was started from a CLI or from Workbench. > > > > Agreed, almost. I think the tool types of the WB are a very useful > > facility (which should be extended). I wouldn't want them to go away. > > I'm not sure the tool types are that important. More important is > knowing the default tool.... > Tell me more about how you think the tool types should be used. Ok. This is an excerpt of a posting I made a while ago in this discussion. o Make COPY look inside an .icon file for a specific copy program to run in order to copy that icon. Not finding one, copy as usual. Similarly for delete, rename, etc. This would make WB more object-oriented, and would allow icons to represent more than a single file, for example. o To get REALLY fancy with this idea, allow a file (or it's .icon) to specify methods for opening, writing a buffer to, reading a buffer from, seeking in, etc., that file. This would allow some really WONDERFUL things, e.g., files to be stored in compressed form, but still be read and written by ordinary programs oblivious to the storage technique. Or source code files could be stored in pre-parsed format, and be greped, printed, etc., as usual, but editors and compilers could have special knowledge about reading them in as pre-parsed files. The possibilities are endless. I know it sounds pretty radical, but I have some ideas on how to implement it. I think it could make the Amiga about the best-integrated microcomputer environment going. I didn't make it clear, I realize now on rereading, but I was talking about tool types. It would be really great if a tool type specified a METHOD, in the object-oriented sense, for doing something to that file. This would make each file, in some sense, like its own device. This could be VERY powerful. I'd like the super-WB to do this, but I'm afraid it would need the cooperation of the exec. Anyway, this is how I'd like to see tool types used. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds