lyman@eos.UUCP (Lyman Taylor) (03/03/88)
In article <1719@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: .... ( deleted comments Byron Han made about multifinder ) >Still sounds awfully serial to me. What happens if you have two windows >at the top (i do this on a sun, usually two editting sessions) maybe >different editors side by side...? Your menu bar would be constantly >changing as you go back and forth (cutting and pasting)... (all that >wasted mouse travel time and a wasted mouse click ) >I think context-sensitive menus make more sense (try SunView applications >and see how well they work) :-) (Seriously, I think a menu bar starts >making less sense in a multitasking environment were more than one >application is running at a time in a number of different windows ) Multitasking saves the World! Come on, the only person I know of the can actually use two applications at once is Mr. Spock of Star Trek due to the unique features of his Vulcan mind ( i.e. he is not a human being ). Unfortunately, us humans can only handle ONE high level cognitive task at once. Therefore, we only need ONE menu at a time. Anything above that is a nice HACK, but not all that useful for us mortals. Needless to say, it ignores most of what about Human Computer Interaction. [ Like people operate best in a CONSISTANT environment which is why the Mac is so easy to learn and use. And UNIX is well UNIX ( a terrific puzzle, but not as great a tool as it could be. And why NeWS and X applications are often thought of as HACKS by people who did not 1) create, 2) pay for, or 3) forcibly made to use the application in the first place. ] Think about it. When have you ever seen anyone, including yourself, doing two things at once ( like running a spredsheet and SIMULTANEOUSLY writing something into your favorite editor ). I give you a hint most computers I seen have ONE keyboard per user. This applies to general human behavior also. For example, people can only handle one conversation at a time. Some people can easily and rapidly " task switch " from conversation to conversation ( doing something remarkably similiar to a multitasking operating system ) but they cannot do it in parallel. This is not to say multitasking is not useful. Multitasking and timesharing used to mean just about the same thing. Then came the single user system. It is useful on a single user system to run a BACKGROUND task(s) that needs NO iteraction with the user, like laser printing a 50 page document. The important point is that menus and the mouse and all that WIMPy stuff are for INTERACTION with the human. WIMPy stuff is used by the human to directly controlthe program unlike the MS/DOS and UNIX environments with their prompts, with which the program ask YOU the questions. The psychological types call this User Directed Software. Humans do not need to control background tasks that is why they are background tasks. If programs need to talk to other programs THEY don't need the menu for hopefully they know what each are talking about :-). As for your example of having two editors going at once. 1) If this was two copies the SAME editor open on two different files then I would same that this is a malfunction of the EDITOR. Take a look at most Mac word processors; they have the capability of having multiple windows open at once. Even emacs has multiple buffers ( it user interface leaves something to be desired though ) 2) If you actually needed two DIFFERENT editors you hopefully were looking at two DIFFERENT types of files. In this case you are context switching between two different types of data who hopefully have completely different menus. ( execpt for the APPLE, FILE, and EDIT menus, there goes that CONSISANTCY again, Mac Write and Mac Paint have for the most part different menus and operation ( those probably aren't the best examples but you get the idea :-). To sum it all up multitasking means that can have more that one task runnig at the same time ( more than one doing work FOR you ), but you can only work WITH one application at a time. So it looks SERIAL because people THINK serial. We can only do low level tasks like see, hear, taste, and smell in parallel; I guess that's what separates the humans from the computers who think SERIALLY just like we do, only they're better at faking it. P.S. Apple I hope you keep this in mind while you are rewriting the MAC OS. We need enhanced MultiF not UNIX. We already got UNIX. :-) P.P.S. And yes the Mac interface isn't THE absolute best interface, but at least its tries. Lyman S. Taylor lyman@ames-aurora.arpa NASA Ames Research Center or more verbose ...{uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!lyman
klee@daisy.UUCP (Ken Lee) (03/04/88)
In article <241@eos.UUCP> lyman@eos.UUCP (Lyman Taylor) writes: > > Multitasking saves the World! Come on, the only person I know of >the can actually use two applications at once is Mr. Spock of Star Trek due to >the unique features of his Vulcan mind ( i.e. he is not a human being ). > > Unfortunately, us humans can only handle ONE high level cognitive task >at once. Therefore, we only need ONE menu at a time. Anything above that is >a nice HACK, but not all that useful for us mortals. Needless to say, it >ignores most of what about Human Computer Interaction. > I think you're missing something here. Some (many?) cognitive tasks require support from more than 1 application program. For example, I regularly debug programs with 3 windows open: an editor, a debugger, and the running program. Even if you had 1 application supporting these 3 things, you'd still need 3 sub-windows to display them all. Many advanced user interfaces are similar. There's often one spatial display window (e.g., a map or image or a spreadsheet), one abstract display window (e.g., some statistical analysis graphs, etc.), and one control panel window. That's 3 windows even for a narrow (but sophisticated) application. I'd hate to see someone fly a plane (or even drive a car) if he could look out the window or look at his guages, but not both at the same time. Ken
mwm@eris (Mike (My watch has windows) Meyer) (03/04/88)
In article <241@eos.UUCP> lyman@eos.UUCP (Lyman Taylor) writes:
< Multitasking saves the World! Come on, the only person I know of
<
< Unfortunately, us humans can only handle ONE high level cognitive task
<at once.
<For
<example, people can only handle one conversation at a time. Some people can
<easily and rapidly " task switch " from conversation to conversation ( doing
<something remarkably similiar to a multitasking operating system ) but they
<cannot do it in parallel.
Uh, could you make up your mind? Switching between one task and
another _defines_ multitasking. So your friends who can switch
conversations _can_ multitask. Doing it in a windowed computing
environment is even easier. Even as I type, I'm watching the output
from a compile, checking for error messages. The other tasks I'm
running now are either display updates (clock), or daemons that do
things for me when certain conditions are met. Am I "using" those
applications? I think so - it's just that they cause to happen
subconsciously things that I'd otherwise have to consciously do.
<Therefore, we only need ONE menu at a time. Anything above that is
<a nice HACK, but not all that useful for us mortals. Needless to say, it
<ignores most of what about Human Computer Interaction.
This is different from the statement that you can only do one thing at
a time. Obviously, you can only use as many menus as there are
pointing devices on the system. Give me two mice on some workstations,
and I can probably use two menus simultaneously.
One the other hand, the "one" menu means it's probably tied down to a
specific place, so you have to go there to use the menu. This makes it
_hard_ to let muscle memory make menu selections for you. That's an
important thing to miss.
<mike
--
[Our regularly scheduled .signature preempted.] Mike Meyer
The Amiga 1000: Let's build _the_ hackers machine. mwm@berkeley.edu
The Amiga 500: Let's build one as cheaply as possible! ucbvax!mwm
The Amiga 2000: Let's build one inside an IBM PC! mwm@ucbjade.BITNETstpeters@dawn.steinmetz (Dick St.Peters) (03/04/88)
In article <241@eos.UUCP> lyman@eos.UUCP (Lyman Taylor) writes: > Think about it. When have you ever seen anyone, including yourself, >doing two things at once ( like running a spredsheet and SIMULTANEOUSLY writing >something into your favorite editor ). I give you a hint most computers I seen >have ONE keyboard per user. This applies to general human behavior also. For >example, people can only handle one conversation at a time. Some people can >easily and rapidly " task switch " from conversation to conversation ( doing >something remarkably similiar to a multitasking operating system ) but they >cannot do it in parallel. I *routinely* do things in parallel in different windows. At its most extreme, this means using several windows on my Sun to watch debugging output from rlogin sessions running communicating network peers on other hosts. Without these windows, I'd have to debug my distributed application off-line, losing the time-relationship between events. I also frequently fixing source-code errors while the compiler in another window is spitting out its error messages. These are extreme examples, but I'm virtually always doing things that I consider multi-tasking, meaning things that I could not do without a multi-tasking system - and a simultaneous-display window system. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
dlw@hpsmtc1.HP.COM (David Williams) (03/05/88)
Hmmm, Sounds like we have some people who have not used the Macintosh running Multifinder! On my tables I have a Mac II and an HP 319 discless workstation running X Windows. Right now I am entering this message via one of two windows I currently have open under the application NCSA telnet. I also have Hypercard up running Focal Point, and underneath that I have the finder. Currently, NCSA has the menu bar and this window is the active one. If I click on the Hypercard window it becomes active and context switches the menu bar. If I click on a Finder window then it becomes active. Meanwhile stuffit is unstuffing some files in the background along with the globe application (which is displaying a color spinning globe in its own window). If I move to the 319 running X...lets see the active window is the one that the cursor is in! So I guess the difference is that I didn't have to click on a window to make it the active one (wow some difference). I don't know how NeWS does its context switching, but it must have to have some way of knowing which window I want to interact with. So I do not have to go up to the menu bar to context switch which window is the active one unless I want to. There is also an fkey available which turns the menu bar into a pop up menu anywhere on the screen, so I guess I have that capability as well (if I choose to do so). So far I like this layering approach that apple has taken. And yes it will be nice when IPC and true multitasking arrives, but for now I am very happy with the powerful consistent graphical interface that Apple has provided me with. I am happy to see this discussion on Window systems/User Interface happening. It is about time that Unix came out of the dark ages and attempted to create an interface so that non-computer scientists would WANT to use it. I would much prefer to use Unix with a decent interface than MS-OS/2. Now if only we could hear some comments from the Xerox Parc folks.
dsc@izimbra.CSS.GOV (manic pop thrill) (03/05/88)
In article <9786@steinmetz.steinmetz.UUCP> dawn!stpeters@steinmetz.UUCP (Dick St.Peters) writes: >In article <241@eos.UUCP> lyman@eos.UUCP (Lyman Taylor) writes: >> Think about it. When have you ever seen anyone, including yourself, >>doing two things at once ( like running a spredsheet and SIMULTANEOUSLY writing >>something into your favorite editor ). I give you a hint most computers I seen > >I *routinely* do things in parallel in different windows. At its most >extreme, this means using several windows on my Sun to watch debugging >output from rlogin sessions running communicating network peers on i cannot speak for the original poster, but what i think he was trying to say was that at any one time you (the human) would not be typing into two editors at once, or would not be filling in two dialog boxes at once, or would not be typing a spreadsheet command at exactly the same time you are typing text into an editor. you can be running a number of programs simultaneously, but at any one time you are interacting (using the mouse, keyboard, lightpen, etc) with at most one. although there may be other windows on the screen where computation is going on, or data is being printed, there is only one window that the user is interacting with directly. dsc dsc `true love is the devil's wishbone'
hill@nicmad.UUCP (Ray Hill) (03/05/88)
In article <241@eos.UUCP> lyman@eos.UUCP (Lyman Taylor) writes: > Multitasking saves the World! Come on, the only person I know of >the can actually use two applications at once is Mr. Spock of Star Trek due to >the unique features of his Vulcan mind ( i.e. he is not a human being ). Then I guess I must have pointed ears. Having multiple applications on the screen at one time is my prefered mode of operation. Using multiple Xterms with the X Window system, I have multiple "vi" editing windows of the code I am currently working on. I also keep one window one for the compile/link of my application. This way I can edit a file while keeping an eye on the compile window for errors. I also like to open a "rn" window while compiling. This way I only read articles while waiting for the compile to finish. If at any second the compile finishes or bombs I see the exact error on my screen. > Unfortunately, us humans can only handle ONE high level cognitive task >at once. See the above note. > Think about it. When have you ever seen anyone, including yourself, >doing two things at once ( like running a spredsheet and SIMULTANEOUSLY writing >something into your favorite editor ). I give you a hint most computers I seen >have ONE keyboard per user. Again see the above note. Also even though only one keyboard is attached to a screen. That doesn't mean you can't do data entry into several windows. You see I am faster at changing code than the computer is at compiling. So I can actually get ahead. > To sum it all up multitasking means that can have more that one task >runnig at the same time ( more than one doing work FOR you ), but you can only >work WITH one application at a time. So it looks SERIAL because people THINK >serial. We can only do low level tasks like see, hear, taste, and smell in >parallel; I guess that's what separates the humans from the computers who think >SERIALLY just like we do, only they're better at faking it. To sum it up, there are times people can appear to work in parallel to the computer. Sure its still actually serial but I get better more throughout by making my computer think I can work in parallel. >P.P.S. And yes the Mac interface isn't THE absolute best interface, but at > least its tries. P.P.S. Any yes the UNIX shell command interface isn't THE absolute best, but at least it tries. > > >Lyman S. Taylor lyman@ames-aurora.arpa >NASA Ames Research Center or Ray Hill hill@nicmad
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/05/88)
In article <241@eos.UUCP#, lyman@eos.UUCP (Lyman Taylor) writes: # In article <1719@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: # # .... ( deleted comments Byron Han made about multifinder ) # # # >Still sounds awfully serial to me. What happens if you have two windows # >at the top (i do this on a sun, usually two editting sessions) maybe # >different editors side by side...? Your menu bar would be constantly # >changing as you go back and forth (cutting and pasting)... (all that # >wasted mouse travel time and a wasted mouse click ) # >I think context-sensitive menus make more sense (try SunView applications # >and see how well they work) :-) (Seriously, I think a menu bar starts # >making less sense in a multitasking environment were more than one # >application is running at a time in a number of different windows ) # # Multitasking saves the World! Come on, the only person I know of Some how you picked up on the multi-tasking aspect rather than the more important issue of the cumbersomeness (is-this-a-word?) of menu bar switching. # 2) If you actually needed two DIFFERENT editors you hopefully were # looking at two DIFFERENT types of files. In this case you are # context switching between two different types of data who # hopefully have completely different menus. ( execpt for # the APPLE, FILE, and EDIT menus, there goes that CONSISANTCY # again, Mac Write and Mac Paint have for the most part different # menus and operation ( those probably aren't the best examples # but you get the idea :-). Again you missed the *main* point, even if you do not have multitasking. The user interface you wind up with is one with constant mouse clicks and constant menu bar switches :( . Further, you will be constantly looking to see which application window is the active one (a further nuisance). Finally (if you do have multitasking) It gets worse (as I percieve it) on an abstract level...when two windows are on top (side by side) why should you choose one over the other in putting a menu bar up for that one? Can you really design a system which unnecessarily defines user activity in a serial manner and *predict* the type of applications you will see in the future. You wind up limiting your user interface today and for the future.
roger_warren_tang@cup.portal.com (03/05/88)
Instead of guessing, why not asky the cognitive people?
And they'll tell you that humans pay attention to only one thing at a time.
The example about gauges and flying is inaccurrate; a pilot glances outside,
then to the gauges and then outside again.clive@drutx.ATT.COM (Clive Steward) (03/06/88)
From article <884@daisy.UUCP>, by klee@daisy.UUCP (Ken Lee): >> > I think you're missing something here. ... > I'd hate to see someone fly a plane (or even drive a car) if he could look out > the window or look at his guages, but not both at the same time. I don't mean to pick on Ken, because he's not the only one. But think that some of the work$tation users who are in this discussion are missing very important information. You can see everything at the same time. Please try a Mac with Multifinder. I am using one now. It is nothing like working with Switcher, which is probably what you are thinking of. (Switcher was fine in its day, too). There is absolutely no difference between this and the 'generic workstation' model which has been around for 10+ years in various forms. You can have as many (overlapping, movable, sizeable, etc.) windows as you can find readable screen for; you can see events changing in all of them, at the same (sliced, just as with *nix etc.) time. It does cost less. The slicing is grainier, though usually not noticeably so. Only one window allows input at a time. I have never seen another system otherwise. The menu bar tracks the input-able window. This is easy to use. There are full facilities for pop-up menus anywhere on the screen, and adjuncts such as heirarchical menus; have been for years now. Many programs use them, including the MFMenus init which I am using now, which makes the most used parts of the finder interface (layer selection, DA's) to a pop-up w/hierarchy menu anywhere on the screen, in any program. It works very well, and I think you would like it, if you tried it. Clive Steward
sho@tybalt.caltech.edu (Sho Kuwamoto) (03/07/88)
In article <1735@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >Finally (if you do have multitasking) It gets worse (as I percieve it) on >an abstract level...when two windows are on top (side by side) why should >you choose one over the other in putting a menu bar up for that one? Can >you really design a system which unnecessarily defines user activity in a >serial manner and *predict* the type of applications you will see in the >future. >You wind up limiting your user interface today and for the future. Enlighten me. If you have two windows side by side on a Sun, what happens when you type something from the keyboard? Why should you choose one over the other in sending characters to it for that one? Can you really design a system which unnecessarily defines user activity in a serial manner and *predict* the type of applications you will see in the future. You wind up limiting your user interface today and for the future. :-) In either case, it seems that certain events can only be posted to the active window (whether or not it is topmost) and you are always going to have this type of problem. In response to someone who said the Amiga system was slightly better because it has a seperate button for the mouse, Get REAL! The Amigas menu bar switches depending on the active windows, it's just that you can't see it until you hit the right button. What happens with context-sensitive popup menus when the program has no windows open? Say you're running a memory based word processor and you have two enormous files to edit. You edit the first one, close it, and edit the second one. Where do you click to get your popup menus when there are no open windows? Another thing that scares me. Customizable mice seem fine for a multi user environment; if I get an account on a new Sun, I copy over my setup files or whatever and everything is hunky dory, right? But for a single user machine, I couldn't imagine what would happen if *my* mac functioned differently from the one my friend has, which functioned differently from the one the school has for public use. There are definite problems with the Mac interface, such as the grow box being in the right hand corner and all. However, these are all a side effect of the way it was designed. Ease of use was built in before Apple realized that power was important too. I think a three button mouse would confuse the, uh, counfuse the... stuffing out of beginners, especially if all three buttons were somehow necessary to do the most basic, necessary tasks. -Sho SonicYouthREMBeatlesKateBushReplacementsResidentsHuskerDuSeveredHeadsArtOfNoise ChrisAndCoseyJoyDivisionKillingJokeLaurieAndersonWireLouReedSkinnyPuppyBrianEno (sho@tybalt.caltech.edu, sho@caltech.bitnet, ...!cit-vax!tybalt!sho)
lad@eplrx7.UUCP (Lawrence A. Dziegielewski) (03/07/88)
From article <2460@nicmad.UUCP>, by hill@nicmad.UUCP (Ray Hill): > Then I guess I must have pointed ears. Having multiple applications on the Pointed head, methinks. > see I am faster at changing code than the computer is at compiling. So I can > actually get ahead. You can write code faster than the computer can compile it? Give the world a demonstration, maybe we could sell tickets. >>Lyman S. Taylor lyman@ames-aurora.arpa >>NASA Ames Research Center or Maybe Lyman is one of those AI expirements run amuk. -- Lawrence A. Dziegielewski | E.I. Dupont Co. uunet!eplrx7!lad | Engineering Physics Lab Cash-We-Serve 76127,104 | Wilmington, Delaware 19898 MABELL: (302) 695-1311 | Mail Stop: E357-318
dlw@hpsmtc1.HP.COM (David Williams) (03/08/88)
Arrggggghhhh! Since when do you SIMULTANEOUSLY do input into 2 or more windows???? I keep reading you guys who edit in one window while running a compile in another etc etc, yet you miss the point--I do the same thing now under MultiFinder. In order to context switch under MultiFinder all I do is click on the window I want to interact with (ie type input into or perform some new function), this does not mean that something is not going on while I am in another window! In order to context switch to another window under the X Window System, I have to move the mouse into the window for it to be the active one. So, the difference seems to be one of moving and clicking the mouse versus moving the mouse. Now I'm sure the nanosecond police are going to say that they save hundreds of man hours by not having to click the mouse, but it seems a bit extreme to me! As for the we don't need no steenking menu bars guys, there are several alternatives available on the mac. One called PopUp DA allows you to turn the menu bar into *GASP* a POPUP menu which appears anywhere on the screen you press the mouse/option key! Wow, I feel more with it already. : ) :) I guess all you NeWs and Amiga guys have 5 keyboards,mice,monitors for the 5 pairs of eyes and arms on your alien bodies...;^) David "quietly Multitasking on my Mac II" Williams Hewlett Packard - Software Development Technology Lab "My other computer is a Mac +","Ack, Ooop","Captain, I detect incoming flames from comp.sys.amiga...Mister LaForge set sheilds to boring indifference"
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/08/88)
In article <8038@uunet.UU.NET> dsc@izimbra.CSS.GOV (manic pop thrill) writes: |i cannot speak for the original poster, but what i think he was trying |to say was that at any one time you (the human) would not be typing |into two editors at once, or would not be filling in two dialog boxes |at once, or would not be typing a spreadsheet command at exactly the |same time you are typing text into an editor. you can be running a |number of programs simultaneously, but at any one time you are |interacting (using the mouse, keyboard, lightpen, etc) with at most |one. although there may be other windows on the screen where |computation is going on, or data is being printed, there is only one |window that the user is interacting with directly. A couple of small points. Roger Sperry, who was awarded the Nobel Prize a few years ago might disagree with you on whether humans can do two things simultaneously or not. But that doesn't belong to this newsgroup. SunView allows you to split the focus, so all keyboard activity goes towards one window, and all mouse activity follows the mouse curser. So you could do one activity with the keyboard, and another with the mouse. -- You mean you DON'T read USENET while playing SDI (e.g. missile command)? - :-) -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
stpeters@dawn.steinmetz (Dick St.Peters) (03/08/88)
In article <8038@uunet.UU.NET> dsc@izimbra.CSS.GOV (manic pop thrill) writes [quoting me]: >>I *routinely* do things in parallel in different windows. At its most >>extreme, this means using several windows on my Sun to watch debugging >>output from rlogin sessions running communicating network peers on > >i cannot speak for the original poster, but what i think he was trying >to say was that at any one time you (the human) would not be typing >into two editors at once, or would not be filling in two dialog boxes >at once, or would not be typing a spreadsheet command at exactly the >same time you are typing text into an editor. you can be running a >number of programs simultaneously, but at any one time you are >interacting (using the mouse, keyboard, lightpen, etc) with at most >one. although there may be other windows on the screen where >computation is going on, or data is being printed, there is only one >window that the user is interacting with directly. According to mail I got from the original poster, "the point is can you _read_ [his emphasis] two screens at once, or do you just alternate". While looking at debugging output in one window I can perceive when the output from the network peer in an adjacent window changes. This is simultaneous use by any reasonable definition - but I take a much broader definition. The original poster's challenge was to the worth of multiple windows & multi-tasking. Not having these is like trying to do library research under a one-book-at-a-time restriction. If you have more than one book open on your desk, you're benefiting from their simultaneous *presence*. Quibblers who say that since you can only *read* one at a time, you only *use* one at a time are missing the point. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
stpeters@dawn.steinmetz (Dick St.Peters) (03/08/88)
In article <3671@cup.portal.com> roger_warren_tang@cup.portal.com writes: > > Instead of guessing, why not asky the cognitive people? > > > And they'll tell you that humans pay attention to only one thing at a time. This is a distortion of what "attention" means. Humans have a primary attention *focus*, but they simultaneously receive and process other information - which can mean information from another sense (hearing, smell, feel, etc.) or from a non-central part of the visual field (noticing motion "out of the corner of your eye", for example). This information is not the focus of your attention, but processing it is being attended to. >The example about gauges and flying is inaccurrate; a pilot glances outside, >then to the gauges and then outside again. The example *is* relevant. When you fly on instruments, you cannot stop yourself from receiving peripheral-vision information about the orientation of the horizon (assuming it's visible), except by wearing a hood that cuts off your external view. Such hoods are standard gear for practicing instrument flying in visual-flight weather. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
lonetto@phri.UUCP (Michael Lonetto) (03/08/88)
I hope that all of the Unix types who are talking about how task switching can't possibly work right if the menu bar at the top of the screen has to switch for each application will avail themselves of the chance to play around with multifinder, preferably on a machine with enough memory to run a few things at once. While the description sounded pretty dubious to me, it WORKS incredibly well. Any open application can have windows on the screen. If a program is capable of doing output in the background (spreadsheet recalculation, graphing program, etc) you can passively watch it.( While most mac programs don't do this now, I don't think it will be that long before they do.) If you click on an open window, that application becomes the "active" application: all of its windows come to the front and it gets the menu bar. This happens very fast and it is quite easy to select, cut/copy, click on an open window from another application, and paste. The whole operation is faster than getting from one directory to another in Unix. As far as being a system for small screens, with 2.5 meg and multifinder, the screen is way too small. Navigating something 2-4 times larger doesn't make getting to the menubar much harder. If you put menus in the windows, which windows do you put them in? All of them? Even for applcations that can have 7-8 windows open at once? Sounds pretty wasteful of the screen to me. Well that's enough for me... -- Michael Lonetto UUCP:(allegra!phri!lonetto) Dept of Applied Genetics Public Health Research Institute, 455 1st Ave, NY, NY 10016
mwm@eris (Mike (My watch has windows) Meyer) (03/08/88)
In article <5674@cit-vax.Caltech.Edu> sho@tybalt.caltech.edu.UUCP (Sho Kuwamoto) writes: <In response to someone who said the <Amiga system was slightly better because it has a seperate button for <the mouse, Get REAL! The Amigas menu bar switches depending on the <active windows, it's just that you can't see it until you hit the <right button. No, having a second mouse button _is_ a win. You don't gain any confusion because there is an Interface Guideline which basically says "thou shalt use the right mouse button for menus (and similar things)." Very few programs use "similar things," and those that do do it right. My experience is that people (artists, etc.) don't have trouble with the second mouse button. On the other hand, you _do_ lose some capabilities. Without doing any customization, you lose the "mulitple select" capabilities of the Amiga. I'm used to configuring programs (at least until I set up the config files) by doing "mouse menu button; pull down config menu; mouse select on all options; let up mouse menu button." On the Mac, this turns into "mouse menu button; pull down config menu; select an option and let up mouse button; repeat for all options." Much slower - but still available on the Amiga for the inexperienced users. <Another thing that scares me. Customizable mice seem fine for a multi <user environment; if I get an account on a new Sun, I copy over my <setup files or whatever and everything is hunky dory, right? But for <a single user machine, I couldn't imagine what would happen if *my* <mac functioned differently from the one my friend has, which <functioned differently from the one the school has for public use. You mean the Mac isn't customizable _at all_? You can't put in your favorite desktop accessories, and can't load the function keys with your favorite acceloraters? And what's this I heard about pop-up menus on the Mac? They don't exist? Or don't count as customization? Nah, having a customizable micro will work like it always has, and like having a customizable shell or editor does on Unix - when you need to work in a different environment, you either arrange to load your favorite environment, or use the lcd version. The former means booting your system disk on the Mac/Amiga/CPM-80/MSDOS/whatever, and creating a login shell as you on a Unix system. No big deal. And now you start getting to the _real_ wins with that second mouse button. If you've got popup menus, how do you distinguish between a click to go to an application and a menu click? I like having a "follow-mouse" interface, instead of a "click-to-type" interface. Consider the problem of getting the mouse from the application at the bottom of the screen to the menu bar at the top. With two buttons, it's easy - I just hold down the menu button as I go. With one button, how do I prevent another window from activating while I move it? As DRI demonstrated, the Mac menu interface can be put on an two-button mouse with no problem. Until you demonstrate that a two-button interface (pop up menus + followmouse, or some such) can be adequately dealt with (by that, I mean that you don't have to drive the window manager with two hands) on a one-button mouse, the one-button mouse will have to be considered inferior. Of course, Apple may have done it right, and left hooks in the software for more buttons. I know Amiga did. <What happens with context-sensitive popup menus when the program has <no windows open? Say you're running a memory based word processor and <you have two enormous files to edit. You edit the first one, close <it, and edit the second one. Where do you click to get your popup <menus when there are no open windows? The same place you click to reactive it under multifinder :-). Seriously, there are lots of answers, depending on how the rest of the window manager works. And from another source: >> And don't forget the Mac was the first 'commercially available' >> personal computer to feature a windowing interface and a secondary >> input device known as a mouse. Not hard to not forget - it's not true. Or don't you remember the Lisa? If you define "personal computer" to be distinct from "home computer," then you can also count the Star as a predecessor to the Mac. The Mac wasn't the first - it was just the first to not flop. <mike -- Il brilgue: les toves lubricilleux Mike Meyer Se gyrent en vrillant dans le guave, mwm@berkeley.edu Enmimes sont les gougebosqueux, ucbvax!mwm Et le momerade horsgrave. mwm@ucbjade.BITNET
garry@batcomputer.tn.cornell.edu (Garry Wiegand) (03/08/88)
In a recent article lad@eplrx7.UUCP (Lawrence A. Dziegielewski) wrote: >From article <2460@nicmad.UUCP>, by hill@nicmad.UUCP (Ray Hill): >... >Pointed head, methinks. >... >You can write code faster than the computer can compile it? Give the world >a demonstration, maybe we could sell tickets. >... >Maybe Lyman is one of those AI expirements run amuk. [My apologies for posting this, but the mail address on this end for L.A.D. looks unusable.] Lawrence, I think your posting was offensive. It's mean-spirited (and rather adolescent) to argue by mocking and making fun of someone making honest remarks. Are you really that nasty of a person? garry wiegand (garry@oak.cadif.cornell.edu - ARPA) (garry@crnlthry - BITNET)
sho@tybalt.caltech.edu (Sho Kuwamoto) (03/08/88)
In article <7481@agate.BERKELEY.EDU> mwm@eris.UUCP (Mike (My watch has windows) Meyer) writes: >In article <5674@cit-vax.Caltech.Edu> sho@tybalt.caltech.edu.UUCP (Sho Kuwamoto) writes: ><In response to someone who said the ><Amiga system was slightly better because it has a seperate button for ><the mouse, Get REAL! The Amigas menu bar switches depending on the ><active windows, it's just that you can't see it until you hit the ><right button. > >No, having a second mouse button _is_ a win. You don't gain any >confusion because there is an Interface Guideline which basically says >"thou shalt use the right mouse button for menus (and similar >things)." Very few programs use "similar things," and those that do do >it right. My experience is that people (artists, etc.) don't have >trouble with the second mouse button. > This could very well be true. I have not dealt much with Amiga software, but the most important thing (in my opinion) to have in a windowing environment is a consistent user interface accross applications. > [Describes benefits of menu button] > ><Another thing that scares me. Customizable mice seem fine for a multi ><user environment; if I get an account on a new Sun, I copy over my ><setup files or whatever and everything is hunky dory, right? But for ><a single user machine, I couldn't imagine what would happen if *my* ><mac functioned differently from the one my friend has, which ><functioned differently from the one the school has for public use. > >You mean the Mac isn't customizable _at all_? You can't put in your >favorite desktop accessories, and can't load the function keys with >your favorite acceloraters? And what's this I heard about pop-up >menus on the Mac? They don't exist? Or don't count as customization? The idea is that users can add functionality through customization but rarely take away functionality. If my neighbor has installed the pop-up init, I can use a complex combination of modifier keys to save time and get at my menus more easily. On the other hand, if I do not know about this ability, I can reach up to the menubar as usual. Now if a sun user has made it so that the rightmost button is resize, the leftmost button is selct from menu, and the center button is hop into the editor, this is fine for him, but h*** for me. Now I don't know a thing about Suns (I wish I did, they seem like very nice machines too.) but if a user typically changes the functionality of the existing interface, that could potentially cause problems. (Try using an editor in someone else's account where he's re-bound all the keys to work with the function keys on his terminal...) > > [more advantages of multiple mouse buttons] > >As DRI demonstrated, the Mac menu interface can be put on an >two-button mouse with no problem. Until you demonstrate that a >two-button interface (pop up menus + followmouse, or some such) can be >adequately dealt with (by that, I mean that you don't have to drive >the window manager with two hands) on a one-button mouse, the >one-button mouse will have to be considered inferior. Of course, Apple >may have done it right, and left hooks in the software for more >buttons. I know Amiga did. > I don't believe Apple has. Too bad. This is not a complete defense of the one-button mouse, as I have had little experience with a multi-button mouse. However, the fact that one is more powerful than the other does not prove that one is more useful than the other. If this were so, we would have five button mice with pressure sensitive keys that would do different things for each of the 2^5 combinations of keys depending on how hard the keys were hit. To make this more fair, consider the following analogy. Why make automatic transmissions when you can use manual transmissions? If I *want* to change gears at exactly the same time an automatic would shift, I can. However, I have the option of dropping my car into 3rd on the freeway to pass another car, or putting it into 5th on surface streets to save gas (Don't laugh, I know someone who does this.) The only problem is that manual transmissions are more difficult to use. Those who are experienced at driving a stick will say that it's just as easy once you get used to it. However, it seems evident that a large percentage of the populace prefers automatic transmission just the same. To them, it seems hardly worth their effort to learn to drive a stick for little or no percieved benefit. In the case of the Amiga mouse, it seems that the right mouse button is pretty much reserved for menus, which means that it's probably not that much harder to use. On the other hand, if *basic* functions are implemented in terms of multiple button mice in different ways for different programs/machines, it could very well be a hassle that is more trouble than it's worth. -Sho SonicYouthREMBeatlesKateBushReplacementsResidentsHuskerDuSeveredHeadsArtOfNoise ChrisAndCoseyJoyDivisionKillingJokeLaurieAndersonWireLouReedSkinnyPuppyBrianEno (sho@tybalt.caltech.edu, sho@caltech.bitnet, ...!cit-vax!tybalt!sho)
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (03/08/88)
In article <3172@phri.UUCP> lonetto@phri.UUCP (Michael Lonetto) writes: |I hope that all of the Unix types who are talking about how task |switching can't possibly work right Well - I don't think we said it wouldn't work right. I admit I have difficulty imagining how the multifinder works. I would guess you Mac-types have a difficult time imagining how something like SunView or NeWS works. We both learn something new! |If you |put menus in the windows, which windows do you put them in? All of |them? Even for applcations that can have 7-8 windows open at once? |Sounds pretty wasteful of the screen to me. That's why people use pop-up windows. They take up NO SPACE, unless you need them. and then you don't have to move your mouse at all to get the menus. From your question I see that pop-up menus aren't understood. Perhaps an simple overview of the SunView 3-button arrangement would be interesting to the Mac-ites? Primary rule: If you want to do something, but don't know what your options are, you hold down the right mouse button. A pop-up menu appears - showing you your choices. (Like the title bar). Some choices have several options - indicated by an arrow pointing right. By moving the mouse to the appropriate arrow, another menu appears, with possibly more menus even further right (indicated by more arrows). You move the mouse to the action you want (it is in reverse video) and let go. The action is performed, the pop-ups go away. You can see the parallel to the pull-down menus - I am sure. The choices are context sensitive, with three main areas: desktop or root level used to open new applications, repaint, etc. application border window manager functions, like moving, resizing, open/closing, exposing/hiding application specific functions depends on the application The nice thing about this is that if you stick with the right mouse button, you can perform any basic operation. Because the user has to select the action and let go, the system doesn't generally surprise the user. (Yes I know I am glossing over some fine points). Another benefit is that any part of the border can be used to change the size or position of the window. As the user grows more sophisticated, they learn that the other two mouse buttons are accelerators, and can be used to perform the basic open, close, resize, move, zoom operations without the cumbersome pop-up menus. In all cases, the user can experiment with the buttons because anything with drastic results must be confirmed. Usually with the opposite button that caused the action. Clicking too many times doesn't usually change anything. I have taught beginners how to use SunView, and I don't agree that three-button mice are hard to use. I frequently get asked about faster ways of doing some common operations. But most people find SunView very simple to use. I should also mention that SunView has several options (e.g.): (Point is - don't flame a window system until you understand it.) Menu styles (16 variables) like expanding initial selections Scrollbar styles (13 variables) Input (14 variables) like mouse motion scaling SunView (12) like icon gravity, click-to-type (split-focus) Yes - SunView is very different than a Mac. But I don't know how different myself. Which is why I have posted my questions. I would like to compliment everyone on the quality of the postings so far. These conversations have been very interesting to me. Thank you. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
dwb@Apple.COM (David W. Berry) (03/09/88)
> According to mail I got from the original poster, "the point is can > you _read_ [his emphasis] two screens at once, or do you just alternate". > While looking at debugging output in one window I can perceive when > the output from the network peer in an adjacent window changes. This > is simultaneous use by any reasonable definition - but I take a much > broader definition. > > The original poster's challenge was to the worth of multiple windows & > multi-tasking. Not having these is like trying to do library research > under a one-book-at-a-time restriction. If you have more than one > book open on your desk, you're benefiting from their simultaneous > *presence*. Quibblers who say that since you can only *read* one at a > time, you only *use* one at a time are missing the point. So, if what you really want is the ability to have a terminal session in the background that you can watch out of the corner of your eye while you edit in another window, multifinder does that quite well. If you want to have multiple windows open on multiple files, even with multiple editors, multifinder does that quite well. Multifinder is multitasking, by all the requirements you've given. What multifinder is weak at is things that require preemptive multitasking. And very little actually requires it, most programs can be easily modified to voluntarily task switch periodically. I've even seen c compilers, pascal compilers, and assemblers which can be used in the background while other things happen in the foreground under multifinder. If you're going to berate things, make sure you've at least seen them and/or researched them thoroughly, even if you have to live with a one-book-at-a-time restriction. > -- > Dick St.Peters > GE Corporate R&D, Schenectady, NY > stpeters@ge-crd.arpa > uunet!steinmetz!stpeters David W. Berry dwb@well.uucp dwb@Delphi dwb@apple.com 973-5168@408.MaBell Disclaimer: Apple doesn't even know I have an opinion and certainly wouldn't want if they did. Garbage lines to make inews happy. Garbage lines to make inews happy. Garbage lines to make inews happy. Garbage lines to make inews happy. Garbage lines to make inews happy. Garbage lines to make inews happy. Garbage lines to make inews happy. Garbage lines to make inews happy.
des@jplpro.JPL.NASA.GOV (David Smyth) (03/09/88)
In article <3172@phri.UUCP> lonetto@phri.UUCP (Michael Lonetto) writes: [talks about how a single menu bar at the top of the screen which changes to reflect the single application which is currently active: ] >While the description sounded pretty dubious to me, it WORKS incredibly >well. ... Well, lots people think vi works incredibly well too. Really, this top-of-screen menu bar is "modal" and modality is really evil and confusing. One of Xerox's design tenets for good human interfaces is "No modes!" and a good tenet it is. Why not attach the menu bar to the application window (the controlling window if there are lots of them). Then there is no concept of modality to the menu bar, and things like network applications work too. What do you do when there is no concept of "foreground"????????????
buzz@phoenix.Princeton.EDU (M. Zabetian) (03/09/88)
For all of you have have problems with how menus should be displayed while multitasking, or which window will accept input, or whether you can do two (three, four, five....) things at once, *PLEASE* take a look at MultiFinder. I am sure I am not the only one who is tired of seeing articles on how it won't be possible for having many applications run because of the menubar, or how the windowing is confusing. I have been using MultiFinder for months now. I have Versaterm running in the background while I type papers in MS-Word, and MacPaint wating in the background till I am ready to copy pictures from it and paste it into word. That's three things at once (by the definition someone gave of doing things at the same time-open books) If I get mail, Versaterm(connected to modem to UNIX host) beeps and I see it in the corner of my eye as it scrolls up. I can also download something while continueing my paper, and then without quitting any of the applications, I can use StuffIt to unstuff the file. On a SUN(most the time) the window accepting the input is the window that the cursor is above. On the Mac it is just as fast; just click on the window you are interested in. If you can't see the window, then click on the MultiFinder icon, or use the Apple menu. And about getting sore wrists from moving the cursor in big screens. If you select the fast mouse tracking in the control panel, you only have to move the mouse about ONE and a HALF inches(average in my case, may vary depending on wrist)!! (For the Apple Mac II color monitor) Please try playing around with a Mac before you start criticising it. Remember how mom used to say "How do you know you don't like it if you haven't tasted it??" -- Mahboud Zabetian buzz@phoenix.princeton.edu 183 Little Hall (609) 520-1271 Princeton University, Princeton, NJ 08544 (609) 734-7760 ****** Anyone need a soon-to-graduate hardware/software engineer? ********
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/09/88)
In article <5674@cit-vax.Caltech.Edu>, sho@tybalt.caltech.edu (Sho Kuwamoto) writes: # In article <1735@ssc-vax.UUCP> benoni@ssc-vax.UUCP # (Charles L Ditzel) writes: #Finally (if you do have multitasking) It gets worse (as I percieve it) on #an abstract level...when two windows are on top (side by side) why should #you choose one over the other in putting a menu bar up for that one? Can #you really design a system which unnecessarily defines user activity in a #>serial manner and *predict* the type of applications you will see in the #future. You wind up limiting your user interface today and for the future. > > Enlighten me. If you have two windows side by side on a Sun, what > happens when you type something from the keyboard? Why should you > choose one over the other in sending characters to it for that one? Your cursor is *IN* that window. That is you are explicitly defining the environment you want your keyboard input and mouse input to go to. That doesn't mean that *other* applications (within windows) are not active. > Can you really design a system which unnecessarily defines user > activity in a serial manner and *predict* the type of applications you > will see in the future. Yes. The issue is really designing a system which *out of necessity* defines user input :) Lots of systems exist that *unnecessarily* constrain user activity. The MacOS may be viewed by some as an example of one these systems (i.e., no command shell, serial menu-bar activity, etc) The context of my response was to the suggestion that a Multi-user Mac would change the *menu-bar* when an application was at the top OR chosen. My comment was that the menu-bar was fine in a serial environment however in a multi-tasking environment, the user inputs should be contrained *within* the applications window. Why should the desktop *deal* with inputs of *one* of its windows(i.e. :application environments)? If anything a desktop menu-bar should deal with meta-events, that is events that act upon the desktop environment (for instance, open a new window). However, a desktop menu-bar robs you of pixels in an already limited screen...a more logical solution is Sun's SunTools popup/pullright menus (which are customizable) and Window frame menus. > In either case, it seems that certain events can only be posted to the > active window (whether or not it is topmost) and you are always going > to have this type of problem. In response to someone who said the You are correct, as far as input via the keyboard/mouse. You are not *always* going to have this problem. A simple touch screens that groks two fingers on two different windows is a simple example. > Another thing that scares me. Customizable mice seem fine for a multi > user environment; if I get an account on a new Sun, I copy over my > setup files or whatever and everything is hunky dory, right? But for > a single user machine, I couldn't imagine what would happen if *my* > mac functioned differently from the one my friend has, which > functioned differently from the one the school has for public use. Why do *so* many people think that the ability to customize or extend is necessarily scary. Done correctly, this would be a feature. A key on keyboard could reset your mouse to a default and knowable configuration. > There are definite problems with the Mac interface, such as the grow > box being in the right hand corner and all. However, these are all a > side effect of the way it was designed. Ease of use was built in > before Apple realized that power was important too. I think a three > button mouse would confuse the, uh, counfuse the... stuffing out of > beginners, especially if all three buttons were somehow necessary to > do the most basic, necessary tasks. > -Sho I would say the one button mechanical mouse is a drawback. You are correct the Mac was designed for a beginner (which is not necessarily bad - it has been its strength but its lack of power is its weakness)... There is no reason a priori to view a three button mouse as more confusing...properly done...it could be a benefit...(for example : the first mouse button could be the normal Mac mouse button, the second mouse button could invoke a builtin MacOS editor, the third mouse button could be a help button or somesuch thing - i make no claim that this is the ideal...just an example.)
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/09/88)
In article <581@eplrx7.UUCP>, lad@eplrx7.UUCP (Lawrence A. Dziegielewski) writes: # From article <2460@nicmad.UUCP>, by hill@nicmad.UUCP (Ray Hill): # > Then I guess I must have pointed ears. Having multiple applications > Pointed head, methinks. # > see I am faster at changing code than the computer is at compiling. > You can write code faster than the computer can compile it? > Give the world a demonstration, maybe we could sell tickets. Maybe you should give the world a demonstration of your ability to read and explain correctly what the person was trying to say. :) A Hint for you Lawrence : The keyword is *changing*.
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/09/88)
In article <3172@phri.UUCP>, lonetto@phri.UUCP (Michael Lonetto) writes:
# I hope that all of the Unix types who are talking about how task
# switching can't possibly work right if the menu bar at the top of the
# screen has to switch for each application will avail themselves of the
# chance to play around with multifinder, preferably on a machine with
# enough memory to run a few things at once.
No one is saying it *can't* work. People are saying it is inelegant
and poorly thought out...given what other systems are doing.
# to select, cut/copy, click on an open window from another application,
# and paste. The whole operation is faster than getting from one
# directory to another in Unix.
You are comparing Apples and Oranges. You can get from one Sun window
to another just as fast (what you should have been comparing).
# As far as being a system for small screens, with 2.5 meg and
# multifinder, the screen is way too small. Navigating something 2-4
# times larger doesn't make getting to the menubar much harder. If you
# put menus in the windows, which windows do you put them in? All of
# them? Even for applcations that can have 7-8 windows open at once?
The desktop can have a *customizable* menu. Windows have menus that
are unique to the application.
# Sounds pretty wasteful of the screen to me.
The waste is in the pixels the menu-bar uses. The workstation menus
are popup...therefore do not clutter the screen. You click your mouse
and presto. :) benoni@ssc-vax.UUCP (Charles L Ditzel) (03/09/88)
In article <1740@ssc-vax.UUCP>, benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > Your cursor is *IN* that window. That is you are explicitly defining > the environment you want your keyboard input and mouse input to go to. Let me be more exact...you put your mouse arrow within a window and the hollow cursor (Sun's have more than one cursor - a hollow cursor indicates dormancy - versus a filled cursor which indicates activity) becomes filled (indicating that you can start typing).
mfi@beach.cis.ufl.edu (Mark Interrante) (03/09/88)
In article <1743@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > >The waste is in the pixels the menu-bar uses. The workstation menus >are popup...therefore do not clutter the screen. You click your mouse >and presto. :) Many machines provide some type of status bar that occupies a small part of the screen. It does not seem unreasonable to maintain pertainent information in a viewable place. Examples of such data that I use are: time, disk/cpu/ network running lights, message window (for incoming mail notices, meeting notices, etc.). Mark Interrante CIS Department University of Florida Internet: mfi@beach.cis.ufl.edu Gainesville, FL 32611 (904) 335-8051
chekmate@athena.mit.edu (Adam Kao) (03/10/88)
In article <7593@apple.Apple.Com> dwb@Apple.COM (David W. Berry) writes: > Multifinder is multitasking, by all the requirements you've given. Ah yes, the old, "if it walks like a duck . . ." argument. But I think in this case the argument is actually "Well it almost walks like a duck, and it almost looks like a duck, and it almost quacks like a duck." I hope you'll understand if in this case I'd rather have a real duck (roasted, please :-)). Multitasking is a simple, neat idea that resulted in major gains in productivity. Multifinder is an attempt to give the Mac some of the greatest benefits of multitasking. Seeing as how the Mac has single-tasking written all over its OS I don't see how Multifinder can be anything but large and complicated. In other words: ---> IT'S A HACK. <--- A great hack, probably, but a hack. David admits there are areas where Multifinder is less than multitasking. I know of no areas where multitasking is less convenient than Multifinder. In fact who's to say there aren't other areas we haven't thought of, because we aren't clever enough? Multitasking is a _new_way_of_ _using_ that little box on your desk. Simple ideas inevitably get used in ways their originators never thought of. Multifinder is a specialized simulation of multitasking, and you'd have to extend it if you wanted to simulate some aspect you forgot about. Okay, I guess what I have here is an existence proof without the existence. But try reversing my argument. "Multitasking is a specialized simulation of Multifinder." Doesn't that sound a little ridiculous to you? Doesn't that imply there's some asymmetry here? People keep saying Multifinder can do what multitasking does. But there is at least one thing multitasking has over Multifinder: generality and simplicity (was that two? Or really one? never mind). What does Multifinder have over multitasking? In other words: ---> WHY WOULD ANYONE WANT TO USE MULTIFINDER??? <--- What's that? Mac software? Who cares about Mac software? Adam disclaimer: MIT lets me use their equipment because I pay them $12,500 a year.
reggie@pdn.UUCP (George W. Leach) (03/10/88)
In article <13650002@hpsmtc1.HP.COM> dlw@hpsmtc1.HP.COM (David Williams) writes: >So, the difference seems to be one of moving and clicking the mouse versus >moving the mouse. Now I'm sure the nanosecond police are going to say that >they save hundreds of man hours by not having to click the mouse, but it seems >a bit extreme to me! I think we are straying into a matter of personal opinion here on this issue as well as the issue of how many mouse buttons are appropriate. What is really needed are some empirical studies. The hardcopy and CRT terminal technology is fairly well studied in terms of human factors. The bit-mapped graphical user interface which typically uses windows, menus, icons, along with a mouse and keyboard for input has not been studied extensively enough to backup any arguements. My personal opinion on mouse buttons is a reflection of what I am accustomed to. I have used the Blit (DMD 6520), UNIX PC (7300), Sun 3, and a PC with a Logitech mouse. All have three buttons! So to me that seems natural. My opinion on context switching between windows is mostly based on personal preferences, but I also think I have a decent point to make. I prefer to click on the window I want to activate. There are two reasons. First, if I accidently bumb into the mouse I most often change the current window. I didn't want that to happen. I am loosing a bit of control. If I move the mouse and explicitly click on a window I definitely want a context switch to occur! My second reason is that once I activate a window I want the mouse cursor out of my view. Only with a point and click model can I move the mouse cursor off the window's real estate. -- George W. Leach Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826
sbb@esquire.UUCP (Stephen B. Baumgarten) (03/11/88)
In article <1743@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: >The waste is in the pixels the menu-bar uses. The workstation menus >are popup...therefore do not clutter the screen. You click your mouse >and presto. :) Somehow I don't think this is problem, since I have yet to see a Sun user running without that silly analog clock and load average graph taking up a quarter of their screen.... :-) -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." ...!cmcl2!esquire!sbb | - David Letterman
fink@mist.cs.orst.edu (Paul Fink) (03/11/88)
>In article <241@eos.UUCP> lyman@eos.UUCP (Lyman Taylor) writes:
< Unfortunately, us humans can only handle ONE high level cognitive task
<at once.
Ever try to walk and chew gum at the same time?tomwest@gpu.utcs.toronto.edu (Tom West) (03/11/88)
I am afraid that the advocates of multiple button mice have made a beautiful theoretical case without looking at the reality of micro software. Having used Macs, Amigas and STs (although mostly Macs), I have found that in most software there is an *incredible* abuse of the general use rules for mice. The second button gets used in all sorts of incredibly bizarre (and completely un-intuitive) ways. I have complained to the owners of the respective machines and met with loud protests of the fact that it is only this piece of software and that the principal still holds true. Unfortunately, the principal doesn't make for ease of use, especially when the software designers are not looking at principals, but at profit. Claims that violating the interface will hurt sales seems unlikely, at least in an environment where such violations are common, as seems to be the case in the multiple button micro environment. We only have to see how hard software designers work to violate the Mac interface when the rules are written in stone for all to see, to realize that given a degree of freedom beyond what is necessary, it will be abused to provide inconsistent and confusing interfaces between programs. Each designer builds their program customized to maximize the throughput and keep *their* program consistent. But unless they have the thought police running all over them, *and unless they have the hardware limited*, they will customize their own software until inter-program consistency is a pipe-dream. This may be different in the Sun market, but I assure people that in the micro market, this definitely seems to be the way of things. -- Tom West BITNET: tomwest@utorgpu.bitnet, tomwest@gpu.utcs.utoronto Internet: tomwest@gpu.utcs.toronto.edu UUCP: tomwest@utgpu utzoo, yetti, harpo, mnetor \ cbosgd, deepthot, utoronto - !utgpu!tomwest ihnp4, lsuc, sfmin, vnr-vpa /
peter@sugar.UUCP (Peter da Silva) (03/11/88)
...and it succeeds in making a 68020 feel like it's as slow as an 8088. In article <6895@drutx.ATT.COM>, clive@drutx.ATT.COM (Clive Steward) writes: > But think that some of the work$tation users who are in this discussion > are missing very important information. You can see everything at the same > time. Please try a Mac with Multifinder. I've tried it. Quickly, stop what you are doing and resize some window that's not part of the terminal program you're in. You click that window's sizing gadget, and wait about a second while Multifinder tells the program that you've activated its window, and it brings it to the front and repaints all the scroll bars and the title bar and everything. Even if that window was the active one, there can be up to half a second wait while the program gets around to realising that you clicked in its sizing gadget. If you move the mouse outsize that box while you're waiting it blows you off. A very frustrating episode all round, particularly after working with my lowly Amiga with its instantaneous real-time response to user events. And it's even cheaper than the Mac. $1200 gets you a VERY full-featured color system. I won't pretend that the display is Sun or even Mac-II quality, but it's definitely in the Mac-plus range. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (03/11/88)
In article ... sho@tybalt.caltech.edu (Sho Kuwamoto) writes: > to have this type of problem. In response to someone who said the ^^^^^^^--- Present! > Amiga system was slightly better because it has a seperate button for > the mouse, Get REAL! The Amigas menu bar switches depending on the ^^^^^--- I presume you mean "a seperate button for the menus". > active windows, it's just that you can't see it until you hit the > right button. You're absolutely right. I am really upset with Amiga for copying this design flaw in the Mac, and for Apple for making it appear desirable. However, it's still better than the Mac menu bar because you don't have to give up screen real-estate for a menu bar that's usually not needed. So, it's only a slight advantage (which is, as you've pointed out above, all that I said it was). Real pop-up menus would be much more desirable. It's on my list of projects. At least on the Amiga it's possible to fix this problem. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (03/11/88)
In article ... sho@tybalt.caltech.edu (Sho Kuwamoto) writes: > Another thing that scares me. Customizable mice seem fine for a multi > user environment; if I get an account on a new Sun, I copy over my > setup files or whatever and everything is hunky dory, right? But for > a single user machine, I couldn't imagine what would happen if *my* > mac functioned differently from the one my friend has, which > functioned differently from the one the school has for public use. Agree with you on this. The more standardistion in the user interface the better... but let's make sure we've got all the bugs worked out first. Redefining the meanings of mouse buttons is a bit hairy. Some programs on the Amiga redefine the menu button, and it bugs me. Slows me down. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
lsr@Apple.COM (Larry Rosenstein) (03/12/88)
In article <1514@devvax.JPL.NASA.GOV> des@jplpro.JPL.NASA.GOV (David Smyth) writes: > >top-of-screen menu bar is "modal" and modality is really evil and >confusing. One of Xerox's design tenets for good human interfaces >is "No modes!" and a good tenet it is. Modelessness is very important. I don't think placing a menu bar at the top of the screen creates a mode. The mode comes from the fact that on the Macintosh only 1 application at a time can have the input focus (which includes both mouse and keyboard input). The system takes advantage of the mode to reuse the screen space by swapping menu bars. Note that any system is going to have a mode related to the keyboard input. >Why not attach the menu bar to the application window (the controlling >window if there are lots of them). Then there is no concept of modality >to the menu bar, and things like network applications work too. This tries to eliminate the modality by making all the menu titles visible and available to be selected. If any of the titles are hidden, then you are back in a mode. Putting the menu bar at the top of the screen has one advantage over a menu bar in the window. The user has much more leeway in hitting a menu title at the top of the screen than one in the window, because if you can't overshoot the top of the screen, but it is easy to overshoot the top of a window. (Actually on a Mac II you could configure your screens so that the top of the menu bar would not be the top of the total screen area.) With the mouse acceleration built into the Macintosh, it doesn't require much motion to move the mouse to the top of the screen and back again. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
lsr@Apple.COM (Larry Rosenstein) (03/12/88)
In article <3609@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes: > >greatest benefits of multitasking. Seeing as how the Mac has >single-tasking written all over its OS I don't see how Multifinder >can be anything but large and complicated. In other words: >---> IT'S A HACK. <--- Large and complicated compared to what? Sure it would have been easier and smaller to design in MultiTasking from the start, but MultiFinder is not large (50K) and it works very well. As you said, it brings many of the benefits of multitasking to Mac users, without having to rewrite applications. >What does Multifinder have over multitasking? In other words: >---> WHY WOULD ANYONE WANT TO USE MULTIFINDER??? <--- > >What's that? Mac software? Who cares about Mac software? Millions of people care. The available Mac software is in fact MultiFinder's advantage over the Amiga or UNIX. There are many tasks for which the Mac is the best tool. (There are tasks for which the Amiga or UNIX is the best tool.) If you simply judge systems on the basis of multitasking, then MultiFinder would not offer any advantages. Most users, however, don't buy computers based on operating system features. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
dwb@Apple.COM (David W. Berry) (03/12/88)
In article <3609@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes: >David admits there are areas where Multifinder is less than >multitasking. I know of no areas where multitasking is less >convenient than Multifinder. Sigh, misquoted again. And out of context even. What I said was that MultiFinder still had some known areas where it could be improved. Not that it was less than multitasking. As a matter of fact it is fully and completely multitasking, non- premptive, but multitasking all the same. Especially when one considers that all macintosh programs should be calling GetNextEvent periodically to interact with the user anyway, and task switching is done there. If one get's right down to it, UNIX, NeWS, SunView, X, A/UX, the Toolbox and every operating system has a lot of room for improvement. In the case of "multitasking" we'll assume you mean either NeWS, SunView, or X (any version you choose) MultiFinder has one major advantage, that isn't important to a lot of folks reading comp.sys.mac but is important to the vast majority of the world. It presents a single, easily learned, consistent interface across all applications. That's something that SunView and X can't provide and NeWS has yet to prove that it will provide. > >People keep saying Multifinder can do what multitasking does. But >there is at least one thing multitasking has over Multifinder: >generality and simplicity (was that two? Or really one? never mind). >What does Multifinder have over multitasking? In other words: >---> WHY WOULD ANYONE WANT TO USE MULTIFINDER??? <--- Huh? Generality I'll grant you simply because the programmer has to go to a little more effort. As far as most users are concerned there is no difference between the multitasking present on your unix box with a windowing system and multitasking as presented by MultiFinder. A comparison of simplicity between multitasking and MultiFinder is relatively useless because multitasking is an operating system concept featured within MultiFinder. To compare apples with apples, let's compare windowing systems. All other things equal, which they basically are, consistency makes the Macintosh interface and MultiFinder simpler to learn and use than X, NeWS, or SunView. > >What's that? Mac software? Who cares about Mac software? > >Adam > >disclaimer: MIT lets me use their equipment because I pay them >$12,500 a year. Well, Adam, eventually you'll make it out into the real world and discover that there are several million people who want a system that's easy to use, presents a consistent user interface and does what Mac software does and Unix doesn't. Unix is wonderful for universities, some businesses and maybe even workstations, but it's just too big and too complex for 95% of the worlds population. David W. Berry dwb@well.uucp dwb@Delphi dwb@apple.com 973-5168@408.MaBell Disclaimer: Apple doesn't even know I have an opinion and certainly wouldn't want if they did.
chekmate@athena.mit.edu (Adam Kao) (03/13/88)
In article <7656@apple.Apple.Com> lsr@apple.UUCP (Larry Rosenstein) writes: > MultiFinder is not >large (50K) and it works very well. Well, size is all relative, you know. 50K is more RAM than my friend's Apple II ever had. And almost as much as the roms in the orignal Macs. But whatever your standards, you can't say 50K is insignificant. >>What's that? Mac software? Who cares about Mac software? > >Millions of people care. Sigh. I forgot to put in the :-). I know perfectly well that my argument is an attempt to compare multitasking and MultiFinder in a vacuum. The logic is so clean when you ignore other variables. Reality is messy. I know that millions of people own Mac software, and that this is MultiFinder's greatest (only?) advantage. Of course, _I_ don't own any Mac software, so why should I care, right? :-) :-) If all you want to do is compare multitasking and Multifinder _as_ _tools_for_switching_between_programs_, I stand by my argument. If you want to introduce extraneous variables (well, I consider them extraneous) like the software that can run under them, then let me introduce another extraneous variable: I can't afford a Mac. (-: :-) :-) (-: ;-) (^: <-: :-] 8-) \-: B-) (-: :-) o o ^ `-' >If you simply judge systems on the basis of multitasking, then MultiFinder >would not offer any advantages. Most users, however, don't buy computers >based on operating system features. Hear hear! Couldn't have said it better myself! >-- > Larry Rosenstein, Object Specialist > Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 > AppleLink:Rosenstein1 domain:lsr@Apple.COM > UUCP:{sun,voder,nsc,decwrl}!apple!lsr Adam
chekmate@athena.mit.edu (Adam Kao) (03/13/88)
In article <7658@apple.Apple.Com> dwb@apple.UUCP (David W. Berry) writes: >In article <3609@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes: >>David admits there are areas where Multifinder is less than >>multitasking. I know of no areas where multitasking is less >>convenient than Multifinder. > Sigh, misquoted again. And out of context even. What >I said was that MultiFinder still had some known areas where it >could be improved. Not that it was less than multitasking. I apologize for misinterpreting your posting. > As >a matter of fact it is fully and completely multitasking, non- >premptive, but multitasking all the same. : : > In the case of "multitasking" we'll >assume you mean either NeWS, SunView, or X (any version you >choose) You and I must have very different understandings of the term "multitasking." I would like to use this definition: "In a true multitasking system, tasks can run independently. They can also communicate with and interrupt each other." -- Caia Grisar, MIT Information Services. I do not understand how a system can be non-preemptive multitasking. Also, this may be just a slip of the tongue (finger?) on your part, but NeWS, SunView, and X are all _windowing_systems_. For example, it makes no sense to discuss the "multitasking" of X because X is merely a set of programs that interface to mouse, keyboard, and screen. Multitasking has to be implemented in the operating system, in this case Unix. This is partly why I feel MultiFinder is not multitasking; it was not written as part of the OS, it was added later. > It (MultiFinder) presents a single, easily >learned, consistent interface across all applications. That's >something that SunView and X can't provide and NeWS has yet to >prove that it will provide. Again, your points have nothing to do with multitasking. Multitasking is about _multiple_tasks_, not user interfaces. > A comparison of simplicity between multitasking and MultiFinder >is relatively useless because multitasking is an operating system concept >featured within MultiFinder. Surely you're not saying multitasking is a subset of MultiFinder? Please explain. If you really are saying that MultiFinder "is fully and completely multitasking" you're on pretty shaky ground. Multitasking systems preempt. Multitasking systems run tasks independently. Multitasking systems are simpler to implement and interface with. > To compare apples with apples, let's compare >windowing systems. That was not the intent of my original posting. If that's what YOU want to discuss, why are you following-up? As I understand it, MultiFinder is not a windowing system. MultiFinder is an addition to the operating system. > All other things equal, which they basically are, ^^^^^^^^^^^^^^^^^^ >consistency makes the Macintosh interface and MultiFinder simpler to >learn and use than X, NeWS, or SunView. I really can't let this go by. Would you mind supporting that statement? >>What's that? Mac software? Who cares about Mac software? >> >>Adam >> >>disclaimer: MIT lets me use their equipment because I pay them >>$12,500 a year. > Well, Adam, eventually you'll make it out into the real world >and discover that there are several million people who want a system >that's easy to use, presents a consistent user interface and does >what Mac software does and Unix doesn't. Unix is wonderful for >universities, some businesses and maybe even workstations, but it's >just too big and too complex for 95% of the worlds population. Don't patronize me. I have my opinions and I enjoy discussing them. Your comment precludes any discussion between us; you imply my opinions have no value because I am a student. If I agreed with you you would not make the same comment. And why do you assume I have no real world experience? Have you never heard of people working for a few years before returning to college to complete their degree? Nor do I understand your comments about Unix. I never claimed Unix was the world's salvation. I never mentioned Unix at all. I acknowledge the reality of several million Mac users (my last posting). But you still have not addressed my main point: As a tool for switching between tasks, MultiFinder has absolutely no advantage over multitasking. And at least one disadvantage (which you have granted me). > > David W. Berry > dwb@well.uucp dwb@Delphi > dwb@apple.com 973-5168@408.MaBell >Disclaimer: Apple doesn't even know I have an opinion and certainly > wouldn't want if they did. Adam "Question Authority!" "Says who?"
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/13/88)
In article <356@esquire.UUCP>, sbb@esquire.UUCP (Stephen B. Baumgarten) writes: # In article <1743@ssc-vax.UUCP# benoni@ssc-vax.UUCP (Charles L Ditzel) writes: # #The waste is in the pixels the menu-bar uses. The workstation menus # #are popup...therefore do not clutter the screen. You click your mouse # #and presto. :) # # Somehow I don't think this is problem, since I have yet to see a Sun # user running without that silly analog clock and load average graph # taking up a quarter of their screen.... :-) At least you have the *choice*. Also you have lots and lots of pixels to waste if you want to on a Sun. Also the analog clock takes up 64x64 pixels... if you don't want it don't put it there :)
benoni@ssc-vax.UUCP (Charles L Ditzel) (03/13/88)
In article <7656@apple.Apple.Com>, lsr@Apple.COM (Larry Rosenstein) writes: > In article <3609@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes: > benefits of multitasking to Mac users, without having to rewrite > applications. If you read between the lines this spells "kluge". If news accounts are correct APPLE IS REWRITING THE MAC OS. -------------- Naturally My Ideas Are My Own.
howard@cpocd2.UUCP (Howard A. Landman) (03/15/88)
In article <7658@apple.Apple.Com> dwb@apple.UUCP (David W. Berry) writes: >What I said was that MultiFinder still had some known areas where it >could be improved. Not that it was less than multitasking. As >a matter of fact it is fully and completely multitasking, non- >premptive, but multitasking all the same. Especially when one >considers that all macintosh programs should be calling GetNextEvent >periodically to interact with the user anyway, and task switching >is done there. You can see the problem but still don't admit it's there? In real multitasking NO SPECIAL CODING IS NEEDED. Most programs multitask AUTOMATICALLY without any special attention from the programmer. Under MultiFinder, each program (except possibly the last one) must be specially coded to be "MultiFinder compatible" by calling WaitNextEvent instead of GetNextEvent (if I don't have them reversed). Why is this a problem? Because it only takes one or two programs which fail to do this before MultiFinder fails to grant any CPU time at all to the lowest priority task. Why is this a problem? Because there are lots of Mac programs out there which were written before MultiFinder and are still useful, but which will never be changed. Companies go out of business. Shareware authors move on to more lucrative pursuits. Etc. I recognize that implementing real multitasking in a Mac environment is fairly tricky. The main problem with any multitasking is handling conflicts when more than one program wants to use a limited resource, such as a printer port. What makes this more difficult on a Mac is that THE SCREEN IS A LIMITED RESOURCE which has to be carefully managed, and almost every program wants the screen to itself while it's running. The original Mac solution to this was not to multitask. This was too restrictive, so Switcher was invented AS A KLUDGE to allow some of the benefits of multitasking. But still nothing could run in the background. This was too restrictive, so MultiFinder was invented AS A KLUDGE to allow background tasks to run IF THEY WERE SPECIALLY CODED. But not everything is, or ever will be. This is too restrictive, so Apple will eventually be forced to actually solve the problem, possibly by melding some feature of AUX into the Mac OS. -- Howard A. Landman {oliveb,hplabs}!intelca!mipos3!cpocd2!howard howard%cpocd2.intel.com@RELAY.CS.NET
jimc@iscuva.ISCS.COM (Jim Cathey) (03/15/88)
In article <1551@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >[Amiga]...it's still better than the Mac menu bar because you don't have to >give up screen real-estate for a menu bar that's usually not needed. Of course, the few programs I've seen leave the menu bar there, but with a program name or copyright message in it until you hit the menu button. To me, this is an even more sinful waste of screen space than menus are supposed to be! (And on a machine that was short-changed on vertical pixel count to boot.) Me, I _like_ my Mac (and my parents like thiers, too). For the class of tasks it was designed to do it does an excellent job. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
bobr@zeus.TEK.COM (Robert Reed) (03/15/88)
In article <3691@bloom-beacon> chekmate@athena.mit.edu (Adam Kao) writes:
You and I must have very different understandings of the term
"multitasking." I would like to use this definition:
"In a true multitasking system, tasks can run independently.
They can also communicate with and interrupt each other."
-- Caia Grisar, MIT Information Services.
I do not understand how a system can be non-preemptive multitasking.
It's very simple. There is nothing in a multitasking system that requires
preemptive scheduling. And there is no requirement that a multitasking
system have more than a very fundamental intertask communications system.
BSD without TCP/IP and sockets would still be multitasking, yes?
The mere fact that there is any scheduler, regardless of the algorithm it
uses, is probably sufficient justification for calling it multitasking.
There can be several tasks simultaneously ready to run, there is a scheduler
which decides at regular intervals which to make active, common resources
such as the display are shared among the tasks, and each has a preserved
context which is activated when the process is resumed. The mere fact that
there is not a timer interrupt which regularly invokes the scheduler to
force task switches is really a small matter.
A few years ago we had a timesharing system on a PDP-11/45 running
"motor-dos" a nonpreemptive multitasking system in which it was easy to hog
time when doing compute bound operations. It worked fine for running 2 or 3
editing tasks. I wouldn't recommend nonpreemptive scheduling for a
timesharing system, but it should work fine for a single user system,
especially if all the tasks are polite about deferral.
PC based spoolers and other such Terminate and Stay Resident programs
provide a form of multitasking for MS-DOS applications. These are truly
running multiple tasks--the printer is running while you are typing
characters into the text editor--but they also fall into the gray area
between strictly nonpreemptive and preemptive scheduling (because these TSRs
can enable interrupts which stimulate preemptive task suspension). In this
case there is no scheduler, but there is multitasking. So there IS more
between heaven and earth than dreamt in your philosophy.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKdwb@Apple.COM (David W. Berry) (03/15/88)
In article <3691@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes: >In article <7658@apple.Apple.Com> dwb@apple.UUCP (David W. Berry) writes: >>In article <3609@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes: > ...Lot's of discussion about how I'm confusing multitasking and windowing > systems. Well, we agree that multitasking and windowing systems are separate entities and you can't compare one to the other. That's one of the points I was trying to make. The rest of the discussion I was trying to compare windowing as available under MultiFinder and windowing as available under other multitasking systems. >You and I must have very different understandings of the term >"multitasking." I would like to use this definition: > > "In a true multitasking system, tasks can run independently. > They can also communicate with and interrupt each other." > -- Caia Grisar, MIT Information Services. > >I do not understand how a system can be non-preemptive multitasking. Caia has a very limited definition of multitasking. The more usual definition I've seen is a system that allows multiple tasks to appear to run simultaneously. Only when one starts talking about interactive multiuser multitasking is it safe to assume premptive. In all other cases it may be more efficient and desireable to have nonpreemptive. >Multitasking has to be implemented in the operating system, in this >case Unix. This is partly why I feel MultiFinder is not multitasking; >it was not written as part of the OS, it was added later. Well, fortunately, the definiton of the Macintosh OS allows such things as multitasking and other OS features to be cleanly and simply integrated in later. It's not a very valid argument to argue that all of an operating systems features must be designed in from the start. I prefer to see operating systems and computers as dynamic. > >> It (MultiFinder) presents a single, easily >>learned, consistent interface across all applications. That's >>something that SunView and X can't provide and NeWS has yet to >>prove that it will provide. > >Again, your points have nothing to do with multitasking. Multitasking >is about _multiple_tasks_, not user interfaces. Granted, but I was responding to the question of why would anybody prefer MultiFinder to multitasking. Apart from the fact that multifinder vs multitasking is like apple vs. fruit, one reason to use MultiFinder instead of other multitasking alternatives is that MultiFinder provides the only multitasking that also provides a consistent user interface across all applications and runs existing macintosh applications. >> All other things equal, which they basically are, > ^^^^^^^^^^^^^^^^^^ >>consistency makes the Macintosh interface and MultiFinder simpler to >>learn and use than X, NeWS, or SunView. > >I really can't let this go by. Would you mind supporting that statement? Well, MultiFinder provides multitasking. It allows 95% of all users to do all the things one expects of a multitasking system. That seems pretty equal to me. > >>>What's that? Mac software? Who cares about Mac software? >>> >>>Adam >>> >>>disclaimer: MIT lets me use their equipment because I pay them >>>$12,500 a year. >> Well, Adam, eventually you'll make it out into the real world >>and discover that there are several million people who want a system >>that's easy to use, presents a consistent user interface and does >>what Mac software does and Unix doesn't. Unix is wonderful for >>universities, some businesses and maybe even workstations, but it's >>just too big and too complex for 95% of the worlds population. > >Don't patronize me. I have my opinions and I enjoy discussing them. >Your comment precludes any discussion between us; you imply my >opinions have no value because I am a student. If I agreed with you >you would not make the same comment. And why do you assume I have >no real world experience? Have you never heard of people working for >a few years before returning to college to complete their degree? I apologize for being patronizing. The simple fact of the matter is that the ideal situation one has the freedom to explore in a college and the situation one finds when dealing with most users are quite different. Your arguments that "I don't have any any macintosh software therefore macintosh software doesn't matter" indicates that you choose to deny a reality Apple and the rest of the microcomputer industry has to deal with. Apple has to support a very large number of people who want to continue to use that software, and/or find that that software meets their needs in a reasonable, cost efficient, timely manner and is also easy to learn to use. Most users don't care about preemptive vs. nonpreemptive multitasking and in fact don't know what either is. They simply want to get work done. I claim that MultiFinder is a very viable and effective solution to the real world problem of providing real users with a multitasking system which solves the problems they need to have solved. That it may not solve your particular problems is unfortunate. I'm not convinced that it doesn't or in the future won't, but you are obviously free to whatever opinion you wish. Personally, I find that it currently meets 95% of my needs. I know of no other system which better meets my needs. The Amiga doesn't have the applications. Unix and it's attendant windowing systems don't have the applications. There are some things that I as a computer professional would like it to do that it currently doesn't. I do, however, get much more done with it than with unehanced the Macintosh OS. > >Nor do I understand your comments about Unix. I never claimed Unix >was the world's salvation. I never mentioned Unix at all. Well, in this forum it is reasonable to assume that multitasking windowing systems refers to one of: Amiga Unix w/X, NeWS, SunView Macintosh w/MultiFinder Those being the three that are commonly and readily available today. Oops, I suppose VMS with X should be added to that list. Since you were discrediting MultiFinder I assumed you were declaring a preference for Unix. > >I acknowledge the reality of several million Mac users (my last >posting). But you still have not addressed my main point: > >As a tool for switching between tasks, MultiFinder has absolutely no >advantage over multitasking. And at least one disadvantage (which you >have granted me). Nope, I've repeatedly pointed out a couple of advantages of MultiFinder over other multitasking systems which you've dismissed without really discounting. 1. MultiFinder provides multitasking services to an existing windowing system which has proven easy to learn and use. 2. MultiFinder allows millions of people to continue using there existing software, most of it with no changes and still have all the advantages of multitasking. -- David W. Berry dwb@Delphi dwb@apple.com 973-5168@408.MaBell Disclaimer: Apple doesn't even know I have an opinion and certainly wouldn't want if they did.
chekmate@athena.mit.edu (Adam Kao) (03/15/88)
In article <3255@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: >BSD without TCP/IP and sockets would still be multitasking, yes? Oh boy. You just left me in the dust. I confess, I'm not a Unix wizard. Please explain? It was very difficult for me to understand this posting. Forgive me if I err, but let me summarize what I got out of it: Robert Reed defines a preemptive multitasking system as one in which tasks are switched automatically after a fixed time. If I have this right, this is also called time-slice multitasking, isn't it? In this case a non-preemptive multitasking system would be one in which the passage of time does not force tasks to switch; instead some other mechanism is used, like the tasks themselves explicitly giving up control. In all other respects preemptive and non-preemptive multitasking would be identical. Mr. Reed continues with several examples of systems that would be difficult to classify using my definition. Please bear with me as I examine Mr. Reed's definition of non-preemptive multitasking (NPM) in light of my definition of multitasking. Let me assume we have an NPM system where tasks switch only when they give up control, presumably by means of some Wait function. (I can't think of another kind of NPM system offhand.) (1) Can tasks run independently? I would say no, because every other task is _dependent_ on the current task calling Wait. If the current task never calls Wait, because of an infinite loop or some kind of crash, then no other task will ever get to run, am I right? (2) Can tasks communicate? The current task can certainly leave messages for other tasks. The other tasks won't be able to reply until the current task calls Wait, but I'll grant that this is communication. (3) Can tasks interrupt each other? Again, the current task could probably do something to make sure some other task doesn't get called again. I would hesitate to call this interrupting, but the real problem is that no other task can ever interrupt the current task. This is really the same problem as (1). Therefore, by my definition, this kind of NPM is not multitasking. Now I must inject some philosophy about Definitions. Definitions are constructs that people agree to use for communication. They ease discussion in that, when accepted, everybody has a better idea of what everyone else is talking about. If you accept my definition of multitasking, I think you cannot avoid concluding that the Mac with MultiFinder is not multitasking. Definitions can only be used by _consensus_. If you do not accept my definition of multitasking, there is nothing I can do. My argument about the Mac and MultiFinder becomes much more complicated. We can't argue ABOUT my definition; you either accept it or you don't. Definitions are _artificial_. Reality is infinitely complex, all things are related to all others, every rule has an exception. Every Definition we make must necessarily be a simplification. We think of Definitions as walls with which we categorize things, but there are always cases that sit on the fence. This does NOT make Definitions useless; we may not know where exactly the atmosphere stops and space begins, but you damn well better know the difference between standing on the Earth and standing on the Moon. Similarly, I don't see the Mac and MultiFinder as any kind of fuzzy case. > So there IS more >between heaven and earth than dreamt in your philosophy. I agree completely. Again, if I have misinterpreted Mr. Reed's posting in any way, I apologize, and hope I will be corrected very quickly. >-- >Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK Adam
rbl@nitrex.UUCP ( Dr. Robin Lake ) (03/15/88)
In article <241@eos.UUCP> lyman@eos.UUCP (Lyman Taylor) writes: >In article <1719@ssc-vax.UUCP> benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > > .... ( deleted comments Byron Han made about multifinder ) > > >>Still sounds awfully serial to me. What happens if you have two windows >>at the top (i do this on a sun, usually two editting sessions) maybe >>different editors side by side...? Your menu bar would be constantly >>changing as you go back and forth (cutting and pasting)... (all that >>wasted mouse travel time and a wasted mouse click ) >>I think context-sensitive menus make more sense (try SunView applications >>and see how well they work) :-) (Seriously, I think a menu bar starts >>making less sense in a multitasking environment were more than one >>application is running at a time in a number of different windows ) > > > > Unfortunately, us humans can only handle ONE high level cognitive task >at once. Therefore, we only need ONE menu at a time. Anything above that is >a nice HACK, but not all that useful for us mortals. Needless to say, it >ignores most of what about Human Computer Interaction. > > ... edited for brevity ... > Think about it. When have you ever seen anyone, including yourself, >doing two things at once ( like running a spredsheet and SIMULTANEOUSLY writing >something into your favorite editor ). I give you a hint most computers I seen >have ONE keyboard per user. This applies to general human behavior also. For >example, people can only handle one conversation at a time. Some people can >easily and rapidly " task switch " from conversation to conversation ( doing >something remarkably similiar to a multitasking operating system ) but they >cannot do it in parallel. > Just HAVE to reply to this one. I'm sitting at my workstation, using 3 keyboards and 3 CPUs --- just because they are not yet interconnected and some of the software won't ever port: - Color VAXstation 2000 running a vendor's modelling package (VMS) - A VT240 which can run a second model on the VAXstation, but is almost always used to run a word processing package on another VAX/VMS system. This is so I can maintain a running narrative of the modelling results. - A Macintosh running (one or more, depending on whether MultiFinder is in use or not): - Another, different modelling package - A HyperCard utility that does some routine calculations needed for the VAXstation modelling work - A VT240 terminal emulation to run models on the VAX when cheap hardcopy is needed - A VT100 emulation to read news on a UNIX system while the model(s) run. Would I like multiple windows and multitasking on a single machine? --- only if it's a MAC! Then it can run EVERYTHING via terminal emulators in one box ---- but there aren't enough serial ports on the Mac to do that! -- Rob Lake {decvax,ihnp4!cbosgd}!mandrill!nitrex!rbl
peter@nuchat.UUCP (Peter da Silva) (03/15/88)
In article ... tomwest@gpu.utcs.toronto.edu (Tom West) writes: > I am afraid that the advocates of multiple button mice have made a > beautiful theoretical case without looking at the reality of micro software. > Having used Macs, Amigas and STs (although mostly Macs), I have found that > in most software there is an *incredible* abuse of the general use rules for > mice. The second button gets used in all sorts of incredibly bizarre (and > completely un-intuitive) ways. I have complained to the owners of the > respective machines and met with loud protests of the fact that it is only > this piece of software and that the principal still holds true. OK. The *ST* doesn't specify what the second button is. It's not a menu button, it's an application specific button. Other than programs that were ports from the ST, and certain peices of PD junk, name one program that doesn't use the menu button on the Amiga as a menu button. And of course every program on the Mac keeps to the user interface guidelines. Interleaf is just one case and the principle still holds true, right? Oh, right, Hypercard is just one case and the principle still holds true. What, Hypercard is an Apple product? -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
dlw@hpsmtc1.HP.COM (David Williams) (03/16/88)
pete da Silva writes: >>...and it succeeds in making a 68020 feel like it's as slow as an 8088. Hmmm, I'm using a Mac II now and it does not feel that way to me or any of the other engineers in my lab who own Mac II's. In article <6895@drutx.ATT.COM>, clive@drutx.ATT.COM (Clive Steward) writes: > But think that some of the work$tation users who are in this discussion > are missing very important information. You can see everything at the same > time. Please try a Mac with Multifinder. >>I've tried it. Quickly, stop what you are doing and resize some window that's >>not part of the terminal program you're in. >>You click that window's sizing gadget, and wait about a second while >>Multifinder tells the program that you've activated its window, and it >>brings it to the front and repaints all the scroll bars and the title bar >>and everything. Even if that window was the active one, there can be up >>to half a second wait while the program gets around to realising that you >>clicked in its sizing gadget. If you move the mouse outsize that box while >>you're waiting it blows you off. *WoW* a whole second to 1/2 a second?? Gee I better go sell my mac and buy an amiga! :) Now if only their was some software for it! ;) uh oh this could start a religious war! It is hard for me to tell if it is even a full second for my II to context switch between typing in this window in NCSA telnet and say double clicking on a folder on the desktop. Sounds like another case of nanosecond madness to me. >>And it's even cheaper than the Mac. $1200 gets you a VERY full-featured color >>system. I won't pretend that the display is Sun or even Mac-II quality, but >>it's definitely in the Mac-plus range. Yes but then we were not discussing the Amiga, which still seems no closer to having any significant installed base, we are discussing the Macintosh. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% David L. Williams | HyperCard Jedi dlw@hpsmtc1.HP.COM | & ...!hplabs!hpda!dlw | Un*x Novice (X Windows here I come!) ______________________________________________________________________________ Hewlett Packard <- Nope, they're my opinions, not Hp's! Software Development Technology Laboratory DCE/User Interface Project Somewhere in Cupertino CA Mailstop: 47LR "What if...Apple put a SPARC on a Nubus card?" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
bobr@zeus.TEK.COM (Robert Reed) (03/16/88)
In <3760@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes:
...let me summarize what I got out of it:
Robert Reed defines a preemptive multitasking system as one in which
tasks are switched automatically after a fixed time.
Not quite. A preemptive multitasking system does not require time-slicing.
Preemption can also be implemented as a part of system I/O calls, as
exemplified in my last message.
Let me assume we have an NPM system where tasks switch only when they
give up control, presumably by means of some Wait function. (I can't
think of another kind of NPM system offhand.)
(1) Can tasks run independently? I would say no, because every other
task is _dependent_ on the current task calling Wait. If the current
task never calls Wait, because of an infinite loop or some kind of
crash, then no other task will ever get to run, am I right?
Task independence comes in many shades. You can write a preemptive
scheduler in which smaller tasks get a higher priority, and by varying the
parameters, effectively lock out larger tasks. Are the larger tasks then
dependent on the smaller ones? Well, in a sense, yes. Yet the tasks
themselves are independent of each other and we still have multitasking.
(2) Can tasks communicate? The current task can certainly leave
messages for other tasks. The other tasks won't be able to reply until
the current task calls Wait, but I'll grant that this is communication.
Again, interprocess communication is NOT a prerequisite for multitasking.
Consider a batch processing system which has a mix of jobs that can be run
in any order. No interprocess communications are required or even expected,
yet the system is truly multitasking, with distinct jobs running
simultaneously.
(3) Can tasks interrupt each other? Again, the current task could
probably do something to make sure some other task doesn't get called
again. I would hesitate to call this interrupting, but the real problem
is that no other task can ever interrupt the current task. This is
really the same problem as (1).
Task interruption is a subset of interprocess communication, and is not
required for a multitasking system. Yet a task interruption system can be
constructed, even using nonpreemptive scheduler, assuming well behaved
processes. It may not be very useful as a program development environment,
because of the issues you've raised. Still, that does not exclude it from
the domain of multitasking systems.
If you accept my definition of multitasking, I think you cannot avoid
concluding that the Mac with MultiFinder is not multitasking.
Definitions can only be used by consensus.
This is the crux of the issue. In your narrowed view of multitasking, IPC
requirements may exclude such systems as Multifinder. Yet, Multifinder fits
broader views of multitasking which rely only on the ability to share
resources among a set of simultaneously executing processes.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKhan@Apple.COM (Byron Han, fire fighter) (03/17/88)
In article <1174@cpocd2.UUCP>, howard@cpocd2.UUCP (Howard A. Landman) writes: > You can see the problem but still don't admit it's there? In real multitasking > NO SPECIAL CODING IS NEEDED. Most programs multitask AUTOMATICALLY without any > special attention from the programmer. > > Under MultiFinder, each program (except possibly the last one) must be > specially coded to be "MultiFinder compatible" by calling WaitNextEvent instead > of GetNextEvent (if I don't have them reversed). Why is this a problem? > Because it only takes one or two programs which fail to do this before > MultiFinder fails to grant any CPU time at all to the lowest priority task. > Why is this a problem? Because there are lots of Mac programs out there which > were written before MultiFinder and are still useful, but which will never be > changed. Companies go out of business. Shareware authors move on to more > lucrative pursuits. Etc. > Your posting is incorrect in stating that one needs to rewrite/recompile applications to be MultiFinder compatible. Having applications that call GetNextEvent instead of WaitNextEvent will not cause your machine to not give time to backround applications. Using WaitNextEvent is a little bit more efficient and gives a few more services (such as defining a sleep time and other such stuff) that GNE does not provide. However, using GNE will not result in an application that "hogs" the system. The important thing is to call GNE/WNE as often as possible - which is a good thing to do anyway to present a responsive human interface to the user. A note to all: please try to think about responses before posting them. There seems to be an excess of followups posted as knee-jerk reactions.
han@Apple.COM (Byron Han, fire fighter) (03/17/88)
Sorry - readnews left off my signature.
chekmate@athena.mit.edu (Adam Kao) (03/17/88)
David W. Berry writes: > Well, fortunately, the definiton of the Macintosh OS allows >such things as multitasking and other OS features to be cleanly and >simply integrated in later. This is not true. Multitasking is one of the most fundamental aspects of an OS, affecting things like memory management, interrupt handling, and data storage. You can't even BEGIN to write an OS until you decide how to address these issues. When you write a single-tasking OS, you're dealing with different questions, and your answers will not be appropriate to a multitasking environment. What happens when two tasks demand access to the same memory location, the same interrupt, the same file? These aren't problems you can fix by twiddling a data field or even replacing a module. Your decisions on issues like these _define_ your OS. A different decision demands a different OS. >>> All other things equal, which they basically are, >> ^^^^^^^^^^^^^^^^^^ >>>consistency makes the Macintosh interface and MultiFinder simpler to >>>learn and use than X, NeWS, or SunView. >> >>I really can't let this go by. Would you mind supporting that statement? > Well, MultiFinder provides multitasking. It allows 95% of all >users to do all the things one expects of a multitasking system. That >seems pretty equal to me. Quick answer: 95% ~= 100% (I'm a math major, you know. :-)) Long answer: What are you claiming is equal here? This workstation I'm using has more pixels, a bigger screen, more RAM, more ROM, more speed, NFS, BSD 4.3, Emacs, INGRES, MACSYMA, Xtrek, Xconq, and a God-knows-how-many-thousands-of-dollars-a-year service contract with DEC. In other words: What are these "things???" > Your arguments that "I don't have any >any macintosh software therefore macintosh software doesn't matter" >indicates that you choose to deny a reality Apple and the rest of >the microcomputer industry has to deal with. This really wasn't intended to be one of my arguments. It was a joke. You know, :-) :-) <-- these are smiley faces :-) Seriously, there are lots of real world variables I've been ignoring, because I wanted to keep the discussion tightly focused. Software isn't the only variable I've been ignoring. How about price? Speed? Expandability? Software philosophy? (Mac software patronizes me. I HATE BEING PATRONIZED!!!) You see, there are a lot of REASONS why I don't own any Mac software, and they're just outside the scope of this discussion. > Since you >were discrediting MultiFinder I assumed you were declaring a preference >for Unix. Please, I'm not trying to discredit anything, or declare a preference for anything. If you must know, I think Unix is too hard to use, the Mac doesn't have enough power, and the Amiga doesn't have enough software. (Oh god, now I'm gonna get flamed by EVERYBODY.) All I really wanted to say is: >>> MultiFinder is not multitasking. <<< I'm not judging Apple's decision to create it, I'm not judging your decision to buy it. I'm clarifying a definition. >>As a tool for switching between tasks, MultiFinder has absolutely no >>advantage over multitasking. : > 1. MultiFinder provides multitasking services to an existing >windowing system which has proven easy to learn and use. > 2. MultiFinder allows millions of people to continue using >there existing software, most of it with no changes and still have >all the advantages of multitasking. Your two points are really only one. And I was very careful in phrasing my point: "As a tool for switching between tasks . . ." Not "As a tool for switching between Mac programs . . ." Please note the latter point is what you're arguing, and the latter point is too limited for my interest. Maybe if I wanted to discuss Switcher vs. MultiFinder. Nevertheless, there is nothing inherent in my definition of multitasking that says it can't run Mac programs. You would need to write such an OS from scratch, but when done, such an OS would be faster, cleaner, more powerful -- more ELEGANT than Mac with MultiFinder. Yes yes, such an OS does not exist yet. I admit that's a problem. But I really don't want to discuss Mac specific OS's. And about this definition debate - please see my replies to Robert Reed. >-- >David W. Berry >dwb@Delphi dwb@apple.com 973-5168@408.MaBell >Disclaimer: Apple doesn't even know I have an opinion and certainly > wouldn't want if they did. Thank you for the apology. I overreacted. Adam
chekmate@athena.mit.edu (Adam Kao) (03/17/88)
In article <3268@zeus.TEK.COM> bobr@zeus.UUCP (Robert Reed) writes: > > Definitions can only be used by consensus. > >This is the crux of the issue. In your narrowed view of multitasking, IPC >requirements may exclude such systems as Multifinder. Yet, Multifinder fits >broader views of multitasking which rely only on the ability to share >resources among a set of simultaneously executing processes. >-- >Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK Again, I don't want to discuss my definition of multitasking, this is too much like angels on a pin. I said "Your definition of NPM is not multitasking according to my definition," and you replied "Here is another system that is multitasking that doesn't satisfy your definition." But this is not a discussion, this is a failure to agree on terms. I have been very careful in defining what I mean when I say "multitasking;" you and David W. Berry have not made explicit statements but you are obviously using a different definition. Therefore I cannot use the term "multitasking" and expect you to understand what I mean. So from now on I will not use the term "multitasking." Similarly, since I do not accept your definition of "multitasking," you cannot expect me to understand your use of the term. In particular, please stop saying "MultiFinder is multitasking," because this statement doesn't tell me anything. Let me restate my argument without using, um, that word. I list here three properties that an OS may or may not have: (1) Tasks can run independently. (2) Tasks can communicate with each other. (3) Tasks can interrupt each other. If an OS has all three of these properties, we shall say that it is P (P for property). In particular, we shall refer to the individual properties as p1, p2, and p3, respectively. First, I claim an OS that is P has many significant advantages over one that is not P. p1 makes an OS better for a human being; he can switch his attention between tasks without having to wait for any particular task to complete. p2 makes an OS better for a programmer; he can take full advantage of techniques like modularity and object-oriented programming, writing less redundant code and more flexible programs. p3 insures no task will "run away with the system." I hope we do not need to discuss this claim. Second, I claim that the Mac with MultiFinder is not P. It does not have p1. because of the need for Wait. I do not know if it has p2. It does not have p3, because the current task is perfectly capable of never relinquishing control. Therefore, an OS that is P has many significant advantages over the Mac with MultiFinder. I also claim that an OS that is not P does not automatically gain any significant advantage _by_not_being_P. Therefore, the Mac with MultiFinder does not automatically have any advantage over an OS that is P. The Mac with Multifinder runs Mac software (mostly) but there is no reason our hypothetical OS cannot run Mac software either. Therefore, given a choice between an OS that is P and a Mac with MultiFinder, I will prefer the OS that is P. In fact, given my personal situation, I won't even require the OS that is P to run Mac software. Your mileage may vary. In followups, if you need some way to refer to your definition of, uh, you know, may I suggest the term NPM. Since this term is not in the OED, may I also suggest you define it (or whatever term you settle on) before you use it. Adam "Comp.windows.misc??? What the hell am I doing in comp.windows.misc? Last thing I remember, I was reading rec.humor . . ."
lsr@Apple.COM (Larry Rosenstein) (03/18/88)
In article <1174@cpocd2.UUCP>, howard@cpocd2.UUCP (Howard A. Landman) writes: > > Under MultiFinder, each program (except possibly the last one) must be >specially coded to be "MultiFinder compatible" by calling WaitNextEvent >instead of GetNextEvent (if I don't have them reversed). Not true. WaitNextEvent exists only to more effectively use the CPU. GetNextEvent can cause a context switch as well. >problem? Because it only takes one or two programs which fail to do this >before MultiFinder fails to grant any CPU time at all to the lowest >priority task. Why is this a problem? Because there are lots of Mac >programs out there which were written before MultiFinder and are still Your arguments are valid in general, but the particular case you site does not occur. 99% of Macintosh application call GetNextEvent regularly, and such applications work fine in the MultiFinder environment. If an application is computing some result, then it might not be calling GetNextEvent. But some applications do call it while computing (in order to test for a cancel request), and these application will yield the CPU to lower priority tasks. > This was too restrictive, so MultiFinder was invented AS A KLUDGE to allow > background tasks to run IF THEY WERE SPECIALLY CODED. But not everything is, > or ever will be. This is not strictly necessary. A background task does not need to call WaitNextEvent. There are some (pre-MultiFinder) public domain programs that run fine in the background. These are the programs that call GetNextEvent while doing some computation. It turns out that the logical way to allow the user to cancel a long computation involves calling GetNextEvent, and such programs will run in the background very nicely. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 32E Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
stpeters@dawn.steinmetz (Dick St.Peters) (03/18/88)
In article <7593@apple.Apple.Com> dwb@Apple.COM (David W. Berry) writes: > If you're going to berate things, make sure you've at least >seen them and/or researched them thoroughly, even if you have to live >with a one-book-at-a-time restriction. And if you're going to chastise someone publicly for something said, make sure the person you chastise is the one who said it. I never said a damn thing, good or bad, about menu bars or any other aspect of the Mac. I did defend multi-tasking when someone challenged its value. -- Dick St.Peters GE Corporate R&D, Schenectady, NY stpeters@ge-crd.arpa uunet!steinmetz!stpeters
clive@drutx.ATT.COM (Clive Steward) (03/18/88)
From article <1174@cpocd2.UUCP>, by howard@cpocd2.UUCP (Howard A. Landman): > You can see the problem but still don't admit it's there? In real multitasking > NO SPECIAL CODING IS NEEDED. Most programs multitask AUTOMATICALLY without any > special attention from the programmer. Howard. In any Mac program, GetNextEvent () _is_always_called at the appropriate interval. Since the beginning of Mac history, and presumably forevermore. In your own words, "NO SPECIAL CODING IS NEEDED. Most programs multitask AUTOMATICALLY without any...". The sole exceptions are non-user programs which take over the machine, such as memory testers or other diagnostic tools. Same for any Unix box. The other call, WaitNextEvent (), is simply available to allow a process to give up more than its 'fair share' of opportunities to run. The people who designed this did their homework ever so much more carefully than many who criticize them have guessed. Clive Steward
goldman@Apple.COM (Phil Goldman) (03/18/88)
In article <1174@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >Under MultiFinder, each program (except possibly the last one) must be >specially coded to be "MultiFinder compatible" by calling WaitNextEvent instead >of GetNextEvent (if I don't have them reversed). No. MultiFinder works just fine with existing apps. Using _WaitNetxEvent is just optimization, just like using sleep() in Unix. >tricky. The main problem with any multitasking is handling conflicts when >more than one program wants to use a limited resource, such as a printer port. >What makes this more difficult on a Mac is that THE SCREEN IS A LIMITED >RESOURCE which has to be carefully managed, and almost every program wants the >screen to itself while it's running. > No, almost every program does *not* want the screen to itself while it's running. Applications are very good about only drawing in windows, so it is fairly simple to extend the windows metaphor to layers. >The original Mac solution to this was not to multitask. > >This was too restrictive, so Switcher was invented AS A KLUDGE to allow some >of the benefits of multitasking. But still nothing could run in the >background. > >This was too restrictive, so MultiFinder was invented AS A KLUDGE to allow >background tasks to run IF THEY WERE SPECIALLY CODED. But not everything is, >or ever will be. > No. The only reason that it was decided to force applications to notify the OS that they needed bg time was that most Mac applications don't have anything useful to do in the background, so they are wasting time. Again, this is simply an optimization, NOT A KLUDGE. It would have been possible to allow them all to run in the background, but wasteful. Also, NO SPECIAL CODING is required to run in the background. The SIZE resource has a "canBackground" bit, which can be changed by anyone, not just the application's developer. If you have an app you wish to run in the background, just set the bit. It will require ResEdit, but if you are an active user of shareware and public domain programs that might never be revved, then odds are you have a copy of ResEdit too. >This is too restrictive, so Apple will eventually be forced to actually solve >the problem, possibly by melding some feature of AUX into the Mac OS. Probably the other way around. As A/UX handles more and more of the Mac interface, it will have to deal with these same problems, and it will probably include the same optimizations to increase performance and response time, to provide the Mac "look and feel." -Phil Goldman Apple Computer
mcdonald@uxe.cso.uiuc.edu (03/18/88)
>I also claim that an OS that is not multitasking does not automatically gain > any significant advantage _by_not_being_multitasking. In that I think you are seriously wrong. It gains freedom by not having the OVERHEAD of a multitasking monitor. One does not have to worry about interfearing with another task. There is no need for code to PREVENT interfearance. Just compare the ease of writing full-function programs (defined as one that makes full use of the machine, using all its resources, including the screen) for MS-DOS compared to Unix (as a particularly strong example). I STILL have not heard of ANY full-function program running on an IBM-PC using a UNIX variant (in this case, by full-function I mean using all the bells and whistles of an EGA or VGA screen. Most arcade-style games are examples of full-function programs.) The defination of all the "windowing" systems I have seen prevent using full functionality. (Even on high-end graphics workstations, e.g. a top-of-the-line Silicon Graphics, different windows interfere with one another at the color map level.)
mls@whutt.UUCP (SIEMON) (03/19/88)
In article <6986@drutx.ATT.COM>, clive@drutx.ATT.COM (Clive Steward) writes: > > In any Mac program, GetNextEvent () _is_always_called at the appropriate > interval. Since the beginning of Mac history, and presumably forevermore. > > In your own words, "NO SPECIAL CODING IS NEEDED. Most programs multitask > AUTOMATICALLY without any...". Much of this argumentation on either side is truly futile. Valid points get made on both sides and are lost in a sea of invective. Multi-finder is a pretty good job of what it is trying to do -- including compatibility with Switcher so that there ARE existing programs that can gracefully cooperate for effective end-user multitasking. Good job, Apple. BUT I can almost never use Multi-finder (on a 2 Meg MacII) because the stuff I have tends to be either stupid or memory hogs. I like having desk accessories stick around, but then I find that they are almost always buried underneath the active window, when I'd really just like to tuck them away (ON TOP) in a corner of what I'm working on. If I have to unbury them to use, I might as well just go up to the Apple menu in the first place. More seriously, in program development, one is constantly coping with partly debugged programs that are NOT well behaved -- it is of little use to have a nicely coded GetNextEvent() loop when you go off into an infinte loop else- where! The point of the "no special coding needed" thing is: even when a program FAILS to cooperate (for whatever reason!), the system still permits the other tasks to go ahead. On the Mac, non-cooperation is mostly a problem for developers, so Apple is on very good ground in providing a non-preemptive environment _as a first step_ towards the ultimate MAC/OS (after all, we all know that no REAL application has bugs). Most seriously, the whole Mac model of computing is so insistently interactive that there isn't a hell of a lot of need for preemption -- the usual sorts of "multitasking" that people want are background printing, downloading etc. There WILL, on a Mac, usually be one highly interactive foreground task that can gracefully pass its unused cycles on to your super-duper Mandelbrot set generator chugging away beneath. By the way, if you didn't notice, this is a complaint -- I dislike programs that I HAVE to interact with. One of the beauties of UNIX is that programs can be QUIET and not flood you with inane chatter ("Do you really want me to do this? Huh? Really, really? And how about this next one too? Oh, really? And this one?") What Apple needs is a good dose of regular expressions. Michael L. Siemon contracted to AT&T Bell Laboratories ihnp4!mhxux!mls standard disclaimer
peter@nuchat.UUCP (Peter da Silva) (03/19/88)
In article <1248@iscuva.ISCS.COM>, jimc@iscuva.ISCS.COM (Jim Cathey) writes: > In article <1551@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >[Amiga]...it's still better than the Mac menu bar because you don't have to > >give up screen real-estate for a menu bar that's usually not needed. > Of course, the few programs I've seen leave the menu bar there, but with a > program name or copyright message in it until you hit the menu button. To > me, this is an even more sinful waste of screen space than menus are supposed > to be! (And on a machine that was short-changed on vertical pixel count > to boot.) Counterexample: Shanghai (The menu bar overlays part of the game) Counterexample: Tracers (The meny bar overlays part of the game) Counterexample: A couple of PD terminal programs I use (the menu bar overlays the top line of text) Counterexample: The workbench (windows can overlay the title bar, no problem) It's convenient to leave the drag bar for the window visible (that's what you mean by the menu bar with the title in it, nicht war?), but it doesn't take up space or keep you from overlaying it with windows. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
peter@nuchat.UUCP (Peter da Silva) (03/20/88)
In article ... dlw@hpsmtc1.HP.COM (David Williams) writes: > Peter da Silva writes: > >>...and it succeeds in making a 68020 feel like it's as slow as an 8088. > Hmmm, I'm using a Mac II now and it does not feel that way to me or any of > the other engineers in my lab who own Mac II's. Perhaps I'm misled by my expectations of how quickly a 68020 can respond to real-time events. It certainly doesn't feel any faster than Microsoft Windows when it comes to general user-interface stuff (yes, it's faster so long as you're sticking within a single application). If Microsoft can do such a good job on a crummy 8088, surely Apple can do better on a 68020. > *WoW* a whole second to 1/2 a second?? Gee I better go sell my mac and buy an > amiga! :) Now if only their was some software for it! ;) uh oh this could > start a religious war! It is hard for me to tell if it is even a full second > for my II to context switch between typing in this window in NCSA telnet and > say double clicking on a folder on the desktop. Sounds like another case of > nanosecond madness to me. I don't know what shape you're in, but like most people I have about a .2 second minimal reaction time. I can sequence events even faster than that for a reflex arc. A whole second is really quite a long time. Imagine how fast you'd type if the computer could only accept one character a second. > Yes but then we were not discussing the Amiga, which still seems no closer to > having any significant installed base, we are discussing the Macintosh. (checks header of article) Hmmm... comp.windows.misc. This place is for comparison of windowing systems on many machines, right? And a 600,000 installed base isn't too bad, when you consider that it was 150,000 less than a year ago. And even that 150,000 wasn't too bad for a product sold with no advertising. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
mckenzie@husc2.UUCP (mckenzie) (03/20/88)
In article <3691@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes: >As a tool for switching between tasks, MultiFinder has absolutely no >advantage over multitasking... Just couldn't let this one go by... As Mr. Berry pointed out, 'multitasking' is not a tool at all - it's an "operating system concept"; as it stands, the sentence quoted above is completely nonsensical. The most basic level of multitasking (as one might guess from the name), is the ability to run two or more tasks concurrently. MultiFinder is a program which implements this level of multitasking, and from my (admittedly limited) experience with other multitasking systems, it does so smoothly and conveniently while retaining compatibility with a very large body of pre- existing software. Sure, pre-emptive multitasking is nice to have, but very few Macs are used for the same kinds of tasks as your typical UN*X box - the Mac is a single-user machine, and in the Mac context multitasking is most useful for: a) switching the user focus quickly between various programs (not really multitasking at all, but closely related), and b) relegating long unattended tasks to the background - neither of which requires pre-emptive multitasking. MultiFinder does a) very well, and can handle b) with friendly applications. MultiFinder doesn't pretend to be the fanciest multitasking software in the world, but it makes the Mac a whole lot nicer to use than it was six months ago. David McKenzie mckenzie@husc2.UUCP
chow@batcomputer.tn.cornell.edu (Christopher Chow) (03/21/88)
In article <6986@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes: | |In any Mac program, GetNextEvent () _is_always_called at the appropriate |interval. Since the beginning of Mac history, and presumably forevermore. | |In your own words, "NO SPECIAL CODING IS NEEDED. Most programs multitask |AUTOMATICALLY without any...". | |The sole exceptions are non-user programs which take over the machine, such as |memory testers or other diagnostic tools. Same for any Unix box. | This is not necessarily true. In any properly written Mac program GetNextEvent() or WaitNextEven() is always called each time through the main event loop. But what determines how often the main even loop gets executed? Sometimes you run tasks which are somewhat time critical. Take for example, downloading in the background under VersaTerm. If I try to unstuff a large StuffIt file, then StuffIt happily crunch away at its unstuff routine until the large file is processed. In the meantime, since MultiFinder is non-preemptive, StuffIt holds control for the entire duration it takes to process the archive file. Unfortuantely, the downloading protocols have time out period, and if the stuffit archive file is large enough then my downloading session will terminate. Without preemptive multitasking and scheduling priorities, its impossible to guarentee that my downloading session will not terminate due to time out errors. I suppose that something like StuffIt can be rewritten to call Get{Wait}NextEvent within the procedure which unstuffs a file, but then we'll be violating the "no special coding necessary" rule. Another problem with MultiFinder is that certain simple activity can interrrupt the entire system. For example, say you were downloading with VersaTerm in the background, and doing a few things in another layer. At present, its possible to bring background downloading to a complete halt by pressing the mouse down over a menu/menubar and just hold it there. So now I have to worry about how long I take to scan the menus of a new application that I just downloaded if I'm downloading another one in the background. Somehow, this dosen't seem right... Christopher Chow /---------------------------------------------------------------------------\ | Internet: chow@tcgould.tn.cornell.edu (128.84.248.35 or 128.84.253.35) | | Usenet: ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow | | Bitnet: chow@crnlthry.bitnet | | Phone: 1-607-253-6699 Address: 7122 N. Campus 7, Ithaca, NY 14853 | | Delphi: chow2 PAN: chow | \---------------------------------------------------------------------------/
bobr@zeus.TEK.COM (Robert Reed) (03/22/88)
In <3834@bloom-beacon.MIT.EDU> chekmate@athena.mit.edu (Adam Kao) writes:
...I don't want to discuss my definition of multitasking, this is too much
like angels on a pin.
I came into this discussion because of your comments that multitasking is
better than Multifinder because multitasking is [blah blah blah] and
Multifinder isn't. Since you've excluded my arguments by defining them out
of your existence, and because I don't know the specifics of Multifinder,
having never used it, I will probably drop out of this discussion.
In particular, please stop saying "MultiFinder is multitasking," because
this statement doesn't tell me anything.
Easily done. I never said it was.
--
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEKpeter@sugar.UUCP (Peter da Silva) (03/26/88)
In article <68600002@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > Just compare the ease of writing full-function programs > (defined as one that makes full use of the machine, using all its resources, > including the screen) for MS-DOS compared to Unix (as a particularly > strong example). Just compare the difficulty of writing efficient, well behaved, programs on MS-DOS as opposed to UNIX. "vi" might not be a full-function editor by your standards, but it does have the rather significant advantage of being fully usable over a serial link. EVen a low-speed dial-up line. The point is that "full-function programs" defined the way you just defined them are not desirable, let alone necessary. I have no problem running games at full bore on my Amiga without interfering with the multitasking. > The defination of all the "windowing" systems I have seen prevent using > full functionality. (Even on high-end graphics workstations, e.g. a > top-of-the-line Silicon Graphics, different windows interfere with one > another at the color map level.) On AmigaDOS you can open as many "screens" at once as you like. Each screen has its own independant bitmap, display modes, and color map. You access screens by dragging the screen in front down as if it was just a big window, or using front/back gadgets to reorder them. [ I'm not saying the Amiga is the be-all and end-all of windowing machines, just that it makes a nice counterexample for people who claim that you can't get real-time response from a multitasking system. A thesis can be disproved by one counterexample. ] -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (03/26/88)
In article <6986@drutx.ATT.COM>, clive@drutx.ATT.COM (Clive Steward) writes: > Howard. > In any Mac program, GetNextEvent () _is_always_called at the appropriate > interval. Since the beginning of Mac history, and presumably forevermore. > In your own words, "NO SPECIAL CODING IS NEEDED. Most programs multitask > AUTOMATICALLY without any...". Clive. What you mean to say is "NO EXTRA SPECIAL CODING IS NEEDED, because most programs have been twisted to fit the Apple GetNextEvent loop, whether or not it's appropriate for the application". Why should such inherently batch programs as compilers or ray tracers have to stop work periodically (and pretty frequently) to check on the user? In real operating systems, Batch programs get along well with Event Loop programs and Multi Threaded programs and whatever other sort of programs you like. > The sole exceptions are non-user programs which take over the machine, such as > memory testers or other diagnostic tools. Same for any Unix box. What, you mean to say that 'cc' and 'as' check for mouse activity? I'd be real surprised to find that... I didn't think they had mice on the PDP-11. > The people who designed this did their homework ever so much more > carefully than many who criticize them have guessed. Given the braindamaged "operating system" they had to start with, I'd say they did an excellent job. Not as good as Microsoft did getting the poor old 8088 to challenge Apple's hotshot 68020 :->, but better than most. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
gilbert@hci.hw.ac.uk (Gilbert Cockton) (03/29/88)
In article <1514@devvax.JPL.NASA.GOV> des@jplpro.JPL.NASA.GOV (David Smyth) writes: > >top-of-screen menu bar is "modal" and modality is really evil and >confusing. One of Xerox's design tenets for good human interfaces >is "No modes!" and a good tenet it is. Larry Tesler should have kept his tee-shirt to himself!!!!!!!!!! Modelessness falls apart under a moment of examination. A problem with HCI is the search for `no-brainer' guidelines which are short, simple and easy-to-learn, .... but impossible to use. Any usable system is going to be moded, as the bandwidth of the input channel is invariably inadequate for the specification of many discrete pieces of input information. Read journals like IJMMS for more thoughtful approaches to modality. The Mac will ALWAYS be moded as long as applications are written in PASCAL or C without signals/threads. This is why talking of modeless design is silly if the implementation abstractions enforce modedness. As for the evil and confusingness of modes, this is meaningless. It is impossible to define modedness well enough to allow experimental comparisons of moded and non-moded systems. The sentence is cute, but untestable ... one of Xerox's design tenets was "Evaluate alternatives" and a better tenet. Now when someone implements a truly modeless complex application, then we'll be able to make sensible comments by EVALUATING the true effects of increasing modedness on human performance when interacting with computers. P.S. Everyone at Xerox had their own pet tenets! :-) P.P.S. ... and so does everyone here. -- Gilbert Cockton, Scottish HCI Centre, Heriot-Watt University, Chambers St., Edinburgh, EH1 1HX. JANET: gilbert@uk.ac.hw.hci ARPA: gilbert%hci.hw.ac.uk@cs.ucl.ac.uk UUCP: ..{backbone}!mcvax!ukc!hci!gilbert
diamant@hpfclp.HP.COM (John Diamant) (04/02/88)
> It is impossible to define modedness well enough to allow experimental > comparisons of moded and non-moded systems. The sentence is cute, but > untestable ... one of Xerox's design tenets was "Evaluate alternatives" > and a better tenet. Now when someone implements a truly modeless > complex application, then we'll be able to make sensible comments > by EVALUATING the true effects of increasing modedness on human performance > when interacting with computers. > -- > Gilbert Cockton, Scottish HCI Centre, Heriot-Watt University, Chambers St., Not true. Emacs is a good example of a modeless editor (in contrast to vi). Now, I know you are immediately going to object (if you are familiar with emacs) that the language major modes and minor modes (like auto-fill) are really modes. Well, that's true, except that emacs is a very usable editor without any of these. You can consider the editor to be a Lisp editor, a Text editor and a C editor all in one, rather than a moded language-sensitive editor, and have a completely consistent view. You need never notice the modes if you use it on the same "language" (including text here as a language) in all cases. It's command model is based on the principle that all keys mean the same thing regardless of whether you are inserting text or not. Again, you may object that multi-keystroke sequences are modal, but they needn't be viewed that way. Unlike insert mode in vi, the "modes" of multi-keystroke sequences are only active for a single keystroke, and so never need to be internalized as a mode by the user. John Diamant SDE UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett-Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
jqj@uoregon.UUCP (JQ Johnson) (04/05/88)
>Emacs is a good example of a modeless editor
This is true only to a first approximation. For example, the keystrokes
allowed after one has typed M-x and before one has typed RETURN have
different effects than the same keystrokes typed elsewhere. Phrased
differently, there is a distinguished window for commands, just as
in vi. At least in gnu emacs (though not in several other variants
of emacs) one can treat the M-x command line *mostly* like another
buffer...
The point here is that "modeless" is not well defined. Followups to
some other newsgroup.gilbert@cs.glasgow.ac.uk (Gilbert Cockton) (04/26/88)
In article <10700002@hpfclp.HP.COM> diamant@hpfclp.HP.COM (John Diamant) writes: >You need never notice the modes if you use it on the same "language" (including >text here as a language) in all cases. > You need never use Emacs at all and then you also wouldn't see the modes! All these ifs and buts, the whole point about modelessness is that it vanishes into a list of exceptions. > >Again, you may object that multi-keystroke sequences are modal, but they >needn't be viewed that way. Sorry, but to defend my argument, I really really do have to view things that way. My apologies for being so slavishly tied to the semantics of the English language. Seriously, I tire of "you don't need to" style arguments. I have a lot of free will and don't need to do lots of things - like turn up for work - Ok so I wouldn't get paid and I'd :-) get the sack, but I really really don't NEED to do it unless I want :-) to not starve. Thus the consequences of not needing to see multi-keystroke :-) sequences as modal are that I end up using the English language with :-) the precision of some computer documentation writers. And of course, :-) they honestly truly don't NEED to go using English like that manner. :-) SUMMARY: Address the argument, not my personal malleability. INFO: What Emacs does is use "Command Heralds" - there are guidelines on the use of these going back to the 1970s. Used well (as emacs tends to), they won't cause too many problems. Triple-processed (e.g some nroff macro-buffers), they can be hell as mid-line characters turn into beginning of line heralds. > Unlike insert mode in vi, the "modes" of multi-keystroke sequences are only > active for a single keystroke, and so never need to be internalized as a mode > by the user. They are still modes, and some of them involve more than two key presses. You can delete things in command mode too. Fortunately, Emacs displays its command modes quite well, so if you answered the phone after the meta-key then came back, you could spot you were in command mode, unlike vi where you have to hit esc and see if the bell rings. It would be trivial to change vi so that its mode-state was visible (as it is in ex mode after ':'). Remember, I was objecting to the extreme and naive idea that modes are invariably evil and avoidable. My main argument is that it is impossible to come up with a modeless 'predicate' which can be applied to a user interface description. The whole concept is wooly.