chekmate@bloom-beacon.UUCP (05/12/87)
I've been thinking for a long time about the ideal user interface on a graphics-intensive computer. The window and icon system popularized on the Mac seems to me a step in the right direction, but I still have reservations. Some of my major concerns: - most icon systems put too much emphasis on graphics for my taste. Text has it's own special advantages: - input speed (if you're a touch typist) - output speed - flexibility (e.g. moving around a tree directory structure) I'm not saying text is king; I just think we need some balance. - the windowing concept doesn't seem to be efficient; there are lots of things the user can do that he doesn't need, and these extra features take a lot of compute power. I'm sure we've all seen novice users spend half an hour resizing windows and shuffling them around. - What use is a window that is half-hidden? Why would anyone want to see only the left half of a document? If the right half is unnecessary, why show the document at all? Microsoft's tiling system doesn't have this problem, but it isn't intuitive enough. - Do we need to move windows arbitrarily like pieces of paper? What difference does it make whether a window is a few pixels to the left or right? - At the same time, current window systems don't really use the potential of these machines. These computers can simulate arbitrary universes; we confine them to a mildly mutated desktop. I guess I am attacking the desktop metaphor; just because it's familiar doesn't mean it's good. I think a good user interface ought to concentrate the available power on productive, often used functions (like a RISC chip :-)). One shouldn't spend programmer time and computer time adding bells and whistles that let the user do useless things. Of course we also need a system that is "intuitively obvious", and these requirements often conflict. In essence, I'm posing some open questions; what features belong in this kind of system? For example, I often hear windows described as independent terminals - why not endow them with all the capabilities of the physical terminal (window recursion)? Is this useful? If there is an ideal window arrangement for certain applications, do we need to let the user mouse around trying to find it? What kind of metaphor should we use, if not the desktop? Is a real-world metaphor necessary? The fundamental question is, how can we make the important stuff available at the right time, without cluttering the display with leftovers and without forcing the user to clean up after us? I realize I've been long-winded, but I feel that the hardware is just sitting there begging to be used, and when the software catches up we're really gonna see what these damn machines can do. Adam
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/12/87)
> - most icon systems put too much emphasis on graphics for my > taste. Text has it's own special advantages: Which is one reason I like the Amiga... you don't have to use the icon oriented workbench if you don't want to. > - the windowing concept doesn't seem to be efficient; there > are lots of things the user can do that he doesn't need, and > these extra features take a lot of compute power. I'm sure If you don't like them, don't use them. As long as the 'extra' features don't effect anything else, if you don't use them, it's as if they didn't exist. > - What use is a window that is half-hidden? Why would > anyone want to see only the left half of a document? Extremely useful. You are generalizing that a user will always want to see the entire window he is working in, which is completely and totally wrong. Many times I have a window or windows that I'm working in that I *want* half hidden. But again, there is a solution if you don't like half hidden windows, you can always use one of the several Freeware programs to automatically put the selected window up front (and other things...) > - Do we need to move windows arbitrarily like pieces > of paper? What difference does it make whether a > window is a few pixels to the left or right? It makes a big difference to me! > - At the same time, current window systems don't really > use the potential of these machines. These computers can > simulate arbitrary universes; we confine them to a mildly > mutated desktop. I guess I am attacking the desktop > metaphor; just because it's familiar doesn't mean it's good. This would be a problem with the workbench. The developer can easily opt for SuperBitmap windows (a window into a larger universe) when he writes his software. >I think a good user interface ought to concentrate the available power >on productive, often used functions (like a RISC chip :-)). One >shouldn't spend programmer time and computer time adding bells and >whistles that let the user do useless things. Of course we also need I agree, but you have to be careful on your definition of "useless". If a hundred thousand people like it, it isn't "useless". >The fundamental question is, how can we make the important stuff >available at the right time, without cluttering the display with >leftovers and without forcing the user to clean up after us? > >I realize I've been long-winded, but I feel that the hardware is just >sitting there begging to be used, and when the software catches up >we're really gonna see what these damn machines can do. That's one big question. Obviously there is no single correct answer. If you have an idea, by all means voice your opinion. (Me, I usually voice my opinion quite loudly, but also make an attempt to implement the idea to backup my opinion) -Matt
pete@utgpu.UUCP (05/13/87)
Hi Yall, On the subject of Window recursion, the one part of most windowing systems I find counter -intuitive is the difference between the desktop and a window. 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. Now if someone could come up with a graphic rendition of Pipes and I/O routing, we'd be laughing... Pete
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-
barnett@vdsvax.UUCP (05/13/87)
In article <565@bloom-beacon.MIT.EDU> chekmate@artemis.UUCP (Adam Kao) writes: > - What use is a window that is half-hidden? Why would > anyone want to see only the left half of a document? More to the point is looking at the top half of a document, while typing in another document. Reading the Unix Manual pages, or looking at example source code while editing is very nice on a Sun. In fact, I like typing in on a window that is UNDER another window at times. example: input to a program while looking at as much of the source as possible. (Why on earth did it output THAT? :-) > - Do we need to move windows arbitrarily like pieces > of paper? What difference does it make whether a > window is a few pixels to the left or right? Sometimes I move my Sun windows around to get the maximum usage possible. This often means butting windows together. -- Bruce G. Barnett barnett@ge-crd.arpa, barnett@steinmetz.uucp ...!{chinet,rochester}!steinmetz!barnett
mike@ames.UUCP (Mike Smithwick) (05/13/87)
In article <1987May12.233757.24441@gpu.utcs.toronto.edu> pete@gpu.utcs.UUCP (Peter Santangeli) writes: > > On the subject of Window recursion, the one part of most windowing systems >I find counter -intuitive is the difference between the desktop and a window. > Wouldn't it make more sence to allow WINDOWS to have there own menu systems? In a sense, the windows do have their own menus, the active windows are given their own menu strip at the top of the screen (if the programmer attached one to it, that is). >These could be model (only the active windows menus available) or semi-model >(active and desktop available). This kind of scheme would make multitasking >much more intuitive. I much rather prefer the Sun approach, which uses popup menus, as opposed to the pulldowns. With the Sun, each window, no matter what, has it's own menu. It can have a system default menu attached to the border,(used for resizing, pushing/popping, etc.), and as many user defined menus for the application within the borders. There is also a user-definable "root-menu" to support their desktop. This menu is attached to the background screen, and is constructed from a dot file in the user account. That is, the user specfies in a simple text file, the programs they want callable from the root-menu. The menus also support seemingly infinite levels of nesting, whereas Intuition has a maximum of two levels (one of it's major flaws). Just a few random thoughts from the cortex of . . . -- *** mike (powered by M&Ms) smithwick *** "ever felt like life was a game, and someone gave you the wrong instruction book?"
hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi) (05/13/87)
pete@gpu.utcs.UUCP (Peter Santangeli) writes: > On the subject of Window recursion, the one part of most windowing systems >I find counter -intuitive is the difference between the desktop and a window. > 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. > Now if someone could come up with a graphic rendition of Pipes and >I/O routing, we'd be laughing... > >Pete The Amiga, in fact, does use this design. The menus available at the top of the screen are always the menus for the active window, no other. If you are running an application on the standard desktop, you can get to the desktop menu bar by simply clicking in the background area (i.e., outside of any window on the desktop), and then the desktop menu is used. Otherwise, the menu bar contains the menu for whichever window is active. I believe this is the design used in Servant, and possibly the design used in Juggler (although I wouldn't know). Clearly this is necessary in a multitasking windowing scheme; for a single-tasking machine, it is of much less importance. -Mitsu
munson@ernie.Berkeley.EDU (Ethan Munson) (05/13/87)
In article <565@bloom-beacon.MIT.EDU> chekmate@artemis.UUCP (Adam Kao) writes: >I've been thinking for a long time about the ideal user interface on a >graphics-intensive computer. The window and icon system popularized >on the Mac seems to me a step in the right direction, but I still have >reservations. Some of my major concerns: > - most icon systems put too much emphasis on graphics for my > taste. Text has it's own special advantages: > - input speed (if you're a touch typist) > - output speed > - flexibility (e.g. moving around a tree directory structure) > I'm not saying text is king; I just think we need some balance. You have a good point here. For experienced users, a mouse-intensive interface can be a pain. The reasonable solution is to have most operations, or at least the most common, available at both the mouse and the keyboard. It is important to recognize that keyboard-oriented commands are not so good for novice or irregular users, who forget command names and syntax and don't even have a very good feel for what it is they are trying to do. The graphic orientation makes it a lot easier to get people to actually use their computers. Us pros are another matter. We understand our machines very well and, frankly, a user-hostile environment may be better for us, at least in terms of raw productivity on well-practiced tasks. > - the windowing concept doesn't seem to be efficient; there > are lots of things the user can do that he doesn't need, and > these extra features take a lot of compute power. I'm sure > we've all seen novice users spend half an hour resizing windows > and shuffling them around. I think you're missing the point. For most of the tasks that PCs are used for, a 68000 clocked at 8MHz with a text/command-line OS (like MS/DOS would be) is a ridiculous waste of compute power. The reason that it is acceptable to have a windowing system on these machines is that there is a lot of excess computing power available in the machine and you might as well use it to make the machine more pleasant to the user. You would never consider using a real window interface on a basic IBM PC because the chip/architecture just doesn't have the stuff to support it (MS Windows, nowithstanding). You shouldn't worry about the inefficiency of supporting a fancy graphic interface because these machines are not intended for computationally intensive tasks. Rather, you should worry about making the machine attractive to use for those tasks that used to be done by hand (producing charts, filing data, typing, bookkeeping). > - What use is a window that is half-hidden? Why would > anyone want to see only the left half of a document? > If the right half is unnecessary, why show the > document at all? Microsoft's tiling system doesn't > have this problem, but it isn't intuitive enough. The reason for overlapping windows is that few of us can afford 18" by 18" screens. Windows are a graphic analogy to multitasking, even though, of the machines being discussed, only the Amiga is multitasked. A window that is largely obscured may not show you its results, but it does remind you that it is there and only a mouse click away from being the focus of your attention (and the computer's). The problem with tiling is that almost no matter how large your screen is, some of the tiles will be too small for the information they display. I prefer overlap because I can get each window to be the right size and then shift between windows as needed. Even on a Sun 3 I find myself overlapping windows because the smallest type size that doesn't give me eyestrain takes over half the width of the screen in an 80 column window. > - Do we need to move windows arbitrarily like pieces > of paper? What difference does it make whether a > window is a few pixels to the left or right? I think we do but primarily for the rather intangible reason that we should control the computer, rather than it controlling us. > - At the same time, current window systems don't really > use the potential of these machines. These computers can > simulate arbitrary universes; we confine them to a mildly > mutated desktop. I guess I am attacking the desktop > metaphor; just because it's familiar doesn't mean it's good. > The desktop metaphor is a product of computers being oriented toward those tasks we perform in our offices or at a desk. For me that is an excellent metaphor. I can conceive of other models, but I am not convinced that any of them are more appropriate for most people. What do you propose as an alternative? If I had an alternative to think about I might be more interested. >I think a good user interface ought to concentrate the available power >on productive, often used functions (like a RISC chip :-)). One >shouldn't spend programmer time and computer time adding bells and >whistles that let the user do useless things. This is, in general, a good point. I, for instance have yet to find a reason to use the small icon display in the Mac Finder. However, in matters of user interfaces it is difficult to make a good pick of what is useful. Is a feature that is considered essential to .1% of the users useful? What about a feature that everybody uses once a year because it is a little more convenient? These are hard calls. > > ....... > >Adam While I obviously don't agree with you all that much, you have asked interesting questions. Thanks for the excuse to ramble on about some of my favorite ideas. Ethan Munson CS Grad Student UC Berkeley
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-
holloway@drivax.UUCP (Bruce Holloway) (05/14/87)
In article <1976@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes: >menu is used. Otherwise, the menu bar contains the menu for whichever >window is active. I believe this is the design used in Servant, and >possibly the design used in Juggler (although I wouldn't know). Clearly >this is necessary in a multitasking windowing scheme; for a single-tasking >machine, it is of much less importance. Microsoft Windows, which is multi-tasking and all the rest, as the menu bar INSIDE the window. And I believe the DEC MicroVax graphics interface is the same way. - Bruce -- Bruce Holloway - Relapsed Newsaholic {seismo,hplabs,sun,ihnp4}!amdahl!drivax!holloway Put the power of RANDOM NUMBERS to work FOR YOU!
page@ulowell.cs.ulowell.edu (Bob Page) (05/14/87)
munson@ernie.Berkeley.EDU.UUCP (Ethan Munson) wrote:
^^^^^^^^
>I think you're missing the point. For most of the tasks that PCs are
>used for, a 68000 clocked at 8MHz with a text/command-line OS (like
>MS/DOS would be) is a ridiculous waste of compute power.
Whoa! You must be stuck in Macintosh/GEM mode. Some of us use our
68Ks at 8MHz with a multitasking OS, sir.
Having a command-line interface puts a much LOWER burden on the other
tasks currently running on the system.
..Bob (typing on an Amiga)
--
Bob Page, U of Lowell CS Dept. page@ulowell.{uucp,edu,csnet} 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
socha@drivax.UUCP (Henri J. Socha (x6251)) (05/15/87)
In article <18881@ucbvax.BERKELEY.EDU> munson@ernie.Berkeley.EDU.UUCP (Ethan Munson) writes: >In article <565@bloom-beacon.MIT.EDU> chekmate@artemis.UUCP (Adam Kao) writes: >>I've been thinking for a long time about the ideal user interface on a >>graphics-intensive computer. The window and icon system popularized >>on the Mac seems to me a step in the right direction, but I still have >>reservations. Some of my major concerns: [Much deleted from the original article and the reply. I am only addressing two minor points.] >You would never consider using a real window interface on a basic >IBM PC because the chip/architecture just doesn't have the stuff to >support it (MS Windows, nowithstanding). You shouldn't worry about the >inefficiency of supporting a fancy graphic interface because these >machines are not intended for computationally intensive tasks. This, I greatly disagree with. GEM from DRI is a very fast environment. I am talking about GEM (and GEM applications such as GEM Draw Plus) on an XT. I feel that a person could use GEM Draw as they use MacDraw. Though in some respects it may not be as smooth to use as a Mac, it is as fast (or close enough) for it not to be an issue. To (ab:-)use one of many similar quotes: "GEM has a tremendous advantage in terms of speed," said John Meyers president of Ventura Software, "but Windows is important for the future." Therefore the issue becomes one of market presence and not hardware/software capability. As another (personal) example, at one point in time (before its release) the FASTest version of Multiplan existed on the slowest machine in the Datapoint family (the 1800/3800) which was slower than a PC/XT. BUT, a very fast Multiplan interpreter was written at Datapoint (faster than the one at Microsoft) and the Datapoint Multiplan was FAST. Once this was realized by MS, the problem was looked into. > I, for instance have yet to find a >reason to use the small icon display in the Mac Finder. I find "Small Icon" display extremely usefull. With a 20 Meg hard disk and many first level folders, I use small icons to display the root directory (if you will). I organize the top half of the disk window by non-modified subject area folders such as: System Folder, Utilities, Applications, Games, etc. The lower half contains my work folders: Projects, Letters, etc. Had I used large icons either more levels of folders would be necessary or windows would have to be scrolled all the time to see what was in them. And, in a command line system I am continuously executing DIR (or ls) to see what is there. Small Icons on a windowing system is the perfect solution to my needs. >>Adam >Ethan Munson **** WARNING: Commercials follow *** In case you didn't notice it, I must admit that I work for Digital Research, the originator of GEM (and the products to be mentioned below.) If feel that the points raised above (especially about the speed of GEM) are accurate. Having used (owning) a Macintosh Plus and having used GEM Draw Plus on a PC/XT I find that the difference in speed between these two machines is not an issue. In both cases you spend much of your time thinging what to do (how to make the drawing) relative to the time spent on how to do it. But, the drawing speeds are still comparable. (OK, its faster on the Mac but not enough to make it a major issue.) ** By the way, go to your local computer store and see GEM applications running ** on the PS/2 Model 50. <<<IT SCREAMS!>>> Now, while I have your attention and while we are talking about preceived vs actual capabilities. Many industry #$@!s have stated that you can't do multitasking on a PC (or AT for that matter). But, DRI has had it available for years. Concurrent DOS XM (Expanded Memory) will run 4 applications on one PC at the same time. And two more to remote terminals! These can be windowed onto one screen or screen switched. These can be true PC-DOS applications or CP/M ones. Basically, only the problem of MS-DOS programmes writing directly to hardware (bypassing the bios) are an issue. For these, instead of running multi-tasked, they are suspended (like the Mac's Switcher). (Yes, TSRs like Sidekick don't work but just use another window!) AND, Concurrent DOS 386 should be released soon (if not already). FlexOS (Flexible Operating System) is a full real-time, multi-user, multi-tasking OS. Again, it does what Industry Figureheads said can not be done. For example, I have seen 3 copies of Lotus 1-2-3 and a graphics programme all running at the same time to the same screen on an Intel 286. They share machine cycles (execute in background) and by simple key sequences any one of the three screens can be brought up. Note that these screens are not redrawn. They have been generated once by the application even when it is in background and are only selected as needed. NOTE: this is not a special version of 1-2-3. It's the same one you bought but running through the DOS Front End of FlexOS 286. ******** Please excuse the ad. But the sad thing is that very few know about the capabilities of these DRI products. Just as they do not know about the Datapoint Personal Computers (never called that). The Datapoint 2200 was sold about one year before the Intel 8008 (Yes, 8 0 0 8) was even available. Machines, Business languages, Local Area Networks, second generation Operating Systems have been all done by Datapoint on a PC about five years before the PC marketplace did it. Ah well, such is life. -- UUCP:...!amdahl!drivax!socha WAT Iron'75 "Everything should be made as simple as possible but not simpler." A. Einstein
socha@drivax.UUCP (Henri J. Socha (x6251)) (05/15/87)
In Message-ID: <1568@drivax.UUCP> I wrote (and others here have commented on): > This, I greatly disagree with. GEM from DRI is a very fast environment. > **** WARNING: Commercials follow *** >In case you didn't notice it, I must admit that I work for Digital Research, >the originator of GEM (and the products to be mentioned below.) >** see GEM applications running on the PS/2 Model 50. <<<IT SCREAMS!>>> >Now, while I have your attention and while we are talking about >preceived vs actual capabilities. >Many industry #$@!s have stated that you can't do multitasking on a PC ... >Concurrent DOS XM (Expanded Memory) will run 4 applications ... >FlexOS (Flexible Operating System) is a full real-time, multi-user, ... [And lots of other stuff about DRI and Datapoint I will not mention again.] WELL, there was commercialism in that article but it is saddly there on purpose. The commercial was a too obvious sidelight. I was raising a point. The commercialism existed as the only means I could think of to make it obvious. The point was a strong reply to the statement that you can't do graphics on a PC. And by that the original author seemed to mean Windows (and only Windows). I had to use the examples and the directness of it to get across that the issue is very often a preceived view of machine capabilities as defined by known products. Sometimes excellent products are unknown to the marketplace. I have no doubt that most people reading the net have not seen GEM run. I have no doubt that there are better products than GEM existing somewhere. I have no doubt that there are better operating systems than FlexOS, XM, etc. I also have no doubt that these better products are also generally unknown. So, again I state: SORRY for the commercialism. But, I felt I had to do it in replying to points made by others that PC-DOS 3.x is it for a PC and you can't get a reasonable Windowing environment because the machine just is not powerfull enough. There is software that CAN and DOES make it powerfull enough. Its just we (in general) don't know about it. --------------- "And we thank you again for your patronage" -------------- -- UUCP:...!amdahl!drivax!socha WAT Iron'75 "Everything should be made as simple as possible but not simpler." A. Einstein
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (05/15/87)
[!!!] > > 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 a feature of the Amiga "Workbench". You select as many files as you wish to act on and then double-click the tool. You just described a feature of the Macintosh "Finder". In certain situations you may selct several files then chose "print" or such from a finder menu. -------- "There's no thief like a bad book" -Italian Proverb
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/15/87)
> This, I greatly disagree with. GEM from DRI is a very fast environment. > I am talking about GEM (and GEM applications such as GEM Draw Plus) on an XT. > I feel that a person could use GEM Draw as they use MacDraw. > Though in some respects it may not be as smooth to use as a Mac, > it is as fast (or close enough) for it not to be an issue. >... etc.. First, I would like to note that Henri Socha posted this message to four newsgroups .. amiga, atari, mac, and ibm, and thus his comments are quite general and not aimed specifically at a single computer. Secondly, remember that if you reply normally, you will be cross posting to these other groups as well (talk about net overload!). This reply of mine is only going to comp.sys.amiga . So just between us, and not repeating his entire article, I would generally agree that GEM/microsoft windows are extremely fast relative to the theoretical maximum achievable on an IBM (insert favorite model here). About the fastest I've seen microsoft windows go (admittedly a brief encounter) is about 10-15% slower than a Mac's windowing system, and no where near as pretty. And as far as comparing it to Intuition, the Amiga wins hands down. (Note that I didn't say 'workbench' here.. I'm talking about bringing up and using 3 screens with maybe 15 windows between them). The second half of the article deals with the great advances in multitasking for the PC. We Amigans might yawn... "oh... finally", and "(shug) so what?" and go back the original "if it wasn't meant to multitask originally, then making it multitask now isn't much of a gain" argument which is based upon the fact that most programs written for single-tasking machines tend to use busy loops for almost all waiting. The Amiga wins hands down here also since it was built with a multitasking core. Notice that the other two major micro's on the market: the Mac and the IBM (any model IBM PC) are *finally* heading towards multitasking, but attempting to implement it using the same old OS architecture as previous single-tasking machines. The only reason this can be done is due to the advent of MMU's (or something similar) in the new machines. Apple's OS is so messy that they've basically scrapped trying to make it multitask, and are porting UNIX over instead. Thank you, I'll take EXEC's shared libraries any day. Now I ask you, how efficient do you think IBM is going to be able to make their new multitasking OS??? Never mind the fact that they still use CR-LF as the line terminator, and have two file modes (text/binary)! Final Note: In previous years, most micro OS's have actually been non-OS's. The Amiga's OS is the first *real* OS for micro's that I've seen. Why? What makes the Amiga different? How many programs written for the Amiga use hardwired "global" memory locations?? Didn't think so. Now look at the Mac: Hardwired locations and address ranges everywhere. Look at the Atari: Same thing! Look at the IBM: IBM?? Ahhhh yes, the IBM. Well, they had the right idea, but IBM's BIOS routines are so incredibly slow that almost nobody uses them when they want speed. So you wind up using hardwired locations after all. About the most 'hardwired' I've ever gone on the Amiga is to manipulate the bitmaps for custom screens directly, and that hardly counts since you go through Intuition to get the addresses (plus the fact that the addresses are definately *not* hardwired). If the unlikely occurs and the Amiga doesn't survive, it's OS and OS concepts certainly will. -Matt
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (05/15/87)
In article <1568@drivax.UUCP> socha@drivax.UUCP (Henri J. Socha (x6251))
writes a lot of advertising. I can't resist the urge to throw some
reality on it:
<Many industry #$@!s have stated that you can't do multitasking on a PC
<(or AT for that matter). But, DRI has had it available for years.
Ever since they did MP/M. I hope the current incarnation is better
than that one, where running everyones favorite menuing hack (which
nearly every large business package for CP/M used) could leave people
who hadn't invoked it in the menu.
I also hope that a few years of _not_ being a dominant force in the
micro market has convinced the DRI tech support to actually care. I
gave up on them years ago, and so can't say for sure.
<The Datapoint 2200 was sold about one year before the Intel 8008 (Yes, 8 0 0 8)
<was even available. Machines, Business languages, Local Area Networks,
<second generation Operating Systems have been all done by Datapoint on a PC
<about five years before the PC marketplace did it.
Yes, DP did all that. On the flip side, if the PC market had the
capabilities that DP was peddling, it usually cost less than 1/5th of
what DP wanted for it. I.e., it was sold into the minicomputer market.
And if you went with the PCs, you got a reasonable architechture like
an eight-eightysux instead of the oddball stuff that DP was selling
(I'm _serious_; the DP architechture I looked at made an 8086 look
reasonable!)
<mike
--
Take a magic carpet to the olden days Mike Meyer
To a mythical land where everybody lays ucbvax!mwm
Around in the clouds in a happy daze mwm@berkeley.edu
In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNETdyer@atari.UUCP (05/15/87)
in article <1568@drivax.UUCP>, socha@drivax.UUCP (Henri J. Socha (x6251)) says: ^^^^^^ 'nuff said. > > This, I greatly disagree with. GEM from DRI is a very fast environment. > I am talking about GEM (and GEM applications such as GEM Draw Plus) on an XT. If GEM is a "very fast" enviroment, then ... then ... (giggle) I'm at a loss for words. 'nuff said! -- -Landon Dyer, Atari Corporation {sun,amdcad,lll-lcc,imagen}!atari!dyer The views expressed here do not necessarily reflect those SEGMENTS of Atari or the AI software that has taken over my brain. ARE FOR Yow! I am waiting for my warranty-expired interrupt! WORMS
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)
tim@ism780c.UUCP (05/16/87)
When talking about window systems in comp.sys.{mac & amiga & atari}, if
you give an example of how something works on your system, please
mention which system you are talking about. Otherwise, it gets very
confusing very quickly for those of us who only use one member of
the set {mac,amiga,atari}.
--
Tim Smith "Learn to juggle while it's still legal"
sdcrdcf!ism780c!timtim@ism780c.UUCP (05/16/87)
In an article munson@ernie.Berkeley.EDU.UUCP (Ethan Munson) writes:
< This is, in general, a good point. I, for instance have yet to find a
< reason to use the small icon display in the Mac Finder.
If you set the window to "View by name", select all the files, move
them to the desktop, then set the window to "View by small icon",
and choose "Put away" from the File menu, you will then have what
looks like a unix "ls -C" ( or just "ls" for Berkeley folks ) listing,
except for the little icons.
This gets a larger number of files displayed per area than any other
view method on the Mac. It can be very handy when one has a folder
with a lot of stuff in it ( e.g., all the .h files for a C compiler ).
--
Tim Smith "Learn to juggle while it's still legal"
sdcrdcf!ism780c!timdew@esl.UUCP (05/16/87)
In article <8705150704.AA05423@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) 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. >> > >You just described a feature of the Amiga "Workbench". You select as many >files as you wish to act on and then double-click the tool. > >You just described a feature of the Macintosh "Finder". In certain >situations you may selct several files then chose "print" or such from a >finder menu. > Actually, you can copy multiple files on the ST as well by selecting them and dragging them. But, the point in a command such as cat is that the order of the files is important. Selection of several files and printing has no inherent order required. On the Mac, printing several files only work if they happen to be from the same application. I don't use a shell on my Atari, but I use UNIX at work. I am both used to windows and shells. I don't think that the GEM desktop replaces a shell; there are things that I can not do with just a mouse. I think that that is just inherent in the way mice are implemented on these machines. <------Pnews defeater------> <<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>> ,<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>> <<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>
hah@isum.intel.com (Hans Hansen) (05/16/87)
Will you people who are following up on this topic please edit the Newsgroups line and quit cross posting to a lot of very disinterested users! Stop USENET NOISE! Edit this line: "Newsgroups: comp.sys.amiga,comp.sys.mac,comp.sys.atari.st" Hans
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)
dgold@apple.UUCP (05/17/87)
In article <6329@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >If you set the window to "View by name", select all the files, move >them to the desktop, then set the window to "View by small icon", >and choose "Put away" from the File menu, you will then have what >looks like a unix "ls -C" ( or just "ls" for Berkeley folks ) listing, >except for the little icons. There's an even easier way to do this. Set the window to "View by Small Icon" first. Then set it to "View by Name" (or whatever). Select All, and drag all the files to the gray outline of the window you are dragging them from, and drop them in. Then set the window back to "View by Small Icon." (The first set to "View by Small Icon" is necessary because the Finder remembers and uses the last iconic view to set the coordinates of files dropped in a folder, even if that folder is not currently being shown in an iconic view). -- David Goldsmith Apple Computer, Inc. MacApp Group AppleLink: GOLDSMITH1 UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold CSNET: dgold@apple.CSNET, dgold%apple@CSNET-RELAY BIX: dgoldsmith
gjditchfield@rose.UUCP (05/17/87)
pete@gpu.utcs.UUCP (Peter Santangeli) writes: > Wouldn't it make more sence to allow WINDOWS to have there own menu systems? I have an ad for the TML Source Code Library that shows a (Lisa?) window with a menu bar that runs across the top of the window, underneath the window's title bar. The window definition code is part of the library. -- Glen Ditchfield {watmath,utzoo,ihnp4}!watrose!gjditchfield Dept of Computer Science, U of Waterloo (519) 885-1211 x6658 Waterloo, Ontario, Canada Office: MC 2006 If you grab the bull by the horns, you at least confuse him -- R.A.Heinlein
jimomura@lsuc.UUCP (05/17/87)
In article <689@omepd> hah@isum.UUCP (Hans Hansen) writes: >Will you people who are following up on this topic please edit the >Newsgroups line and quit cross posting to a lot of very disinterested >users! Sorry Hans. I have to disagree with you. It's clear that this is a topic of discussion which crosses the boundaries. Not everyone receives all the newsgroups so those in whatever newsgroup might be used to contain this discussion would not be available to everybody. The Net currently doesn't have a 'windows.general' group, and even if it did, this discussion has the earmarks of a short term discussion wherein a few standards might be hacked out, but nothing longterm. Why not use the 'n' option in your reader? -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
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)
olson@endor.harvard.edu (Eric Olson) (05/18/87)
In article <6329@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >If you set the window to "View by name", select all the files, move >them to the desktop, then set the window to "View by small icon", >and choose "Put away" from the File menu, you will then have what >looks like a unix "ls -C" ( or just "ls" for Berkeley folks ) listing, >except for the little icons. > >This gets a larger number of files displayed per area than any other >view method on the Mac. It can be very handy when one has a folder >with a lot of stuff in it ( e.g., all the .h files for a C compiler ). Another option for a higher-density file display is to modify the LAYO resource in the Finder. ResEdit already has a TMPL for this, so you need only use a reasonably current ResEdit on a reasonably current Finder, open up the LAYO resource in the Finder, and modify the line spacing for the text view. You can also modify the tab stops, the font, the default (i.e., new folder) window size, the Icon view spacings, etc. -Eric olson@endor.harvard.edu harvard!olson
cjp@vax135.UUCP (Charles Poirier) (05/18/87)
In article <1800@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: >In article <689@omepd> hah@isum.UUCP (Hans Hansen) writes: >>Will you people who are following up on this topic please edit the >>Newsgroups line and quit cross posting to a lot of very disinterested >>users! >The Net currently doesn't have a 'windows.general' group, and even But it does! Our News spool shows a (rather empty) "comp.windows.misc" group. >if it did, this discussion has the earmarks of a short term discussion >wherein a few standards might be hacked out, but nothing longterm. As I understand Nettiquette, if an appropriate group *already* exists, it should be used regardless of the scale of the discussion. I am redirecting followups to comp.windows.misc. -- Charles Poirier (decvax,ucbvax,ihnp4,attmail)!vax135!cjp "The road to Hell is paved with good opinions."
tecot@apple.UUCP (Ed Tecot) (05/18/87)
In article <1987May12.233757.24441@gpu.utcs.toronto.edu> pete@gpu.utcs.UUCP (Peter Santangeli) writes: > > > Hi Yall, > > On the subject of Window recursion, the one part of most windowing systems >I find counter -intuitive is the difference between the desktop and a window. > 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. The advantage of having all the menus in one place is that the user knows what all of his options are. > Now if someone could come up with a graphic rendition of Pipes and >I/O routing, we'd be laughing... You obviously have never seen a Silicon Graphics IRIS with visual pipes. _emt
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
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (05/19/87)
In article <1800@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: <In article <689@omepd> hah@isum.UUCP (Hans Hansen) writes: <>Will you people who are following up on this topic please edit the <>Newsgroups line and quit cross posting to a lot of very disinterested <>users! < < Sorry Hans. I have to disagree with you. It's clear that this <is a topic of discussion which crosses the boundaries. Not everyone <receives all the newsgroups so those in whatever newsgroup might <be used to contain this discussion would not be available to everybody. <The Net currently doesn't have a 'windows.general' group, and even <if it did, this discussion has the earmarks of a short term discussion <wherein a few standards might be hacked out, but nothing longterm. Sorry, but the net does (at least around here) have a windows.general group, except it's called comp.windows.misc (as opposed to comp.windows.x, comp.windows.news, or whatever). This looks like the perfect discussion to put into it. I've pointed the followups to this there, but they probably don't belong. <mike -- Take a magic carpet to the olden days Mike Meyer To a mythical land where everybody lays ucbvax!mwm Around in the clouds in a happy daze mwm@berkeley.edu In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNET
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.)
alexande@drivax.UUCP (Mark Alexander) (05/21/87)
In article <732@atari.UUCP> dyer@atari.UUCP (Landon Dyer) writes: >If GEM is a "very fast" enviroment, then ... then ... (giggle) >I'm at a loss for words. 'nuff said! I believe the original article was comparing GEM to MS-Windows. By that standard maybe GEM is fast. Compared to text-only systems it's darned slow. Your posting just flames GEM without saying what you're comparing it with. I'm not sure that it's possible to make a fast graphics enviroment for machines like an 8088 PC or the original Atari ST. I could be wrong here, but it seems like hardware help is really required (blitters, faster CPUs, graphics coprocessors -- gosh, that sounds like an Amiga!). If GEM is so lousy, why is Atari selling it with their upcoming PC clone? Why not go with MS-Windows, which is rapidly becoming the industry standard for PCs? Or better yet, write your own Windows and make it small AND fast AND robust AND powerful. That shouldn't be too hard :-) seeing as how crummy the existing products are. Disclaimer: I don't use GEM. It's too slow. -- Mark Alexander ...{hplabs,seismo,sun,ihnp4}!amdahl!drivax!alexande "Bob-ism: the Faith that changes to meet YOUR needs." -- Bob
tim@ism780c.UUCP (Tim Smith) (05/23/87)
In article <8705150704.AA05423@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >You just described a feature of the Macintosh "Finder". In certain >situations you may selct several files then chose "print" or such from a >finder menu. You can also double-click on an application. If it is one that can handle multiple files, it will usually open all of them. If it can only deal with one file, it will open one of them. Some applications, however, will do nasty things. I had a situation once where I had several font files and several text files in a window, along with the font/da mover. I selected all the files in the window, and opened the font/da mover, figuring it would ignore the text files. Well, it didn't ignore them. It silently trashed them! If I ever meet the author of font/da mover in a dark alley... -- Tim Smith "Learn to juggle while it's still legal" sdcrdcf!ism780c!tim
tim@ism780c.UUCP (Tim Smith) (05/23/87)
In article <689@omepd> hah@isum.UUCP (Hans Hansen) writes:
<Will you people who are following up on this topic please edit the
<Newsgroups line and quit cross posting to a lot of very disinterested
<users!
What do you want us to change it to? Your article is posted to all
three groups, with no hint as to which one you wish this discussion
was out of.
--
Tim Smith "Learn to juggle while it's still legal"
sdcrdcf!ism780c!tim