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.