Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!decwrl!sun!cmcmanis From: cmcmanis@sun.uucp (Chuck McManis) Newsgroups: comp.sys.amiga Subject: Re: statement Message-ID: <10455@sun.uucp> Date: Mon, 15-Dec-86 15:27:34 EST Article-I.D.: sun.10455 Posted: Mon Dec 15 15:27:34 1986 Date-Received: Tue, 16-Dec-86 22:50:09 EST References: <1107@spice.cs.cmu.edu> Distribution: net Organization: Sun Microsystems, Inc. Lines: 105 Summary: Some technical difficulties These are some comments on Mike's problems with the workbench, yes we would all like to see it go really fast but no, it doesn't do that yet. In article <1107@spice.cs.cmu.edu>, mjp@spice.cs.cmu.edu (Michael Portuesi) writes: > 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). This is one of the better features of 1.2, the workbench opening of directories is much improved. (down to one second rather than two) > 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. And while in theory this is a good thing, there are a lot of files I would just as soon *not* have the workbench clutter up my screen with. All of the devices come to mind, as do all of the CLI specific commands. There are quite a few files that are of *no* use to the workbench user and he/she would probably resent having to wait for their icons to appear. > 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. Ever select info after selecting and Icon? You can pass some things in the ToolTypes field, you can also use extended select to pass filenames. The Wbench startup message has all of that stuff in it. > The icons could be speeded up by putting them all in one file in each > directory...or in a great big file in the root directory. Then you > could write utilities to install, copy and delete icons. A file that > didn't explicitly have an icon definition in the "icon file" would be > given a default "vanilla" icon, sort of what the Mac does for files it > has no specific definitions for. Sorry to disappoint you, however, this would only work if it was the *first* file you wrote to the disk and you never changed it. Since AmigaDOS uses a hashing scheme to locate directory entries it has no compunction about putting directory blocks close together. Thus your "one file" may have pieces of itself all over the disk. A somewhat better approach might be to have an "icon pointer" in directory blocks that points to a linked list of icon file headers in that directory. This would at least prevent you from having to scan the entire directory for .icon files. (There are even free longwords in the Directory block and the FileHead block structures, how about it Andy 1.3?) > 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. It would be a start, personally I would prefer a way of double clicking (shift double click?) If POINTREL requesters really do work in 1.2 then maybe a double menu click would be the way to go. > 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. Huh? With two drives have you tried, put your source disk in DF0: and you destination in DF1:, drag the DF0: icon over the DF1: icon, it asks you to put workbench back in,(swap 1) you do and it throughs up a confirm requester, and asks you to put the source disk back in so you replace the workbench disk in DF0: with your source disk (swap 2) Then the diskcopy routine copys the disk in DF0: to DF1:, voila copied disk and you only swapped twice. > 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). But what about the other stuff the .info file contains, like where on the screen the icon appears, the default tool to run when the user double clicks this icon, options to give to the tool, etc. > As it is, the current Workbench has enough holes in it that I would > label it as unsuitable for the novice user. > Mike Portuesi I wouldn't label it unsuitable, it has improved alot in 1.2 and I assume it will do so even more in 1.3. I hacked together an interface for the Lattice 3.1 C compiler that ran under workbench and it seemed to work out fairly well. Now that some of the tools like Egad! are coming together you should probably be on the lookout for better workbench applications. -- --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.