Path: utzoo!attcan!uunet!munnari.oz.au!ariel!ucsvc.ucs.unimelb.edu.au!lu!tsplib
From: TSPLIB@lure.latrobe.edu.au (Space Physics Library mail.....)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: How to improve Workbench 2.0! (LONG)
Message-ID: <5045@lure.latrobe.edu.au>
Date: 11 Feb 91 21:24:39 GMT
References: <779@caslon.cs.arizona.edu> <1991Feb4.134336.23501@ux1.cso.uiuc.edu> <1991Feb4.151637.5868@mintaka.lcs.mit.edu>
Organization: VAX Cluster, Computer Centre, La Trobe University
Lines: 111

G'day,

{Please do not reply by mail to this account, I am temporarily a guest here. I}
{offer an e-mail address that I think will work below.                        }

RC> rjc@geech.ai.mit.edu      (Ray Cromwell) writes:
RC> ragg0270@uxa.cso.uiuc.edu (Richard Alan Gerber) writes:
RG> dave@cs.arizona.edu       (Dave P. Schaumann) writes:

DS> It would be nice to have something like environment variables for icons with
DS> standard names, so that instead of having default tool be sys:utilities/more
DS> it could be $PAGER (or whatever syntax you like), and then if I *want* to
DS> [...]
DS> Surely this would be an easy thing to do.

I can't believe it!  One of the points I've been wanting/waiting to raise in
comp.sys.amiga.advocacy at my home site (which I'm hoping will pick the news
group up) has been raised in my absence.  Way to go Dave! :-)

RG> Absolutely great idea, Dave! And if the environmental variable wasn't set
RG> you could have the default be the default tool. Give this man a job, C=.

Can I have one too then C= ?  I mean, I've had the exact same idea. :-)  But
seriously we have a convergence of users wills here because we know of three
of us (at least) that would like this feature.

RG> Additionally,  whenever the system can't find either the environmental
RG> variable or the default tool, have a requester inform the user of this
RG> fact and ask him if he would like to help find it. Then up pops a file
RG> requester a la AmigaVision, with which the user sets the path. (excuse
RG> me if this has been covered before, I've missed much of this thread).
RG> 
RG> Regards,
RG> Richard
RG> gerber@rigel.astro.uiuc.edu

Give Richard a job too C=.

RC> PROPOSAL:
RC> 
RC>   Why don't we all particpate in developing some standard Environment
RC> variables for applications to use. Then future updates and new programs
RC> [...good user's eye justification deleted per bandwidth considerations...]
RC> I'll start it off..
RC> 
RC> $EDITOR=path/name of default editor to use
RC> $PAGER=path/name of pager (less,more,leggi, ppmore, etc)
RC> $PAINT=paint program
RC> $VIEW=iff picture viewer
RC> $PLAY=smus/med player
RC> $MOVIE=anim player
RC> $TERM=term

Let us stick with this terminology until/if someone points out objections to
it...

$SHELL=  the name of the CLI shell you wish to be invoked...if a program has
         a CLI window option say (perhaps $CLI?). {With popup shells I can't
         see this as a much needed option.}
$SCREEN= with public screens in OS 2 perhaps the user would wish to select a
         screen for apps to come up on(say a TermBench screen where terminal
         emulators could popup?)

RC> What are the benifits of env vars? How many times has a program assumed
RC> the path of a program. Like a picture file looking for 'myhd:picviewer' ?
RC> Of course you have to edit it with the info command.

This was the same set of events that led me to thinking I should propose it.

RC> With env vars, the Icon can just execute '$VIEW'. Optionally you could even
RC> specify your favorite command line options. One problem with this is,
RC> neither WB nor AmigaShell support wildcard expansion. Until Commodore adds
RC> env var support in icons, it will have to be hacked with an iconx script.
RC> The tooltype of pictures/music/textfiles, etc would have to execute
RC> s:envexpand which would GetEnv the var and execute it.

I may actually give this a go.  I like the concept, hmmm. :-)

RC> Any ideas?

{Not regarding the Env vars for WB.}

These ideas fall into the category of `Workbench should be an equally powerful
alternative to a CLI/Shell' no?  {At least they do for me IMHO. :-)}

A complicated (and I realise unoriginal) idea I've been `Blue Skying' with  is
the notion of alternate(user defined) viewing of the file space directory tree.

You want that in English you say?  Okay :-), but I'll use an example.

Ocassionally, I find myself wanting to consider all of the files  I am working
with (that come from different sub-directories/volumes) as part of 1 temporary
directory structure.  Isn't this idea that of linking directories to appear as
one super directory?

Well yes it is and all I really want is a way to do it from WorkBench... :-)

I don't mean this should be permanent unless the user wants it. I also realise
that some criticisms will be that this is merely wishing for featurism.  I can
admit that you can do without this feature for WorkBench but I'd rather have a
WorkBench environment that has a `look' reflecting the logical structure of an
environment that could be setup via a CLI.  {Philosophy mode off now. :-)}

{Is this is already possible in AmigaDOS2.x with directories if they are link}
{-ed together, and have a .info icon for WorkBench to see?                   }

yours truly,
Lou Cavallo               (e-mail: U3364521.ucsvc.ucs.unimelb.edu.au, I think)

PS:  I'm sorry about the length of this posting.  I've tried to be as brief I
     can and I hope the clarity of my writing hasn't suffered.