Path: utzoo!utgpu!watmath!clyde!bellcore!rutgers!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!arisia!quintus!pds
From: pds@quintus.uucp (Peter Schachte)
Newsgroups: comp.sys.amiga
Subject: Re: WorkBench Dreams
Keywords: I wish..
Message-ID: <835@quintus.UUCP>
Date: 10 Dec 88 00:08:56 GMT
References: <720@pdp.cs.OHIOU.EDU> <27075@ucbvax.BERKELEY.EDU>
Sender: news@quintus.UUCP
Reply-To: pds@quintus.UUCP (Peter Schachte)
Organization: Quintus Computer Systems, Inc.
Lines: 96

In article <27075@ucbvax.BERKELEY.EDU> me128-aw@kepler.Berkeley.EDU (me128 student) writes:
[Lots of good ideas for a better workbench]

Most of these ideas seem really good.  I've got a few more wishes.  The
substantive ones are at the bottom.

For starters, I agree with arp@pdp.cs.OHIOU.EDU (John Gordos) about
asyncronous activity.  When an icon or gadget is visible, I should be
able to click on it.  This was mentioned a while ago with a plea to get
rid of the Zzz cursor.

>2. No disk icon positions.

It would be nice to be able to snapshot window *sizes* without
snapshotting the position.  Maybe this should be done with an option
that ignores the position but not the size.

>3. Type text, Show IFF picture, print file, print picture from menu?

I'm not sure I understand what you mean.  Are you proposing these as
standard menu items.  I think these would be better placed in a
user-definable menu.  You could provide a default file (say,
s:user-menu) that provides these.

>4. User definable menu.

Great, but why not allow several menus?  It'd make it easier to
organize the items.  Also, there should be a way to change the menus
(by editing the file) without rebooting.

Also, a minor but useful point, if you have a drawer window open selected
when you select a menu item that gets launched CLI-style, that
directory should be the current one for that launch.  So, e.g., you
could work in a drawer window, and then select the MAKE menu item, and
it would know what directory to look in for a Makefile.

>7. Pulling icons out of windows onto the WB screen
>Perhaps allowing them to be snapshotted this way?

Amen!

>10. Option to run as cli
>When you're in showastext mode, how about running the task as a cli process
>if it does not have an associated icon file.

Or if it has a TOOLTYPE of MODE=CLI or something like that.

A few more things:

11.  Items in user-defined menus should be able to run as WB or CLI
processes.  I really miss this in BROWSER.

12.  Allow drag launching.  I.e., I should be able to drop a file icon
onto a program icon, and that would be the same as selecting the file
icon and shift-double-clicking on program icon.  Old idea.

13.  More convenient arg passing.  Currently all you can pass to a
WB-started process is files.  I want to pass switches, strings, etc.
Ok, I can pass these as TOOLTYPEs, and that's good.  But why not have a
standard TOOLTYPE like ARGS=<argument pattern> where <argument pattern
is sort of like CLI command templates.  More generality would be nice,
but the basic idea is good.  Then in addition to the menu item OPEN,
there would be an item OPEN WITH ARGS that would parse the TOOLTYPES,
find the ARGS entry, find the entries and values named in the argument
pattern, and put up a requester window with toggle buttons for boolean
switches, string gadgets for string switches, radio buttons for
multiple-choice switches, etc.  You get the idea.  Then there'd be
SAVE, QUIT, and RUN buttons.  Hitting SAVE would install the
configuration back into the icon.  RUN would close down the requester,
and start up the program with the specified args (I have no idea how to
do this for WB-type programs, but it would be easy if started
CLI-style).  Fixing up WB-startup to include switches is something
Peter Da Silva proposed recently.  This would be a Good Thing, and is
really just a matter of convention.

14.  On-demand scrolling windows for program output.  Instead of opening
a window for program I/O, hand it a stream to a special device that
waits until it gets output from the program before it opens a window.
And when it does get some bits, it stores them away somewhere, and opens
a scrolling window on the output.  Something like a VIEW window, if
you've seen VIEW.  This window would be special, though, in that you
could select it like an icon, and supply it as input to another program.
This would let you do pipelines a step at a time from the workbench.
When the window is closed, the stored bits are deleted, and the stream,
if it's still opened, becomes a like a NULL:  device.  You could also
write the contents of the window to a file.  Again, I don't know how to
do this for a WB-style launch, but for CLI-style, it's easy.  And
again, I believe Peter Da Silva has a proposal for WB that would allow
this (right, Peter?).

I think all this together would be enough to lure a few more
programmer types away from a keyboard-based environment to a WIMP
interface.

-Peter Schachte
pds@quintus.uucp
..!sun!quintus!pds