mjw@f.gp.cs.cmu.edu.UUCP (05/12/88)
Keywords:
All this kicking , dropping etc seems good.
However, I don't think that I could stand compiling if I had to move
libraries etc about
to get things done.
To make the workbench truly usable (which we have to do to make the amiga a
machine which even kids and mac-users (not serious mac programmers) can use)
we need to provide the functionality of shell scripts, whithout having to
understand what a shell script is.
A modest proposal (which might be bogus, since I haven't thought too deeply
about picture based programming languages).
Make a new type of workbench object : a factory.
Factories contaoin (at least ) 3 types of objecxts:
conveyor belts, loading bays, holding bins.
Primitive tools : opject producers, object duplicators ,
compilers. Editors....
Smaller factories.
Factories have loading bays : these should be object type specific
(if you drop an object on a factory, it should go to the correct loading
bay) . When the correct combination of things appears at the factory
loading bays, the factory starts up.
- Factories should also be able to be told how to order things (i.e files)
I guess these things appear in holding bins.
conveyor belts take things from loading bays, bins, and the outputs of
primitive tools and subfactories to other subfactories, tools, or the
factory output.
Needless to say, factories can be shown as Icons, or expanded.
Scenario: Compiling a program with a make factory:
A make factory contains 2 sets of order forms: 1 set for c files, one
set for lib files. These make the factory fetch (I guess some factories need
a kick knob to start them if they aren't fed anything) the c files and lib
files.
As c files arrive in a holding bin, they are carried on converor belts to
the compiler object, which consumes them (non destructively - the default)
an dspits out some assembler source (e.g.) this goes to an assembler
holding bin (to allow async compile and assem) whence they are conveyed
to the assembler, which spits out the object file.
Compiler switches are just that: the compiler icon should be able to show
a control panel.
Object files go to a holding bin on the linker. The linker has a list of
files which must be there before starting. When they are there, it orders
the correct libraries, and chews until it spits out a executable.
Notes : I know that I haven't dealt with such things as 'written bits'
but I believe that the analogy can extend to cover m,ost of the tthings one
can do with a O.S.
Sorry anbout the typos, too painful to correct through Dnet at
1200 baud.
When I say compiler, I mean a object which encapsulates the compiler
code. In fact, I imagine that sometimes, such an object will act by
assembling a command line to a regular progtram on the basis of its
inputs and switches, and then just spawn a cli to execute that command line.
Notice how nicely this allows evenm the naive user to correctly use
multitasking hrough a proiducer consumer model.
This is in the spirit of looking at the problems that other systems solve,
(in this case shell scripts and naive user fdriendlyness), and trying to
solve the same problem better.
--------------------
I think this has potential, and is quite doable -
I'd be tempted to hack up a prototype myself if I wasn't goingg to be
out of the country for a month.
Let me know what you think.
Michael
--
Michael.Witbrock@cs.cmu.edu mjw@cs.cmu.edu \
US Mail: Michael Witbrock/ Dept of Computer Science \
Carnegie Mellon University/ Pittsburgh PA 15213-6890/ USA /\
Telephone : (412) 268 3621 [Office] (412) 441 1724 [Home] / \cmcmanis%pepper@Sun.COM (Chuck McManis) (05/13/88)
I like the factory idea. I was thinking that the compiler object could be
'opened' like a window and the libraries moved into it. But the idea of
an 'order' form has appeal as well. An object that contains pointers to
objects (maybe you could represent this as a window with ghosted icons
in it, add pointers by dragging an icon into the window, the ghosting
indicates it is a pointer.) then drop the order form onto the compiler
and poof. And a shortcut for 'do it again' would be nice too.
--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.pds@quintus.UUCP (Peter Schachte) (05/14/88)
In article <1665@pt.cs.cmu.edu>, mjw@f.gp.cs.cmu.edu (Michael Witbrock) writes: ... > Make a new type of workbench object : a factory. > Factories contaoin (at least ) 3 types of objecxts: > conveyor belts, loading bays, holding bins. ... > Needless to say, factories can be shown as Icons, or expanded. This analogy is cute. Very visual. I expect a naive user could learn to build such factories without too much trouble. Of course, I'd like to see several example factories before I'm really convinced. It might be useful to take a few existing unix shell scripts and see if you can express everything they do with this model. Things like string handling and conditionals need to be worked out. There is one thing I'd like to see added: demand driven factories. You've suggested a sort of supply-side system. I'd like to be able to "pull" somthing out of a factory sometimes. Make is a good example: you want to pull the latest executable for some program out of the factory. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
Tri-Soul@cup.portal.com (05/15/88)
Lo there,
I think in one respect it is sort of being done or was with another
language....cannot remember the name at the moment.. But I like the
metaphor involved... would be interesting to see.
------------------------------------------------------------------------------
I do not brake for Hobbits,
Hell I stop and chat...
Tri-Soulaugi@cbmvax.UUCP (Joe Augenbraun) (05/17/88)
In article <53116@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > I like the factory idea. I was thinking that the compiler object could be > 'opened' like a window and the libraries moved into it. But the idea of > an 'order' form has appeal as well. An object that contains pointers to > objects (maybe you could represent this as a window with ghosted icons > in it, add pointers by dragging an icon into the window, the ghosting > indicates it is a pointer.) then drop the order form onto the compiler > and poof. And a shortcut for 'do it again' would be nice too. > The problem with any scheme like this is that you need to be able to see the icon for any given program (the particular "factory" if you will) in order to use it. This means searching your subdirectories to find the one that you want, which is in effect the same as having a tree structured menu system. This problem can be allieviated to some degree by allowing the combining of small factories into superfactories, with each small factory becoming a process in the new superfactory. The object (how about widget?) can be sent through any or all of the processes in the factory in any order (using a work order), or sent into other factories for further processing. Each process could have its own control panel. I don't really like that solution, but its the best one that I can think of. It only helps to reduce the number of icons that the user has to deal with, not with the fact that we are basically talking about a tree structured command system. Any better ideas for solutions? -- Joe Augenbraun ucp: {uunet|ihnp4|rutgers}!cbmvax!augi System Engineering arpa: cbmvax!augi@uunet.uu.net Commodore Business Machines Phone: 215-431-9332
UH2@PSUVM.BITNET (Lee Sailer) (05/18/88)
In article <3784@cbmvax.UUCP>, augi@cbmvax.UUCP (Joe Augenbraun) says: > > >The problem with any scheme like this is that you need to be able to see >the icon for any given program (the particular "factory" if you will) in >order to use it. This means searching your subdirectories to find the one >that you want, which is in effect the same as having a tree structured >menu system. There are a couple of solutions, none perfect I guess. 1. When built, factories could appear in the WorkBemnch Screen menues. 2. There could be a factory that found other factories. 3. If it were easy to get icons out onto the desktop, there could be twenty or thirty factories, represented by small icons, along the bottom of the screen 4. There could be a screen for factory icons. The main point remains valid for WIMP interfaces---it is sometimes hard to find the thing you want to point at. lee