[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:AMIGA NOTES
Notice:Join us in the *NEW* conference - HYDRA::AMIGA_V2
Moderator:HYDRA::MOORE
Created:Sat Apr 26 1986
Last Modified:Wed Feb 05 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:5378
Total number of notes:38326

396.0. "A WorkBench for Hackers" by CONS::BIRKHOLZ (An Experimental PDP Network) Mon Mar 23 1987 15:03

This arose out of an electronic discussion with Wes Plouff.  In that
discussion, Wes assures me that most reasonably proficient Amiga users use the
CLI 99+ % of the time.  I don't think there is anything essentially wrong with
a metaphorical interface like the "desktop", but obviously it holds little
utility for the "expert" user.  I'm writing this because IT DOESN'T HAVE TO BE
THAT WAY.

It seems to me that WorkBench is incomplete.  MOST of the powerful,
UNIX-originated ideas (redirection, generalized files, etc.) have been left
out!  No wonder the expert would rather use CLI.  LARGE wonder that novices
using WorkBench ever discover these ideas.  I don't think mapping UNIX
concepts into the WorkBench is even hard!  At least, that's what I'd like to
find out.  (Some ideas about how to "expertize" the WorkBench follow in a
P.S./Appendix.)

Of course, this is all guesswork on my part; there are a few potential
problems:  Does an iconic presentation of system structures just take up too
much room on an already tiny screen?  Does manipulating an iconic presentation
buy you anything over a textual presentation?  (I can see how typing filenames
can be reduced to clicking on icons, or perusing directories can be speeded
up, but are there other tasks that are too cumbersome to do iconicly?  Of
course, we might just blame such problems on bad presentations, but we won't
really know until we hit a problem.)  Does a useful interface require hooks
that are unavailable in the current exec?

I am most excited by the potential for making ALL system structures presentable
and modifyable.  This would be the EXPERT'S dream!  (OK, THIS expert's dream.)
It could mean ULTIMATE CONTROL!  You could LOOK at the list of tasks and adjust
priorities.  You could LOOK at what device drivers or libraries are loaded; and,
if they think they are being used when you know they aren't (because someone
didn't close them), you could force them to be removed to recover the memory.
You could LOOK at what files were generated by an executable.  You could LOOK at
what memory is being used by a task.  And what about the novice?  With a little
extra work (i.e. pop-up documentation), a novice could become a sophisticated
systems hacker in a month!  (Maybe?) 

Why am I telling you all this?  Because I've got my hands full.  Because I
assume that if you work on this, I won't have to buy it from you.  Because
with many people working on little pieces, exploring different presentations,
the end result is almost guaranteed to be better than if one little group
worked alone.  (This is the vision that drives Richard Stallman and the Free
Software Foundation, no?)

So, what do you say?

-Matt

P.S. / Appendix I

Files:

Here's an obvious one.  It probably exists in the WorkBench already.  Files
have protection bits, filenotes, dates, etc. that are inaccessible (to me)
from the WorkBench.  How about a tool for editing these?  And give me a
default icon so I can see ALL the files -- otherwise I'm back to the CLI.

Redirection and pipes:

Where are redirection and pipes in WorkBench?  No where?  Well, let's make
some!  How about drawing directed pipes (pipes with a one-way valve in the
middle?) from your standard input file's icon to your executable file.
Analogously with standard output.  Pipes (in the UNIX sense) can also be
handled identically.  Executables that open new or existing files and use them
as their standard XXXput would be see to draw a pipe to the file too.

Processes:

Double-click on an executable and it gets wrapped in a process structure
(which can be opened to show status, stack size, priority, % cpu-time used,
etc.) while it executes.  Pipes will sprout as files are opened (perhaps this
should be a selectable option).  In general, all changes to system structures
should be viewable -- especially, locks on files that are not released after
a program exits (presented as pipes that go to/from a file from/to nowhere).

Drivers:

An executable wrapped in a DEVICE or LIBRARY structure would be analogous to
the presentation metaphor for the analogous PROCESS system structure.
(Was that too much to put in one sentence?)

Memory maps:

I want to SEE who's using how much of my memory.  Maybe this note will get
someone to write such a tool for me :-).  (Or maybe someone will just tell me
where I can find something like that already written.)

Confusing the novice:

Of course, we don't want to confuse anybody, or they won't use the interface
to learn about the system.  Many options in the interface should be
user-selectable, i.e. user-turn-offable.  Of course, the UNIX paradigms for
organization (i.e. directories) should save the novice and expert alike from
too many details.  THE DETAILS SHOULD BE ACCESSIBLE, THOUGH!
T.RTitleUserPersonal
Name
DateLines
396.1FeedbackELWOOD::PETERSMon Mar 23 1987 16:2320
    
    Pipes
    	Where are pipes in the CLI ?  I know there is a pipe program
    in public domain, but I didn't think straight CLI has it.
    
    System Monitor
    	Most of the functions you describe are system monitor type
    functions. I do like the ideas and I am willing to help work on
    some of these ideas.
    
    Icon Interface
    	I too would like a better interface. I have been using ZING.
    It is not the greatest but I like it better than CLI or Workbench.
    Most of the complaints about ZING are speed related ( floopies are
    slow ), but if you have RAM or a hard disk ZING works great. Do
    you think this could be a starting place for a new user interface??
    
    
    		Steve Peters
    
396.2Power to the ICONS!SQM::JMSYNGEJames M Synge, VMS Performance Anal.Mon Mar 23 1987 19:0942
	Sounds like this is a discussion for one of the windowing notesfiles,
	but we're all Amigaphiles here and lots of us want to see some
	improvements to the current set up.

	I can certainly believe the 99% number.  I don't even have a copy of
	LoadWB on my normal start up disk.  I have to hunt one down whenever
	I want to show somebody a demo.

	There are several user interfaces where the normal access is iconic.
	Apollo and Xerox's XDE are two such systems.  They are include default
	tools for editting all files.  File types are a useful idea in this
	type of environment.

	I would be willing to use an iconic interface on the Amiga if it
	offerred me some advantage over CLI.  CLI is certainly very primative,
	but at least I have access to all files and can do some limited

	If I could draw a pipeline on the screen, starting with a file,
	into program 1, then to program 2, and finally to a 'new file' icon,
	I'd definitely use such an interface.  This last item should create a
	file but should also have the ability to be displayed until it is
	closed.

	A cute feature on a pipe in use would be a display of the number
	of bytes that had flowed through it.

	It would certainly get pretty messy on the screen if you had more
	than one of these pipelines going at once.

	Of course, a set of programs is often more complex than a simple
	linear flow of data.  It could be a net of programs and files.
	It would be nice to be able to build such a net graphically.
	You would select the 'task builder' tool which would open a window
	which would be the canvas for the picture you build of your network
	of tasks.  You could drag tools (programs) and files from the WB screen
	into this window, then draw pipes linking them.

	I'd certainly like to have a discussion of this topic continue.
	It sounds like we could come up with some very intriguing ideas.

James Synge.
396.3Get ready for the TaskMaster!WHERE::BIRKHOLZAn Experimental PDP NetworkTue Mar 24 1987 14:5588
Re: .1

Where are pipes in the CLI?  Nowhere.  I assume this was an oversight.
There's no reason not to use them and intergrate them into a metaphorical
interface, though; is there?

I know there are system monitor programs out there.  Someday I'll have to
go get them.  Ideally, they could be integrated into The_Hackers_WorkBench
as is.  I'd like to work on these things too, BUT:  I have yet to steel
myself for yet another soaking for yet another developers manual for yet
another windowing system; and, I'm hot for this interpreted C environment
(which I call The_C_Machine) that I'm trying not to work on >8 hrs/day.

Can you tell me/us in a nutshell what nifty ideas ZING embodies?  First of
all, is it an editor, shell, or utility?  Also (for example, if it is a
shell) does it have command recall/editing?  Command history, input, and
output in seperate windows?  As a source of ideas -- "a starting place" --
ZING sounds promising.

Re: .2

I'd rather not follow yet another notes file.  Someone who already does can
probably let us know how other systems present system structures/objects,
and allow the user to modify them.

As in Re to .1, please let us know about the ideas in Apollo and Xerox's
XDE about presenting and modifying system structures (and how they might
apply to the Amiga).  Default editors of different types of files sounds
like the MacIntosh too.  Where could we hook this kind of information into
AmigaDos?  Use filenotes as scripts to execute when a file is
double-clicked?

If you're psyched about the iconic pipe idea, please feel free to write it
for me (scratch that, for YOU, write for yourself :-).

What about complexity control?  It could easily get messy.  A 'task
builder' that creates a new screen or window for each "command" would keep
things clean, but do you really want to "click your way down" to the files
of concern in each new screen/command?  I suppose the Current Directory
could be reflected in a directory window automatically opened (reused?) in
each new screen/command.  In fact, we now have the possibility of more than
one Current Directory!

Etc.

I would also like to see this discussion continue.  (I'd also like to see
some software.  I could probably take some time away from The_C_Machine,
but I don't relish taking some money out of my wallet to get the Intuition
manual.)  Anyway, I apparently AM willing to "waste" my morning, so here's
some more musing inspired by the Lisp Machine environment, the Scheme
Machine, and a multitude of other acquaintances.

The job of the primitive CLI (e.g. CLI!) is to collect names and load the
object indicated by one with the others are arguments.  Interacting with
the CLI consists almost entirely of typing names.  (That's why recall and
editing are often the first things to appear in a new shell!)  The
Hackers_WorkBench will have to do this kind of thing FAST AS GREASED
LIGHTNING in order to "compete".  In principle, this looks entirely
feasible.  First of all, I wouldn't want file objects to be presented as
anything bigger than a boxed filename.  Then a directory wouldn't take up
much more room than a directory listing!  If a directory window is made
parameterizable so that it could sort and filter files, then we've
basically got a nifty directory editor like the ones found on the Lisp
Machine or Chipmunk (Scheme Machine).  Naming a file consists of one click
per directory level.  In principle, this could be really fast.  In
practise, we are bounded by the time to display a directory window.
Unfortunately, "AmigaDog sucks rocks" as one "admirer" put it.  I suppose
we'll have to cache (ideally all) directories in memory.  How expensive is
that, do you suppose?  Who wants to find out, do you suppose?

One big thing I'm concerned about is how to subsume the functionality of
a good shell like Matt Dillon's.  Pipes and redirection have a ready-made
iconic metaphor -- i.e., pipes!  But what about shell scripts?  Command
recall/editing?  Perhaps the 'task builder' could generate new tasks from
old, edited commands/screens.  Shell scripts, though.  That's a toughy.
However, in the interpretive C environment of my C_Machine(tm) (<--
FACETIOUS trademark notice) script files will be automagically reduced to
machine code.  In terms of a graphical metaphor, perhaps a 'script 
builder' screen can organize a sequence of 'task builder' commands/screens
in a flowchart-like description of the script.  Sounds wild, doesn't it?
No, I'm not "tripping"...
I don't THINK I'm tripping...
Am I tripping?

Someone want to do a (tactful) sanity check here?

        -Matt
396.4BAGELS::BRANNONDave BrannonTue Mar 24 1987 21:3621
    re: .-1  sanity check?  is that a fun thing to do? :-)
    
    Look at some technical docs on the Microsoft Windows interface.
    They are trying to sell a windowing interface to an large, established
    base of CLI users.
    
    The window interface has lots of keyboard equivalences for things
    you can do with the mouse.  And gives you the choice of tiled windows
    or pop-up (overlapping) windows.  Directories are displayed as
    filenames, you double-click on the filename you want to run.
    Intuition could learn a few things from them.  
    
    Windows doesn't have the front/back gadgets or sliding screens,
    it seems to prefer tiled screens with scroll bars.
    
    -dave
    
    p.s. i like the discussion, how to represent CLI functions in a
    windowing interface raises lots of interesting questions.
    The Amiga could use a lot more powerful workbench even for the
    non-hacker.