Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt.cs.cmu.edu!spice.cs.cmu.edu!mjp
From: mjp@spice.cs.cmu.edu (Michael Portuesi)
Newsgroups: comp.sys.amiga
Subject: workbench
Message-ID: <1111@spice.cs.cmu.edu>
Date: Thu, 18-Dec-86 16:08:07 EST
Article-I.D.: spice.1111
Posted: Thu Dec 18 16:08:07 1986
Date-Received: Fri, 19-Dec-86 00:25:32 EST
Reply-To: mjp@spice.cs.cmu.edu (Michael Portuesi)
Organization: Carnegie-Mellon University, CS/RI
Lines: 187

Keywords:


I've been meaning to reply to everybody's comments about my original
post, but things got in the way (now that finals are over, I've
discovered what it's like to actually sit down and read fiction
instead of textbooks).  In any case:

Having icons for every file
---------------------------
Chuck McManis:
> 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.
 [...]
> 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.

Gerard Lachac:
> This is ridiculous!!  Even the Mac doesn't give you this.. (ever play
> with MacTool??)
> I can just see it now, opening up my c drawer on the workbench and 
> have 30 icons pop up!  How useful!!!  :-)

No it isn't.  What if I wanted to copy some of those files from the c
drawer to a new disk?  What if I need to delete a few of these
lesser-used commands to free up some space on the disk?  If you don't
let me see them, I can't manipulate them (unless I use the CLI, of
course).  Opening up the "System" folder on the Mac reveals the System
file, the Finder, the Clipboard...why does the user need to see these?
So he can copy them elsewhere and delete them if he has to, that's
why.  If you don't want to see 30 icons on your screen from the c
drawer, don't click on it.  And you wouldn't have to wait long for
these "useless" icons to appear either, if icons were moved to one
file instead of many.

As for the other stuff the icon contains (like what tool to run,
options, etc) simply put up a requester telling them "There is no tool
for this project" or something like that.  That's what the Finder does on
the Mac.  As far as screen location, I'm sure the Workbench could
figure a suitable default location to place the icon in a window if
its not explicitly specified.  Not having an Intuition manual, I don't
know exactly what is stored in an icon...but I'm willing to bet it
could either be ignored or some reasonable defaults supplied.

Charles Poirer:
> Let's not forget, too, that if ALL files are represented in the icons
> file, then one could use the icons file as a complete directory
> listing.  No more need for all this grinding just to put up a file
> requester!  Use the current directory scheme only for what it is
> optimized for: single file access by (unglobbed) filename.

I didn't think about that...but that's certainly an argument in my favor.

> While I'm at it, let me add my vote in favor of uniform filename
> expansion at the CLI level.

And let me add my vote against it.  If the CLI has to expand
filenames, then under my proposal the Workbench would have to as well.
Nothing like duplication of code in concurrent programs wasting
memory.

Argument passing
----------------

Chuck McManis:
> Ever select info after selecting an 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.

Andy Finkel:
> Setting the ToolTypes field of an icon is meant to do just that.
> But you want a quicker way, I guess.

Some things?  Can I pass everything that CLI can and where is the
documentation for this ToolTypes field?  I'm not flaming here...I want
to be educated.  If the ToolTypes field really does have the
functionality I describe then my gripe is null.

Andy's not altogether far from the truth that I do want a quick way to
pass arguments to a command from Workbench.

Implementing an argument-passing Mechanism
------------------------------------------

Chuck McManis:
> 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. 

Charles Poirer:
> Let me suggest a tweak for Worchbench arguments: use Left-amiga-click
> as Open-with-arguments.  This can be an alternative to having to go to
> the Workbench menu, i.e.  support both methods.

Okay, that's even better than my original suggestion.  This would be
faster than selecting Info to access the ToolTypes field.

Accelerating performance
------------------------

Matt Dillon (from multiple messages):
> What I purpose is simply a reorganization in the disk format (one
> .info file per folder rather than lots of little ones).  This seems
> best since things are already arranged in a directory-uniform style.
> Placing all the information in a single file in the root directory is
> NOT a good idea.

> What some of you are proposing would require modifications to the workbench
> message format, and that is simply impractical.

Eric Lavitsky:
> What happens if you accidentally blow away the file that has *all*
> the icons in it? Bye bye icons!

Okay, so the best method probably is a file of icons per directory.
The "great big file" idea was merely a suggestion...as is all my
flaming.

Matt, I realize you want to make transparent changes to
Workbench...but I really do think some more substantial changes to
Workbench should be made at the same time.  "User-friendly" does not
have to equal "User-useless".  Why is changing the Workbench message
format impractical?

Dan Green:
> I think the "ideal" situation would be for the linker to reserve
> 512 bytes or so as the header for each program, (and fopen'ing a new
> file could pad the top with the header also) and then store the .info
> in this area.  Of course TYPE would have to be smart enough to skip
> the header, which is trivial.

And so would MicroEmacs and every other program that deals with stream
input.  Even I'm not radical enough to modify the format of individual
files.

Eric Lavitsky:
> Please queue up mouse events for the Workbench, or at least make it
> an option from Prefences (like CLI on)...

Not a bad idea, and I think it's worth implementing, but band-aids
don't fix leaky pipes...new pipes do.

Diskcopy from workbench
-----------------------

Chuck McManis:
> 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
[etc...]

Gerard Lachac:
> Hmmmm...  every time I use to use the WB for diskcopy it was the
> same 3 swaps... except with a cute little window attached!

Looks like I got bit on this one...next time I'll make sure I know
what I'm talking about before I engage my mouth.

My assessment of the workbench diskcopy was from someone else using it
on our user group's two-drive system.  He didn't know all the details
of its operation, and watching it in use turned me off on it from that
point on.  I didn't attempt to use it on my own one-drive system until
Chuck pointed out it wasn't as bad as I thought...I haven't tried his
suggestion on a two drive system, but I'm sure he's correct.  On my
system, it wanted five swaps, but I also had a number of commands in
ram: plus PopCLI and a few other programs running, so I wasn't
surprised.  I take back everything I said about Workbench diskcopy.

Andy Finkel:
> BTW, under V1.2, the Workbench Diskcopy and the CLI Diskcopy
> are the same program.

Nice to hear that...two programs to do the same thing is a little
silly, even if I don't know what I'm talking about.
-- 

+----------------------------------------------------------------------------+
| Mike Portuesi								     |
| Carnegie-Mellon University Computer Science Department		     |
|									     |
| ARPA: mjp@spice.cs.cmu.edu						     |
| UUCP: {harvard | seismo | ucbvax | decwrl}!spice.cs.cmu.edu!mjp	     |
|									     |
| "Talking about music is like dancing about architecture"		     |
|			--Laurie Anderson, "Home of the Brave"		     |
+----------------------------------------------------------------------------+