Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!wagner From: wagner@utcs.UUCP Newsgroups: comp.sys.amiga Subject: Re: statement Message-ID: <1986Dec20.144752.5348@utcs.uucp> Date: Sat, 20-Dec-86 14:47:52 EST Article-I.D.: utcs.1986Dec20.144752.5348 Posted: Sat Dec 20 14:47:52 1986 Date-Received: Sat, 20-Dec-86 15:36:17 EST References: <1107@spice.cs.cmu.edu> Reply-To: wagner@utcs.UUCP (Michael Wagner) Distribution: net Organization: University of Toronto Computing Services, general purpose UNIX Lines: 178 Checksum: 00455 In article <1107@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) says some very interesting things. For the most part, my comments are interspersed with his. However, I think it's worth separating the arguements involved into performance and function issues. Matt's original comment was on performance (and usability, as a result). Some of Michael's comments extend the discussion (in very useful ways, mind you). > >I agree with Matt's sentiments. The performance of the workbench is >simply too slow for it to be considered a viable user interface. I >personally dislike listening to my drive grind and the 2-second delay >between each individual appearance of an icon in a window. Agreed. With 1.2, 2Meg expansion and addbuffers 50, it's better, but still a pain. >I hate >being bothered with a bunch of .info files lying around in my >directory cluttering up the listing of the important stuff there. Well, realistically, this is a problem for the CLI user of a workbench drawer. Not really fair. >I >especially don't like the fact that the Workbench totally ignores >files without .info files -- making it look to the workbench user that >a disk or directory could be totally empty when in fact it is loaded >with files. Couldn't agree more. Workbench should certainly put up some sort of default icon for files without matching .info files. I do like the ability to hide files from the eyes of the casual user though. Perhaps more universal use of the .noinfo trick that the CLI uses, or a flag in the .info file that says don't display me? >In short, I think the Workbench is ill-designed at best. The >Macintosh Finder provides its services in a consistent, quick manner. >I'm not saying that the best design is an emulation of Apple's. What >I am saying is that the following issues need to be addressed: > > 1) The performance of the Workbench needs to be accelerated > tremendously. I haven't seen 1.2 in action yet, but under > 1.1 I don't understand how the novice could tolerate its > slowness, let alone the experienced user (read: hacker). Agreed. Clearly this is a performance issue, and can be fixed at either the application (workbench) or underlying level. I claim that fixing the underlying level (amigaDOS file system) provides more benefit in other areas too (although being a bigger project, perhaps). > 2) The Workbench needs to be more consistent. There should be > an icon for every file in the system when the user opens a > window. Everything that the CLI can see the Workbench > should also be able to see. Agreed. This is new function, and would have to be put into the workbench. However, I think the need is more general than is being stated here. ".info" files are not just icons. They contain all sorts of information about how the associated file should be treated, including the name of the program that knows how to process it, and any options that should be set for the processing of this file. There should be default .info files for files that don't have their own. There should be both a system default and defaults for the surrounding drawer(s). Resolution should be by the system. That is, as now, a system call should give back the .info for this file, but it should be extended to resolve the information request with reference to system defaults and so on. Imagine a default file that specified that anything in this drawer was a project to be used with the DPAINT tool, and had this associated imagery. In addition, it should be possible to reference other files for large portions of duplicated data (such as the imagery). This would allow .info files to contain a very small amount of data, only that part that was unique for this associated file, and point off to imagery elsewhere. > 3) There should be some sort of mechanism to allow the > Workbench to pass CLI-type arguments to its programs. > True, the novice user does not need this and should > probably be shielded from it, but hackers like me would > take the Workbench seriously if this feature existed. This actually sounds a little awkward to use, but perhaps I just can't see the need well yet. In any case, a flag in the .info file saying that workbench should prompt for a single string argument would be easy and usefull. Such a .info file (only one) in the c: directory would supply this functionality for all CLI commands. Individual .info files associated with individual commands could provide more specific prompting services and tailoring. Notice, incidentally, that in a parallel discussion about CLI/shell and prompting mechanisms, we are coming around to the idea that, with each command executable, there should be an associated file containing the operand requirements, and that the CLI should look at it and interact with the user before the command is loaded and run. It seems that the .info files are ideally suited to just that. Moreover, both the line mode shell and the workbench could read these same descriptions. Workbench could put up a requestor to get the results...the line mode shell(s) could just issue textual prompts. Amazingly, no one has mentioned one of the things that bothers me the most about the current .info scheme. There can only be one .info file per 'real' file. I would like to have two icons that point to the same executable or tool, with perhaps different options set (i.e. they differ only in the parameters stored in the .info file). I don't think this is possible in the current scheme. Anyone know how to do this currently? >How to implement these features/improvements? >[...] >The argument-passing mechanism could be implemented as a string gadget >that appears only when the icon is opened when the new option "Open >with Args" is selected instead of "Open" from the "Workbench" menu. >Additionally, Preferences could set a default parameter that would >pop up the arugment string gadget by default when an icon is >double-clicked. We seem to have similar ideas here, although I expect that the flag should be tied to the file rather than the action of opening. I mean, either the command can be called from workbench or it can't. If it can't, then it always need the other interface. No? >When the capability to run CLI programs is added to Workbench, >Workbench users will be able to access the full power of the machine >in a friendly manner. They won't have to mess around with atrocities >like the Workbench DiskCopy which copies a disk in 8 swaps (even when >you have an external drive! -- it assumes you use drive 0 only) when >the CLI version does it in 3. You've baffled me completely here. Workbench never asks me to swap disks at all. To copy disks, you just drag one disk icon over the other. If you select the icon and then the menu option duplicate, you invoke the one-disk duplicate (and then you swap). If you don't like this 'feature' of workbench, don't use it. Granted, it would be nice if the utility underlying were to make better use of available memory, but that's the utilities fault, and not the fault of the workbench. Perhaps I miss the point? >Default icons for "tools" and "projects" will immediately reduce the >number of icons kept around, as every file will no longer require its >own individual icon description to be recognized by Workbench. If a >custom definition does not exist, the default is used -- and the >system only reads ONE file to determine this information for EVERY >program in the directory! The image of the default icons could be >changed with IconEd or Preferences (the same way Preferences now >allows you to change the mouse pointer). We seem to pretty much agree here. Although I must admit that I don't know how you would have separate default icons for tools and projects, since you can't tell one from the other without the .info file you seem to be wanting to avoid. There is, of course, provision in AmigaDOS for a string associated with every file. It's called the file comment, or some such, and it's poorly supported at best. There are conceptually three sources of associated information for each file. There is the file comment, manipulated with the FILENOTE command. There is the textual part of the .info file, manipulated with the INFO menu selection. Of course, that's really an editor. Then there is the imagery, manipulated by the ICON editor. Of course, you have to start out by editing an 'icon of the right type' (read, an info file with the right strings already in it). This uglyness comes from seperating the various parts of what is clearly the same function. Perhaps they could put these functions back together in the next release? >As it is, the current Workbench has enough holes in it that I would >label it as unsuitable for the novice user. I have problems with Workbench, but I use both interfaces all the time, and switch back and forth between them. I'd like to see them more compatable, but I think that workbench is already usable for the novice. I think it's unsuitable for the sophisticated user. >| "Talking about music is like dancing about architecture" | >| --Laurie Anderson, "Home of the Brave" | I just love this quote. I left it in out of appreciation. Michael Wagner (wagner@utcs)