bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (05/13/87)
In article <> pete@gpu.utcs.totonto.edu > Wouldn't it make more sence to allow WINDOWS to have there own menu systems? > These could be modal (only the active windows menus available) or semi-modal > (active and desktop available). This kind of scheme would make multitasking > much more intuitive. You just described "Intuition", the Amiga user interface. Each window may be attached to a menu strip. *poof*. On the Mac desk accesories can add a extra menu item to the far left of the application's. Try 'key caps' to see this in action. > Now if someone could come up with a graphic rendition of Pipes and > I/O routing, we'd be laughing... Yeaahhhhhaa, that's it. (in my best Saturday Night Live voice) ------------------------------------- Greetings, Earthling -Bryce Nesbitt-
kishore2@watdcsu.UUCP (05/14/87)
In article <8705130929.AA17766@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >In article <> pete@gpu.utcs.totonto.edu >> Wouldn't it make more sence to allow WINDOWS to have there own menu systems? >> These could be modal (only the active windows menus available) or semi-modal >> (active and desktop available). This kind of scheme would make multitasking >> much more intuitive. > > You just described "Intuition", the Amiga user interface. Each window may > be attached to a menu strip. *poof*. > Of course it's not anything new that the folks at C-A thought up. Have a look at the user interface on a Xerox Lisp machine sometime to see a very nice user interface.
pete@utgpu.UUCP (05/14/87)
In article <8705130929.AA17766@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >In article <> pete@gpu.utcs.totonto.edu >> Wouldn't it make more sence to allow WINDOWS to have there own menu systems? >> These could be modal (only the active windows menus available) or semi-modal >> (active and desktop available). This kind of scheme would make multitasking >> much more intuitive. > > You just described "Intuition", the Amiga user interface. Each window may > be attached to a menu strip. *poof*. Then I applaud Intuition. Good Idea. (I have only really used Mac and ST a lot.) > > On the Mac desk accesories can add a extra menu item to the far left of > the application's. Try 'key caps' to see this in action. I have seen this in action, but I don't like it. One tends to start to expect the DESKTOP menu functions to control your accessory. Which of course they usually don't. > > >> Now if someone could come up with a graphic rendition of Pipes and >> I/O routing, we'd be laughing... > > Yeaahhhhhaa, that's it. (in my best Saturday Night Live voice) Funny how such a visual metaphor is so hard to implement... One more idea. One of the reasons I often drop down to a command interpreter while using my ST is that I can pass multiple files as arguments to many programs (ex: cat a.t b.t > c.t). Wouldn't it make sense to be able to HIGHLIGHT these multiple files from the desktop by single clicking, and then ACTIVATE the program by double clicking on it. The result being the filenames (+ volumes/subdirectories?) being passed to the programs in argv,argc form. -- Pete Santangeli pete@utgpu > >------------------------------------- >Greetings, Earthling -Bryce Nesbitt-
ralphw@ius2.cs.cmu.edu (Ralph Hyre) (05/15/87)
>In article <> pete@gpu.utcs.totonto.edu writes ... >> Now if someone could come up with a graphic rendition of Pipes and >> I/O routing, we'd be laughing... Something like the following model (which I first heard described by Steve Berlin at MIT as a user interface proposal for an information system) might be handy for 'visual pipe fitting': Visual shell ("Plumber's Finder") model: ====== Pipes o-, -o I/O connectors /\ /\ o stdin / \ stdout o===o stdin / \ stdout o======[ /dev/null (Garbage can?)] o fd 4 \ / stderr o=+ o fd 4 \ / stderr o=o-in1[Pipe ] ____ \/ | \/ +=o=o-in2[Fitter]out-o=o/ log| Application | Application | |file| Icon | Icon | +----+ +===================+ After the pipelines are built you invoke a 'DOIT' operation which invokes the appropriate commands. (In the above example we're only interested in logging the error output of each program) You could add a gimick where the pipes themselves provide the ability for 'spying' on the data coming through them. You could also reduce the need for 'pipe fitters' (like tee) by making it possible to build pipes with multiple connections on them. File objects (IBM card icon by default) would have 'append' and 'overwrite' input connectors, which correspond the csh '>>' and '>' operations. (appending is probably a reasonable default, so it shold be the most prominent connector.) I'm not convinced that forcing Unix semantics on a graphical model will get you as many customers as would rewriting the applications, but I could be wrong. There's still the problem of passing command line arguments and such, so you will need to change the application anyway. -- - Ralph W. Hyre, Jr. (c) Copyright 1987 by Ralph W. Hyre, Jr. You may redistribute only if your recipients can. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
maciolek@gecrd1.UUCP (05/15/87)
In article <1987May14.125051.3647@gpu.utcs.toronto.edu> pete@gpu.utcs.UUCP (Peter Santangeli) writes: > >In article <8705130929.AA17766@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >>In article <> pete@gpu.utcs.totonto.edu >>>Wouldn't it make more sence to allow WINDOWS to have there own menu systems? >> >> You just described "Intuition", the Amiga user interface. Each window may >> be attached to a menu strip. *poof*. > > One more idea. One of the reasons I often drop down to a command interpreter >while using my ST is that I can pass multiple files as arguments to many >programs (ex: cat a.t b.t > c.t). > Wouldn't it make sense to be able to HIGHLIGHT these multiple files from >the desktop by single clicking, and then ACTIVATE the program by double >clicking on it. The result being the filenames (+ volumes/subdirectories?) >being passed to the programs in argv,argc form. As any number of happy Amigans will be quick to point out, Intuition offers -ALMOST- this very facility, AND avoids the one drawback: that there's no obvious way to de-select an object once you've single-clicked on it. (You see, MOST of the time, when you single-click an icon, then decide "Nah, I don't want THAT icon, I want THIS one", you want to be able to click on the new choice and expect the old choice to go away.) The Intuition answer is that you hold down a SHIFT key while single-clicking individual icons, thus telling Intuition "don't de-select the previous icon when I click on the next; keep all the previously selected ones around." I find this especially useful when moving many files between drawers. Mike Maciolek seismo!rochester!pt.cs.cmu.edu!cadre!pitt!gecrd1!maciolek -consulting for- General Electric "Presumably, it was essential to get the wrong answer as fast as possible." - Kernigan and Plauger, _Elements_of_Programming_Style_
davidh@ucbcad.berkeley.edu (David S. Harrison) (05/15/87)
Peter Danzig here at UC Berkeley has implemented a system in X which allows a user to graphically connect applications together using pipes. The system has been available for quite some time on prang. When prang recovers from its very serious illness, look for Electrician in ~X/berkeley. This work was done as a class project for a User Interface course taught by Larry Rowe. If you are interested in talking to the author, I think he can be reached using the electronic address ``danzig@arpa.Berkeley.EDU''. David Harrison (davidh@ic.Berkeley.EDU)
merchant@dartvax.UUCP (05/16/87)
In article <1987May14.125051.3647@gpu.utcs.toronto.edu>, pete@gpu.utcs.toronto.edu (Peter Santangeli) writes: > One more idea. One of the reasons I often drop down to a command interpreter > while using my ST is that I can pass multiple files as arguments to many > programs (ex: cat a.t b.t > c.t). > Wouldn't it make sense to be able to HIGHLIGHT these multiple files from > the desktop by single clicking, and then ACTIVATE the program by double > clicking on it. The result being the filenames (+ volumes/subdirectories?) > being passed to the programs in argv,argc form. > -- > Pete Santangeli With the Macintosh, you can. You highlight the files, go to the File menu and choose Open. Of course, they must all be of the same type (If you select two MacWrite documents and a MacPaint document and choose Open, it says no.) -- "Where hides sleep?" Peter Merchant (merchant@dartvax.UUCP)
oster@dewey.soe.berkeley.edu.UUCP (05/17/87)
There is a visual metaphor for pipes that is obvious to me but somes to have eluded everyone else. So, I'm giving up my chance for fortune and settling for fame by announcing _Oster's Visual Filters_ 1.) When you connect programs together using pipes, then the first program in the pipeline puts out data. Programs after the first in the pipeline take an input stream, transform that input stream, and produce an output stream. We call these programs "filters". 2.) In a window system, we have data structures called "documents" that are made visible in graphical structures called "windows". In general, a window shows us a piece of a document, and transforms our mouse-clicks and key downs into modifications of the document. 3.) In the real, physical world we speak of water pipes being equipped with filters. (like the pipelines we now use on computers) We also speak of camera lenses being equipped with filters. A graphical filter should be like a camera filter: it mutates the original view. 4.) Camera filters stack. A stack of camera filters is called a "filter pack". Photographers attach and remove entire filter packs, they also add and subtract indiviual filters from existing packs. A named stack of filters, a filter pack, can be used just like a single filter. This idea is very similar to the way we use simple shell scripts now. 5.) the unix program "cat" takes a text file and puts it into a pipline. Our "windowCat" would take a text file and present it in a window. Just for an example, a.)suppose we are looking at a pascal program. b.)Now, in our example, we create a "egrep" filter and place it on top of the windowCat window. We tell the egrep filter "procedure|function" in its "command line" - a pane of the filter we use for giving the filter parameters. The combined pair present us with a new virtual document, or view, that contains only the lines with either "procedure" or "function" on them. our window looks like: ------ procedure IsCancel(a : Boolean); function CMult(a, b : Complex) : Complex; function CDiv(a, b : Complex) : Complex; ... ------ c.) suppose we put a new filter on top of our filter pack: "sort" now we see only the procedure declaration lines from our original program, but in sorted order: ------ function CMult(a, b : Complex) : Complex; function CDiv(a, b : Complex) : Complex; procedure IsCancel(a : Boolean); ... ------ d.) Now, we can take the whole stack of filters we've built and call it "pascalIndex" : we've built a tool for looking at pascal programs that shows us an index of the procedures defined in the program. e.) with an appropriate filter, a virtaul document can be copied into a file, so that it is now a real document, that can be editied with any tet editor. f.) so much we can expect unix filters (bound to the right i/o library) to do for us. Now suppose that we use fresh filters, newly created for this window environment. Then, not only would be able to scroll through a virtual document viewed through a filter pack, but we'd be able to edit it as it stands: Take our pascal index example: suppose we notice a typo, so we click with the mouse to move the typing cursor, then type in the correction. Sort, the topmost filter, preserves a table of where the data it is presenting came from, so it filters the mouse clicks and keystrokes, and informs the filter below it which line I am changing, in the terms of the filter below sort. I may click on the top line and type there, but sort tells the layer below it that I am typing on the 25th line of the document that sort saw as input. Similarly the middle filter, grep, knows that its 25th line corresponds to the 2000th line of the original document, so it tells the bottom layer that I am working on the 2000th line. The bottom layer makes the appropriate change to the document, and everything is fine. So, there you have it, a visual metaphor for pipes. -- --- David Phillip Oster -- "The goal of Computer Science is to Arpa: oster@lapis.berkeley.edu -- build something that will last at Uucp: ucbvax!ucblapis!oster -- least until we've finished building it."
bryce@COGSCI.BERKELEY.EDU (05/18/87)
The idea of selecting multiple files, and then double-clicking the application to act on them is something I've been thinking about quite a bit the last time. I think the idea can be generalised even further. If you view every icon as an object that can be activated, there are only two primitives that you need to do almost everything: - Activating an object (double clicking). This works like it currently does: when you activate a disk/folder, it opens, when you activate a program, it starts running, etc. - Feeding an object (dragging one or more other objects onto it). For disks and folders, it does the same as usual: the objects get stored there. If you feed a program, it starts running with those objects as arguments. The nice thing is a lot of things that are handled in a 'funny' way currently can be incorporated in the general scheme. For instance, to print a file, you move it to the printer icon. It remains unspecified wether this icon represents the device itself (i.e. the OS knows about the printer) or a program that knows how to drive the printer (and that might do spooling, reformatting, etc). -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster. (Sorry for the theft, but this idea has merit)
john@viper.UUCP (John Stanley) (05/18/87)
In article <115@gecrd1.UUCP> maciolek@gecrd1.UUCP (Mike Maciolek) writes: > >As any number of happy Amigans will be quick to point out, Intuition offers >-ALMOST- this very facility, AND avoids the one drawback: that there's no >obvious way to de-select an object once you've single-clicked on it. (You >see, MOST of the time, when you single-click an icon, then decide "Nah, I >don't want THAT icon, I want THIS one", you want to be able to click on the >new choice and expect the old choice to go away.) Where's the "drawback" Mike? As any number of happy ATARIans will be quick to point out, Gem will also clear a previous selection when you click on a new one.... (Note exception below...) >The Intuition answer is that you hold down a SHIFT key while single-clicking >individual icons, thus telling Intuition "don't de-select the previous icon >when I click on the next; keep all the previously selected ones around." I >find this especially useful when moving many files between drawers. This is exactly the same method Gem uses for multi-item selection. The point that the original poster was making had nothing to do with -how- items are selected. The point he (she?) was making was that the people designing Gem have little to no imagination about how to create a really flexable system... If you click on one or more files in a Gem folder-window and then double click on a program icon, that program is run -period-. The desktop throws away the information about which files were highlighted... The sensible thing to have the interface do is to pass the program being run the names of the highlighted files, but DRI never dreamed that the users (gasp) might need any of the multi-file capability that the desktop could embody and which, in fact, it does fully use for its built-in utilitys... I know that DRI has control of the desktop code and would probably never put something this potentialy useful into the system on their own, but has Atari considered collecting a few of these ideas and pointing out to DRI how they could make things much better with a few very small changes? The code to implement this particular change is not very big and allows for some very nice possibilities that are currently impossible and very frustrating... --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
jay@jimi.cs.unlv.edu (Jay Nietling) (05/18/87)
There was a talk at the Usenix 1986 Summer Conference about such an interface. The reference: Paul E. Haeberli, Silicon Graphics, Inc. A Data-Flow Manager for an Interactive Programming Environment Usenix 1986 Summer Conference Proceedings pages 419-428 -jay
tecot@apple.UUCP (Ed Tecot) (05/19/87)
In article <1987May14.125051.3647@gpu.utcs.toronto.edu> pete@gpu.utcs.UUCP (Peter Santangeli) writes: > >In article <8705130929.AA17766@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >>In article <> pete@gpu.utcs.totonto.edu >>> Wouldn't it make more sence to allow WINDOWS to have there own menu systems? >>> These could be modal (only the active windows menus available) or semi-modal >>> (active and desktop available). This kind of scheme would make multitasking >>> much more intuitive. >> >> You just described "Intuition", the Amiga user interface. Each window may >> be attached to a menu strip. *poof*. > > Then I applaud Intuition. Good Idea. (I have only really used Mac and ST >a lot.) >> >> On the Mac desk accesories can add a extra menu item to the far left of >> the application's. Try 'key caps' to see this in action. > I have seen this in action, but I don't like it. One tends to start to >expect the DESKTOP menu functions to control your accessory. Which of course >they usually don't. > >> >> >>> Now if someone could come up with a graphic rendition of Pipes and >>> I/O routing, we'd be laughing... >> >> Yeaahhhhhaa, that's it. (in my best Saturday Night Live voice) > Funny how such a visual metaphor is so hard to implement... > > One more idea. One of the reasons I often drop down to a command interpreter >while using my ST is that I can pass multiple files as arguments to many >programs (ex: cat a.t b.t > c.t). > Wouldn't it make sense to be able to HIGHLIGHT these multiple files from >the desktop by single clicking, and then ACTIVATE the program by double >clicking on it. The result being the filenames (+ volumes/subdirectories?) >being passed to the programs in argv,argc form. You just described how the Mac DOES work! If you select multiple files all of the same type and double click on one of them, the application will open all of them. The restriction is that all of the documents must belong to one application, UNLESS you also select an application, then double clicking will open that application with those documents. Note that only applications which can open multiple documents will do that (not MacPaint). _emt
anson@elrond.CalComp.COM (Ed Anson) (05/19/87)
In article <1987May14.125051.3647...@gpu.utcs.UUCP (Peter Santangeli) writes: > > One more idea. One of the reasons I often drop down to a command interpreter >while using my ST is that I can pass multiple files as arguments to many >programs (ex: cat a.t b.t > c.t). > Wouldn't it make sense to be able to HIGHLIGHT these multiple files from >the desktop by single clicking, and then ACTIVATE the program by double >clicking on it. The result being the filenames (+ volumes/subdirectories?) >being passed to the programs in argv,argc form. > The Finder *does* do essentially that. The finder allows selection of multiple documents. Double clicking on any of them causes the application to be launched and passes the entire list of documents (including owners and file types) to the application. The application does what it will with the information. Take Word, for example. Select several Word documents, double click on one, and all are open in their respective windows. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, UUCP: [decvax, wanginst, savax]!elrond!anson (Just blame me; my boss isn't even certain about just what I do.)
rae@unicus.UUCP (Clith de T'nir a.k.a. Reid Ellis) (05/24/87)
In article <865@elrond.CalComp.COM> anson@elrond.UUCP (Ed Anson) writes: >... The finder allows selection of >multiple documents. Double clicking on any of them causes the application >to be launched and passes the entire list of documents (including owners >and file types) to the application. The application does what it will with >the information. To expand briefly -- when multiple documents of the same type are selected, the 'owning' application runs when the collection is double-clicked. This can be defeated by selecting an application as well, which will be run and given the files, regardless of their type. The Finder's user interface for this is limited in two ways. 1) You can't pass other applications in as arguments (for example, if you want to run 'unpit' to pack together several applications). 2) You can't pass in documents from different folders without going through the somewhat tedious put-all-the-documents-ont-the-desktop, run-the-application, put-the-documents-away (with "Put Away" from the File menu in the Finder) cycle. These two limitations don't exist when running the MPW shell, of course, since the command is the first 'word' on the line. In this way, you can pass in multiple applications from various folder to unpit to do with as you will. (Note this assumes you have unpit 0.3.1, which lets you pack things on startup by holding the option key down) But then again, command-lines are what we're trying to get away from, aren't we? :-) -- "Hey! You're not Ricky Ricardo, you're a cop! And those are potatoes." "Huh? Hey -- the kid's right! You're under arrest, Pal! Whew, you sure saved the day, kid." Reid Ellis, aka Clith de T'nir {seismo!mnetor, utzoo!yetti}!unicus!rae (uucp) mnetor!unicus!rae@seismo.css.gov (arpa)