cap+@cs.cmu.edu (Chris Paris) (10/29/90)
I find it interesting that in this group people almost universally prefer NeXTStep to X. I might share these sentiments except for one glaring omission in NeXTStep (or in my knowledge of it). That is, I have found no way to eliminate the requirement that I click in a window to move the keyboard focus to it. I find this extremely annoying, and actually prefer working in X over NeXTStep for this reason alone. If anyone knows a way to configure NeXTStep the way I like, I would greatly appreciate a response.
vesper@kong.gsfc.nasa.gov (Greg Vesper - RMS) (11/03/90)
In <1990Oct28.165341.6949@cs.cmu.edu> cap+@cs.cmu.edu (Chris Paris) writes: >I find it interesting that in this group people almost universally prefer >NeXTStep to X. I might share these sentiments except for one glaring >omission in NeXTStep (or in my knowledge of it). That is, I have found >no way to eliminate the requirement that I click in a window to move the >keyboard focus to it. I find this extremely annoying, and actually prefer >working in X over NeXTStep for this reason alone. If anyone knows a way >to configure NeXTStep the way I like, I would greatly appreciate a >response. I couldn't agree more. This is a matter of personal preference of course, but it would certainly be nice to have the option. Being able to configure your mouse buttons to taste would also be very handy.. Greg Vesper (vesper@kong.gsfc.nasa.gov) 301-286-5162 Goddard Space Flight Center; Greenbelt, Maryland "Two basic facts of life: 1) There is a God. 2) You're not him." -- Greg Vesper (vesper@kong.gsfc.nasa.gov) 301-286-5162 Goddard Space Flight Center; Greenbelt, Maryland "Two basic facts of life: 1) There is a God. 2) You're not him."
isbell@ucscf.UCSC.EDU (Art Isbell) (11/05/90)
In article <vesper.657582579@kong> vesper@kong.gsfc.nasa.gov (Greg Vesper - RMS) writes: >In <1990Oct28.165341.6949@cs.cmu.edu> cap+@cs.cmu.edu (Chris Paris) writes: > >>I find it interesting that in this group people almost universally prefer >>NeXTStep to X. I might share these sentiments except for one glaring >>omission in NeXTStep (or in my knowledge of it). That is, I have found >>no way to eliminate the requirement that I click in a window to move the >>keyboard focus to it. I find this extremely annoying, and actually prefer >>working in X over NeXTStep for this reason alone. If anyone knows a way >>to configure NeXTStep the way I like, I would greatly appreciate a >>response. > >I couldn't agree more. This is a matter of personal preference of >course, but it would certainly be nice to have the option. Being able >to configure your mouse buttons to taste would also be very handy.. > I, too, have found the Sun style of window activation handy, but I seem to remember NeXT expressing their GUI standard that *explicit* user input should be required before anything happens rather than the system making assumptions about the user's intentions. I believe NeXT's rather stringent guidelines are more positive than negative because a certain level of consistency results. As I look at my "desktop" now, moving from Stuart to Workspace would require passing over Writenow and Digital Librarian windows. Should these windows receive "activate" messages just because they happened to be in the path between Stuart and my intended destination, Workspace? I doubt anyone would think so. I guess this could be circumvented by requiring the mouse cursor to reside in a window for x seconds before activation starts, but I could see problems with this approach, also. How does Sun manage? I occasionally assume that because the cursor is in a window that the window is the active window, and it is annoying to type and have something unexpected happen in the actual active window, but I'm adjusting to the NeXT approach. As to being able to configure mouse buttons, do you mean something more than the configurations allowed in Preferences in which the "right" button can be activated to cause the active menu to pop up under the mouse cursor (a handy feature, especially if you move the default position of the main menu out of the way mostly below the lower edge of the screen) and "left" and "right" buttons can be interchanged to accommodate lefty users? -- _____ ____ Art Isbell |\ | | | | \ 315 Moon Meadow Lane NeXT Registered Developer | \ | ___ |____| | | Felton, CA isbell@ucscf.UCSC.EDU | \ | |___| | \ | | 95018-9442 (408)438-4736(B) | \| |___ | \ |___/ (408)335-1154(H)
bb@reef.cis.ufl.edu (Brian Bartholomew) (11/05/90)
In <1990Oct28.165341.6949@cs.cmu.edu> cap+@cs.cmu.edu (Chris Paris) writes: > That is, I have found no way to eliminate the requirement that I click > in a window to move the keyboard focus to it. I find this extremely > annoying, and actually prefer working in X over NeXTStep for this > reason alone. If anyone knows a way to configure NeXTStep the way I > like, I would greatly appreciate a response. In article <vesper.657582579@kong> vesper@kong.gsfc.nasa.gov (Greg Vesper - RMS) writes: > I couldn't agree more. This is a matter of personal preference of > course, but it would certainly be nice to have the option. Being able > to configure your mouse buttons to taste would also be very handy.. In article <8516@darkstar.ucsc.edu> isbell@ucscf.UCSC.EDU (Art Isbell) writes: > I, too, have found the Sun style of window activation handy, but I seem > to remember NeXT expressing their GUI standard that *explicit* user > input should be required before anything happens rather than the system > making assumptions about the user's intentions. I believe NeXT's > rather stringent guidelines are more positive than negative because a > certain level of consistency results. Let me add my voice to these, and say that I, too, hate click-to-type. However, adding an option to enable pointer focus would mess up the "menu always in the left corner" semantics. Keeping the menu for the current application always in view is a strong reminder to the user as to which operations are available for any given program. Always making the menu work in the same way, in the same place, is valuable from a consistancy viewpoint. I am not sure how pointer focus would work, given the way the current interface works. Comments? I think the issue of an app that is "not being used" getting a signal from a mouse moving across it is a red herring. Logically, all apps are multitasking, and so they are all asking for input at once; the idea of a focus is just a convention to switch your input between apps. I will say that my style of work (System Administration / Programming) fits the pointer focus model much better. Typically, I am trying to do 14 things at once, and I like to run a mouse around the screen and drop little tidbits of input into all the windows / processes / applications I am currently riding herd on. I truly do more than one thing at once, and a fast application context switch is the most important key to this. I also use and value a "front" key, that alternately does "bring to top" and "bury" on the window that the mouse is in, even if all I can find is a little corner to put my pointer in. The alternating behavior, i.e. "bury", lets me use it as a "dig" key when I lose a window under others. "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!mathlab.math.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!mathlab.math.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu
fox@allegra.att.com (David Fox) (11/05/90)
In article <8516@darkstar.ucsc.edu> isbell@ucscf.UCSC.EDU (Art Isbell) writes:
As I look at my "desktop" now, moving from Stuart to Workspace would require
passing over Writenow and Digital Librarian windows. Should these windows
receive "activate" messages just because they happened to be in the path
between Stuart and my intended destination, Workspace? I doubt anyone would
think so. I guess this could be circumvented by requiring the mouse cursor
to reside in a window for x seconds before activation starts, but I could
see problems with this approach, also. How does Sun manage? I occasionally
assume that because the cursor is in a window that the window is the active
window, and it is annoying to type and have something unexpected happen in
the actual active window, but I'm adjusting to the NeXT approach.
In a multi-tasking operating system there is no need to activate
and de-activate applications, only a need to be able to see which
application is currently receiving input. The requirement of click-
to-type is a vestige of non-multi-tasking operating systems like
MS-DOS and MacOS. Even the Amiga window system can be configured
so there is no need to click on applications to direct the input
stream to them. This is a very disturbing revelation for someone
like me who has been thinking of buying a NeXT machine.
David Fox
fox@allegra.att.comsmb3u@mendel.acc.Virginia.EDU (Steven M. Boker) (11/05/90)
There is a method to all of this madness. First of all have you guys from X land ever moved your cursor across a crowded screen when your ram was all occupied with high priority tasks? Thats why I end up setting click to type even in X. In NeXTStep there are several "layers" of windows that can be put up on the screen. If you have IB up and running as well as 5 editor windows and a couple of Stuart shells as I commonly do, things can get crowded. One of the ways that NeXTStep reduces the complexity of the screen is by only showing the panel layer of the currently activated application. If the panel layers were constantly being activated as the cursor moved from one window to another, your screen would be a truly ugly and confusing sight. What I recommend is that you try to separate the concepts of attention and intention. When your focus of intention is on a window, fire that finger. Its already on the mouse, poised over the button. I think that once you get over this initial pavlovian exercize, you will find that there is a reward for your new behavior pattern. Steve.
jmann@angmar.sw.stratus.com (Jim Mann) (11/05/90)
In article <FOX.90Nov5085517@papyrus.tempo.nj.att.com>, fox@allegra.att.com (David Fox) writes: |>In a multi-tasking operating system there is no need to activate |>and de-activate applications, only a need to be able to see which |>application is currently receiving input. The requirement of click- |>to-type is a vestige of non-multi-tasking operating systems like |>MS-DOS and MacOS. Even the Amiga window system can be configured |>so there is no need to click on applications to direct the input |>stream to them. This is a very disturbing revelation for someone |>like me who has been thinking of buying a NeXT machine. |> It is NOT just a vestige of non-multi-tasking systems. In saying this, you seem to be making the assumption that everyone would prefer the non-click-to-type method of activation. I disagree. I think most people, especially those NOT coming from a Sun environment, prefer the click-to-type scheme. Perhaps this is in part because it is what they are used to from Macs and PCs. One of the reasons I like my NeXT so much is that they DID build on reflexes many of us had developed from the micros we'd worked on: click to type, single click to select, double click to activate, drag over to select a region and so forth. I find Sun to be the odd machine out. Jim Mann Stratus Computer jim_mann@es.stratus.com
purtill@morley.rutgers.edu (Mark Purtill) (11/06/90)
jmann@angmar.sw.stratus.com (Jim Mann) writes: >It is NOT just a vestige of non-multi-tasking systems. In saying this, you >seem to be making the assumption that everyone would prefer the >non-click-to-type method of activation. I disagree. Irrelavent. This thread started with someone asking for the OPTION to not have to click to type. No one has suggested that everyone be forced to use non-click to type, and indeed X allows both click to type and not. And if you would find it horrible to have pointer-focus, that's exactly how I feel about click-to-type. Different people have different preferences, and NeXT won't make any sales by telling people that their preferences are wrong. NeXTStep should provide an OPTION for pointer focus, and, yes, this *is* a significnat factor in which machine I buy (Sparc vs. Next). ^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (201)932-4580 (O) ((")) P.O. Box 1179, Rutgers Univ., Piscataway, NJ 08855 (201)220-6905 (H)
fox@allegra.att.com (David Fox) (11/06/90)
In article <2955@lectroid.sw.stratus.com> jmann@angmar.sw.stratus.com (Jim Mann) writes: In article <FOX.90Nov5085517@papyrus.tempo.nj.att.com>, fox@allegra.att.com (David Fox) writes: |>... The requirement of click |>to-type is a vestige of non-multi-tasking operating systems like |>MS-DOS and MacOS... It is NOT just a vestige of non-multi-tasking systems. In saying this, you seem to be making the assumption that everyone would prefer the non-click-to-type method of activation. I disagree. I think most people, especially those NOT coming from a Sun environment, prefer the click-to-type scheme. Perhaps this is in part because it is what they are used to from Macs and PCs. One of the reasons I like my NeXT so much is that they DID build on reflexes many of us had developed from the micros we'd worked on: click to type, single click to select, double click to activate, drag over to select a region and so forth. I find Sun to be the odd machine out. The proper response to varying preferences is options. To provide the option of click-to-type is backward compatibility. To provide *only* click-to-type is a throwback. I'm glad the NeXT is compatible with your reflexes. For the sake of NeXT Inc. you should wish the same for the rest of us.
mdixon@parc.xerox.com (Mike Dixon) (11/06/90)
In a multi-tasking operating system there is no need to activate
and de-activate applications, only a need to be able to see which
application is currently receiving input. The requirement of click-
to-type is a vestige of non-multi-tasking operating systems like
MS-DOS and MacOS.
activating applications on the next isn't done for the OS's benefit
(of *course* it doesn't care). it's done for the user's benefit; the
activated application brings up its menus and auxilliary windows.
to get rid of the notion of activating an application you'd have to
have every application leave all its menus and auxilliary windows up
all the time. the next interface designers decided this made it
*harder* to manage multiple applications, not easier. if you're going
to argue with them, at least argue about the real issues.
--
.mike.peb@Autodesk.COM (Paul Baclaski) (11/06/90)
In article <FOX.90Nov5085517@papyrus.tempo.nj.att.com>, fox@allegra.att.com (David Fox) writes: > ... Even the Amiga window system can be configured > so there is no need to click on applications to direct the input > stream to them. This is a very disturbing revelation for someone > like me who has been thinking of buying a NeXT machine. Actually, on the Amiga, moonmouse (aka sunmouse) does not work perfectly because all it does is interpose a click whenever the mouse moves into a new window. This causes problems with editors that use the same mouse click to move the cursor, for instance, so you move the mouse back to the editor and the cursor jumps to a random spot. Click-to-type is the QWERTY of window systems. The worst case senario is when you use 2 machines, one at work with real estate mode (Gosling's term for non-click-to-type) and one at home with click-to-type: it causes many errors on both machines because you can easily forget what machine you are on. >From: jmann@angmar.sw.stratus.com (Jim Mann @ Stratus Computer, Inc.) >One of the reasons I like my NeXT so much is that they DID >build on reflexes many of us had developed from the micros we'd worked >on: click to type, single click to select, double click to activate, drag >over to select a region and so forth. I find Sun to be the odd machine out. Hey, what about us early users of window interfaces who have been using Suns for years (6 for me). We have reflexes too! >From: smb3u@mendel.acc.Virginia.EDU (Steven M. Boker @ University of Virginia) >There is a method to all of this madness. First of all have you guys from >X land ever moved your cursor across a crowded screen when your ram was all >occupied with high priority tasks? Thats why I end up setting click to type >even in X. Sun solved this problem by having a 200 millisecond no-motion filter on the mouse: your mouse must stop before the window is activated, so spurious activations do not occur. Sun supports click-to-type too, in sunview and xview, BTW. Paul E. Baclaski peb@autodesk.com
bourget@Neon.Stanford.EDU (Trevor G Bourget) (11/06/90)
It's true that having scads of windows pop up and go away just because you drag the mouse across their main window would be quite costly and rather annoying. But I don't understand why this behavior is considered synonymous with a non-click-to-type interface. The only change needed to implement this functionality, in my opinion, would be that, whenever a key is pressed, a makeKeyWindow message would be sent to the window under the mouse; if it doesn't become the key window, the input would just go to the existing key window. Given the typing speed of most folks, I don't think this would be considered an unacceptable resource consumption in order to obtain the user interface they desire. -- Trevor (bourget@neon.stanford.edu)
cerberus@caen.engin.umich.edu (R Eric Bennett) (11/06/90)
In article <1990Oct28.165341.6949@cs.cmu.edu> cap+@cs.cmu.edu (Chris Paris) writes: >I find it interesting that in this group people almost universally prefer >NeXTStep to X. I might share these sentiments except for one glaring >omission in NeXTStep (or in my knowledge of it). That is, I have found >no way to eliminate the requirement that I click in a window to move the >keyboard focus to it. I find this extremely annoying, and actually prefer >working in X over NeXTStep for this reason alone. If anyone knows a way >to configure NeXTStep the way I like, I would greatly appreciate a >response. It's funny to hear that someone actually LIKES move to focus. Sure its nice to be able to type blind every once in awhile, but more often than not it sends me clamoring to find out where I'd typed 'make' in my source code. I admit that I am not the greatest typist but when typing in a unix command I like to SEE what I am typing. I have also only used X on DEC 3000/5100 (?) but move to focus is REALLY annoying on them because you can only bring the window to the front by clicking on a button at the top of the window. I have wasted more time trying to move a window to the front than I have ever saved by being able to type without a window being key. It's also annoying to have a window come up and have your input redirected to that window just because it happened to come up underneath your mouse pointer. According to human factors work, you only waste .1 second clicking the mouse and since you have to move the mouse to activate another window anyway (~1.2 seconds) I think I'd rather have the whole thing take ~8% longer just to avoid the above headaches. Just one man's opinion, R Eric Bennett cerberus@caen.engin.umich.edu cerberus@itl.itd.umich.edu (NeXT mail)
ea08+@andrew.cmu.edu (Eric A. Anderson) (11/06/90)
Excerpts from netnews.comp.sys.next: 5-Nov-90 Re: NOT (click to type) in .. Mike Dixon@parc.xerox.co (896) > activating applications on the next isn't done for the OS's benefit > (of *course* it doesn't care). it's done for the user's benefit; the > activated application brings up its menus and auxilliary windows. > to get rid of the notion of activating an application you'd have to > have every application leave all its menus and auxilliary windows up > all the time. the next interface designers decided this made it > *harder* to manage multiple applications, not easier. if you're going > to argue with them, at least argue about the real issues. > -- > .mike. Not true, applications would just have to be written differently. Instead of having the menus in the upper left hand corner or wherever you have them, they could be attached to the top of each window. This is the solution taken by many X applications. Alternately you can have the menus pop up with a key held down ala xterm. I personally prefer this strategy, I like my menus to be close to the window I'm working in and having them right below the title bar or something like that is very convinient. I do agree though that it could look somewhat chaotic if as you moved across windows they had to activate and deactivate their menus. Perhaps they should build that in as an option -- menus across the top of windows and focus follows pointer. I don't think it can every be said that having more options ever hurt an Operating System. -Eric ********************************************************* "My life is full of additional complications spinning around until it makes my head snap off." -Unc. Known. "You are very smart, now shut up." -In "The Princess Bride" *********************************************************
dd26+@andrew.cmu.edu (Douglas F. DeJulio) (11/07/90)
purtill@morley.rutgers.edu (Mark Purtill) writes: > NeXTStep should provide an OPTION for pointer focus... I can't agree. One of the horrible things about X11 is that it is too customizable. This is bad for several reasons; it's particularly bad for support people.
anderson@sapir.cog.jhu.edu (Stephen R. Anderson) (11/07/90)
In article <QbBiMMm00VI8FQbSF0@andrew.cmu.edu> dd26+@andrew.cmu.edu (Douglas F. DeJulio) writes: > purtill@morley.rutgers.edu (Mark Purtill) writes: > > NeXTStep should provide an OPTION for pointer focus... > I can't agree. One of the horrible things about X11 is that it is too > customizable. This is bad for several reasons; it's particularly bad > for support people. Do user interfaces exist to serve the purposes of users or those of "support people"? Steve Anderson
scott@NIC.GAC.EDU (11/07/90)
Just to add my thought to the move-to-focus stuff: One summer, I worked with a NeXT cube and a VAXStation 3100 on my desk. The NeXT ran (what else?) NeXTStep, the VAXStation, DECWindows. I'd only used NeXT for 2 weeks before that, and Macs not at all. The NeXT at work did not show up for about a month, so I'd had more time on the VAXStation than on the NeXT when it showed up. I _hated_ the move to focus stuff. One area where there'd be problems on the NeXT is that, at least under the X I saw, the cursor was _always_ on-screen. This caused me no end of frustration, because you _always_ had to have that cursor within the window you wanted to type in, and it was without fail right where you were working. So you always had to move it a couple times when editting a large file. Under NeXTStep, the cursor can be told to go away until the user moves it. Now, beyond the fact that I probably could have configured X to do what I want (though I really don't know that), move-to-focus when you cannot see the cursor would probably be pretty fun to watch, though I'd not want to be the user in such an environment. The amount of time it'd take to figure out where the cursor is would be much larger than that to click that extra time to get stuff going. Another problem I almost always had was that I'd run the cursor over something, it'd come to the front, and cover the window I was aiming for. That, of course, is a usage factor, but after a month I still wasn't doing it correctly. If it takes 3 months to get up to speed . . . Besides, for a windowing system that seems to demand 3 mouse buttons, I really don't understand an aversion to clicking them . . . :-) scott hess scott@gac.edu Independent NeXT Developer (Stuart) GAC Undergrad (Horrid. Simply Horrid. I mean the work!) <I still speak for nobody>
korp@atlantis.ees.anl.gov (Peter Korp) (11/07/90)
Honestly.... Hasn't this issue been beaten to death yet? Lets agree that some people like click to type while others like follow the cursor! Now, have NeXT put the support for "pseudo" follow the cursor back into NeXTStep. It was there in 0.8 where by holding alt-cmd down and click would make a window input sensitive but leave it where it was in the tree hierarchy. Why did this disappear? Will it come back? Is the Black Hole really gone forever? Peter
morrison@cs.ubc.ca (Rick Morrison) (11/07/90)
I moved from an X-windows environment to NeXTStep about a year and a half ago.
I too initially despised click to type. By now, of course, I am quite used
to it, and actually appreciate its conservative behaviour from time to
time. The problem that I still have with the interface is the marriage of
click-in-window with bring-window-to-top-and-make-current. It should
be possible to make a window current without bringing it to top. I
am forever shifting windows around in order to view some small
fraction of the contents of each window concurrently.
-------------------------------
Rick Morrison | {alberta,uw-beaver,uunet}!ubc-cs!morrison
Dept. of Computer Science| morrison@cs.ubc.ca
Univ. of British Columbia| morrison%ubc.csnet@csnet-relay.arpa
Vancouver, B.C. V6T 1W5 | morrison@ubc.csnet (ubc-csgrads=137.82.8.20)
(604) 228-5010declan@remus.rutgers.edu (Declan McCullagh/LZ) (11/07/90)
In article <10357@ubc-cs.UUCP>, morrison@cs.ubc.ca (Rick Morrison) writes: > I moved from an X-windows environment to NeXTStep about a year and a half ago > I too initially despised click to type. By now, of course, I am quite used > to it, and actually appreciate its conservative behaviour from time to > time. The problem that I still have with the interface is the marriage of > click-in-window with bring-window-to-top-and-make-current. It should > be possible to make a window current without bringing it to top. I > am forever shifting windows around in order to view some small > fraction of the contents of each window concurrently. I'd like to allow one fact to enter this otherwise totally subjective discussion: NeXTstep v2.0 DOES allow you to view other windows by using Command-Up and Command-Down arrow. It does NOT make the other windows the key window, though - there was a WindowServer hack on the archive servers a few months ago that would allow you to bind keystrokes to applications and switch between them in that manner. -Declan -------------------------------------------------------------------- Declan McCullagh / NeXT Campus Consultant \ declan@remus.rutgers.edu --------------------------------------------------------------------
purtill@morley.rutgers.edu (Mark Purtill) (11/07/90)
dd26+@andrew.cmu.edu (Douglas F. DeJulio) writes: >purtill@morley.rutgers.edu (Mark Purtill) writes: >> NeXTStep should provide an OPTION for pointer focus... >I can't agree. One of the horrible things about X11 is that it is too >customizable. This is bad for several reasons; it's particularly bad >for support people. I thought a NeXT was supposed to me a machine to make users more productive, not support people happier. Being different from what I'm used to is *not* going to make me more productive. Forcing me to use a fixed interface that someone else likes but that I hate will not make me more productive. It may make me buy a Sparc instead of a NeXT though, and if enough people do likewise, there won't BE any NeXT support people. Besides, I don't really see how this would make life more difficult for support anyway, unless they want to sit down at my machine and type (and point), which is not likely anyway. What are the other "several" reasons? ^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (201)932-4580 (O) ((")) P.O. Box 1179, Rutgers Univ., Piscataway, NJ 08855 (201)220-6905 (H)
cortesi@informix.com (David Cortesi) (11/07/90)
In article <1990Nov6.075856.3596@engin.umich.edu> cerberus@caen.engin.umich.edu (R Eric Bennett) writes: >In article <1990Oct28.165341.6949@cs.cmu.edu> cap+@cs.cmu.edu (Chris Paris) writes: >>I find it interesting that in this group people almost universally prefer >>NeXTStep to X. > >It's funny to hear that someone actually LIKES move to focus. It's always funny (or interesting) to find out that other people's tastes are different than our own, isn't it? Now if we can just remember that that's normal, not evidence of moral turpitude or a congenital brain defect... My experiences are based on regular, repeated moves between SunView, Mac, and NextStep, with occasional forays into Motif. Every one of them cramps my style a different way. Here are three ways that NextStep definitely impedes my "power user" fingers: 1) No way to send a window to the back. If you completely cover a window, the only way to get at it is to iconize everything in front of it. Yes, I know about double-clicking the application's icon in the dock -- but some are not in the dock, the dock is not always visible, and besides, the things that most often are covered up are Stuart windows by other Stuart windows -- so clicking on the Stuart icon is no help. (and Stuart's "activate" menu contains 4 or 5 nearly-identical names) It wasn't until I'd used NextStep a while that I appreciated how often I had used SunView's "back" function. 2) No way to use a window without bringing it to the front. I found many good uses for the SunView ability to interact with a window that was partly obscured by other windows. Often you don't *need* to see a window in its full rectangularity; only one corner or the top or bottom edge. The good thing is not that you can type into a window by pointing at it; it's that you can type into a window without having to bring it to the front, covering up the window you are interested in. 3) Click-to-activate can cause scrolling: if you want only to activate a window, and only its left edge is showing, you will also cause a scroll action when you click on it. This is true of Edit and Stuart and probably others. Which means that bringing a mostly-covered window to the front can require very careful aim to hit just that tiny visible corner of the title bar or bottom frame. -- /////// / David Cortesi /////// cortesi@informix.com ////// ////// // // // //// / /// Informix Software // Tough times never last, //
purtill@morley.rutgers.edu (Mark Purtill) (11/07/90)
I'm beginning to wonder if NeXTStep isn't a total botch. First I hear that you're forced to have click-to-type, and everyone acts like I'm insane for prefering it, and then I read: morrison@cs.ubc.ca (Rick Morrison) writes: >The problem that I still have with the interface is the marriage of >click-in-window with bring-window-to-top-and-make-current. Do I read this right? The window you're typing in MUST be in front? I suppose I'm supposed to like that, too. Well, I don't; I often leave the bottom of a shell exposed with the top covered by several other windows, and can thus slip into it (leaving the other windows) to check mail and run other small commands without having to rearrange the desktop after I'm done. It sound's like NeXTStep won't let me do that. Perhaps I'd better ask: Will NeXTStep let me redefined what mouse clicks do? Or am I stuck with whatever NeXT thinks I like? While I'm at it: scott@NIC.GAC.EDU writes: > One area where there'd be problems on the NeXT is that, at least under the > X I saw, the cursor was _always_ on-screen. This caused me no end of > frustration, because you _always_ had to have that cursor within the > window you wanted to type in, and it was without fail right where you > were working. So you always had to move it a couple times when editting > a large file. (1) I believe X11 can be set up to be click-to-type, although I've never seen it done. (2) Right now there is a mouse-cursor in the window I am typing in, and this is causing me no trouble what-so-ever. (I just typed right under it now). (3) You hate pointer focus, and I hate click-to-type. I don't care WHY you hate pointer focus, I just want to be able to use the system I like. So, please, NO MORE POSTINGS on why I really ought to like click to type. I don't, and I don't want to use it. NeXT ought not to force me to; of course, they can't, as I can not buy a NeXT, but I'd rather that it didn't come to that. ^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (201)932-4580 (O) ((")) P.O. Box 1179, Rutgers Univ., Piscataway, NJ 08855 (201)220-6905 (H)
philip@pescadero.Stanford.EDU (Philip Machanick) (11/07/90)
In article <Nov.6.17.05.05.1990.17330@morley.rutgers.edu>, purtill@morley.rutgers.edu (Mark Purtill) writes: |> dd26+@andrew.cmu.edu (Douglas F. DeJulio) writes: |> >purtill@morley.rutgers.edu (Mark Purtill) writes: |> >> NeXTStep should provide an OPTION for pointer focus... |> >I can't agree. One of the horrible things about X11 is that it is too |> >customizable. This is bad for several reasons; it's particularly bad |> >for support people. |> I thought a NeXT was supposed to me a machine to make users |> more productive, not support people happier. Being different from |> what I'm used to is *not* going to make me more productive. Forcing |> me to use a fixed interface that someone else likes but that I hate |> will not make me more productive. It may make me buy a Sparc instead |> of a NeXT though, and if enough people do likewise, there won't BE any |> NeXT support people. |> Besides, I don't really see how this would make life more |> difficult for support anyway, unless they want to sit down at my |> machine and type (and point), which is not likely anyway. What are |> the other "several" reasons? |> If you want one more, it forces all users to either become designers or make do with whatever suboptimal setup they inherit from however they got their initial setup from. Look at it this way: a BMW or a Honda has a professionally designed interior. The placing of controls may be a bit different but, because the design is good, you get used to it quickly. Imagine if the switches and controls came packed in a separate box and you had to figure out how to position them optimally. Ergonomics is a difficult subject in car design; it is no easier in human-computer interaction. I'd rather have mildly inconsistent interfaces designed by professionals than be forced to design my own. "Professionals" don't always get these things right of course; that's why there are certain makes of car I wouldn't drive. But this is no argument for demanding total customization. I'm not saying interfaces should not be customizable at all, just that I think there are limits. I really can't see that making the user become a designer is "more productive". -- Philip Machanick philip@pescadero.stanford.edu
gillies@m.cs.uiuc.edu (11/07/90)
> The problem that I still have with the interface is the marriage of > click-in-window with bring-window-to-top-and-make-current. It should > be possible to make a window current without bringing it to top. Ditto. This is also the way Xerox's development environment works: click to type, but the window does not come to the top. The Mac is particularly crippled because it has no "move window to bottom". With click-to-type-and-bring-to-top, it is essential to include a fast way to get rid of the window which was topped, after you finish typing.
jacob@gore.com (Jacob Gore) (11/07/90)
morrison@cs.ubc.ca (Rick Morrison) writes: >The problem that I still have with the interface is the marriage of >click-in-window with bring-window-to-top-and-make-current. / comp.sys.next / purtill@morley.rutgers.edu (Mark Purtill) / Nov 6, 1990 / > Do I read this right? The window you're typing in MUST be in > front? No. If you click on a window (or drag it), it will come up front and become the key window (if it can). Alt-clicking on a window (or alt-dragging it) brings it to the front without making it the key window (and it can obscure, partially or completely, the key window). Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
ea08+@andrew.cmu.edu (Eric A. Anderson) (11/07/90)
>One summer, I worked with a NeXT cube and a VAXStation 3100 on my desk. >The NeXT ran (what else?) NeXTStep, the VAXStation, DECWindows. I'd only >used NeXT for 2 weeks before that, and Macs not at all. The NeXT at work >did not show up for about a month, so I'd had more time on the VAXStation >than on the NeXT when it showed up. >I _hated_ the move to focus stuff. I have no Idea what window manager you were running, because the dec window manager and session manager, especially under decwindows does not support focus follows pointer. Indeed, on the VaxStation I am working on there has been a hack written which allowed you to have focus follows pointer, it was IMPOSSIBLE in the dec supplied stuff. About the cursor always being on the screen -- Well gee, I personally could not deal with a cursor that went away. I would always want to be able to see the cursor, it would really suck If I didn't. Again, it is just my belief that it should be customizable. -Eric ********************************************************* "My life is full of additional complications spinning around until it makes my head snap off." -Unc. Known. "You are very smart, now shut up." -In "The Princess Bride" *********************************************************
cerberus@caen.engin.umich.edu (R Eric Bennett) (11/07/90)
In article <1990Nov6.075848.3527@engin.umich.edu> cerberus@caen.engin.umich.edu (R Eric Bennett) writes: >It's funny to hear that someone actually LIKES move to focus. Sure its nice to >be able to type blind every once in awhile, but more often than not it sends me >clamoring to find out where I'd typed 'make' in my source code. I admit that >I am not the greatest typist but when typing in a unix command I like to SEE >what I am typing. I have also only used X on DEC 3000/5100 (?) but >move to focus is REALLY annoying on them because you can only bring the window >to the front by clicking on a button at the top of the window. I have wasted >more time trying to move a window to the front than I have ever saved by being >able to type without a window being key. It's also annoying to have a window >come up and have your input redirected to that window just because it happened >to come up underneath your mouse pointer. > >According to human factors work, you only waste .1 second clicking the mouse >and since you have to move the mouse to activate another window anyway (~1.2 >seconds) I think I'd rather have the whole thing take ~8% longer just to avoid >the above headaches. > >Just one man's opinion, >R Eric Bennett >cerberus@caen.engin.umich.edu >cerberus@itl.itd.umich.edu (NeXT mail) > Sorry about this article being posted 4 times. Explanation: We have a problem with our rn program. It gives a segmentation fault when trying to post a follow-up article. To get around it, I have to execute the send command from a shell. I didn't think that the article was getting posted so I tried aliasing the entire command and writing a script and alias a source call of the script, etc. The four articles were a result of that. I was going to cancel them but I got t he old segmentation fault when trying to cancel and I haven't had time to post another article explaining the four copies. Sorry, Eric Bennett cerberus@caen.engin.umich.edu PS Yes I do think it is rather ironic, paradoxical, etc. to take up bandwidth by apologizing about taking up bandwidth. But I felt it should be done.
cap+@cs.cmu.edu (Chris Paris) (11/07/90)
In article <1990Nov7.005656.26478@Neon.Stanford.EDU> philip@pescadero.Stanford.EDU (Philip Machanick) writes: >If you want one more, it forces all users to either become designers or >make do with whatever suboptimal setup they inherit from however they got >their initial setup from. Look at it this way: a BMW or a Honda has a >professionally designed interior. The placing of controls may be a bit >different but, because the design is good, you get used to it quickly. >Imagine if the switches and controls came packed in a separate box and >you had to figure out how to position them optimally. Ergonomics is a >difficult subject in car design; it is no easier in human-computer >interaction. I'd rather have mildly inconsistent interfaces designed by >professionals than be forced to design my own. "Professionals" don't >always get these things right of course; that's why there are certain >makes of car I wouldn't drive. But this is no argument for demanding total >customization. > No. The ability to customize allows users to become designers, or make do with whatever setup they inherit from the manufacturer. In NeXTStep today, the above disjunction is missing. We are forced to make do with whatever (hard-coded) setup the manufacturer has provided. Allowing customization doesn't create problems for those who don't want it. It simply allows solutions for those who do. I agree that new users of X often inherit some pretty lousy setups. I also agree that X is far from turnkey. This is not a problem with X, but rather a problem with X support. When a commercial organization such as DEC (or NeXT) decides to supply X as a standard on its machines, there is an obligation to provide a reasonable set of defaults, just as NeXT was obligated to supply a "reasonable" set of defaults for its NeXTStep. In NeXTStep, these defaults were provided by means of hard-coding them into the program. In X, they would be provided by a set of configuration files, which users could change at will, or ignore if they didn't want to become "designers." Some things in NeXTStep work differently than some users would like, but provide the same functionality. Click to type is such a thing. However, other aspects of NeXTStep are simply restrictive, such as not being able to type in a window that is not on top (I'm talking about 1.0 here, I'll believe claims about 2.0 when I see it). This limitation will make it more difficult for me to get my work done, and this is just one reason why I plan to run X when I get my machine. Chris Paris cap@cs.cmu.edu
anderson@sapir.cog.jhu.edu (Stephen R. Anderson) (11/07/90)
In article <1990Nov7.005656.26478@Neon.Stanford.EDU> philip@pescadero.Stanford.EDU (Philip Machanick) writes: [previous discussion of customization a la X deleted] If you want one more, it forces all users to either become designers or make do with whatever suboptimal setup they inherit from however they got their initial setup from. Look at it this way: a BMW or a Honda has a professionally designed interior. The placing of controls may be a bit different but, because the design is good, you get used to it quickly. Imagine if the switches and controls came packed in a separate box and you had to figure out how to position them optimally. Ergonomics is a difficult subject in car design; it is no easier in human-computer interaction. I'd rather have mildly inconsistent interfaces designed by professionals than be forced to design my own. "Professionals" don't always get these things right of course; that's why there are certain makes of car I wouldn't drive. But this is no argument for demanding total customization. My apologies in advance, but this seems to suggest some lack of familiarity with life under "brand X" interfaces. In fact, X supports a large number of interface styles: at least gwm, mwm, olwm, and (tv)twm come to mind. Each provides a somewhat different (you should pardon the expression) look-and-feel. In general, these different views of human-machine interaction have been thought out in very considerable detail, typically by people with quite clear and coherent (though distinct) notions of the design considerations involved. Beginning users need do no designing whatsoever to have a fully functional setup that may well meet all of their needs. Quite advanced users may also find one of these packages nearly ideal off the shelf. But even the least customizable of this lot, OpenLook, provides some range for tweaking things to match what an individual finds optimal (and even OpenLook lets you choose click-to-focus vs. real-estate-focus!). The interface styles available under X in no way force the user to design things from the ground up: they merely _allow_ this (to a greater or lesser extent). To pursue your automotive analogy further, suppose your choices were limited to (a) the BMW/Honda/Porsche/Ferrari [choose one for illustration]; or (b) a GMC pickup. Now suppose the new BMW/Honda/etc. has been professionally designed to put the clutch on the right, and the accelerator on the left, and you can't bear that. Which would you prefer: being forced to buy the pickup, or having the option to re-arrange the pedals? I think it will be quite unfortunate if a substantial number of potential users of NeXTs find themselves having to choose something else for relatively trivial, low-level reasons. Why do you think there are so many thousands of init's and cdev's written for the mac? It's really not because Apple didn't have enough professionals at work in designing the OS, but rather because different folks go for different strokes - some of which weren't really envisioned when the OS was desgined in the first place. The resulting situation at present is rather chaotic, but I bet lots more people have macs than would be the case if the plain-vanilla Apple-supplied macOS were the only possibility. I'm not saying interfaces should not be customizable at all, just that I think there are limits. I really can't see that making the user become a designer is "more productive". On the other hand, _letting_ the user affect the design may well have a big impact on productivity. This is especially true, as others have pointed out, for users who work on more than one machine. If you go back and forth among Suns, macs, and the NeXT, it sure doesn't help productivity to have to constantly have part of your attention focused on "let's see - how was it that you do that on this box?" Steve Anderson
declan@remus.rutgers.edu (Declan McCullagh/LZ) (11/08/90)
In article <1990Nov6.221820.17987@informix.com>, cortesi@informix.com (David Cortesi) writes: > 1) No way to send a window to the back. If you completely cover a > window, the only way to get at it is to iconize everything in front > of it. Yes, I know about double-clicking the application's icon in > the dock... But do you know about Command-DownArrow? > 2) No way to use a window without bringing it to the front. I found > many good uses for the SunView ability to interact with a window that > was partly obscured by other windows. Command-UpArrow and Command-DownArrow work here, too. Or you can Alternate-Click in a window's title bar (that works under NeXTstep 1.0). > 3) Click-to-activate can cause scrolling: if you want only to activate > a window, and only its left edge is showing, you will also cause a > scroll action when you click on it. This is covered in the online documentation and is a conscious decision by NeXT. It's sometimes very nice to be able to click on a window's close box and having it disappear without activating that application. -------------------------------------------------------------------- Declan McCullagh / NeXT Campus Consultant \ declan@remus.rutgers.edu --------------------------------------------------------------------
glenn@heaven.woodside.ca.us (Glenn Reid) (11/08/90)
In article <Nov.5.13.41.53.1990.16444@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes: > And if you would find it horrible to have pointer-focus, >that's exactly how I feel about click-to-type. Different people have >different preferences, and NeXT won't make any sales by telling people >that their preferences are wrong. NeXTStep should provide an OPTION >for pointer focus, and, yes, this *is* a significnat factor in which >machine I buy (Sparc vs. Next). It's true that having the option would be nice. Just as a data point, I used Suns a lot before I got my NeXT machine. I was a die-hard fan of pointer focus, and it was one of the reasons I didn't like the Mac. However, I didn't consider that to be important enough to affect a multi-thousand dollar buying decision, so I got the NeXT anyway. It took me about a day to get used to click-focus, and I like it just fine now. Probably the most important thing to realize in this discussion is that it is NOT "click-to-type". On the Sun, you have to type a lot, because basically all you have is a lot of terminal windows and Emacs sessions, all of which are highly keyboard driven. Pointer focus is great because if you're not using the mouse, it's easier to just bump it into the right place then to actually find the mouse button and click it. It's the back-and-forth between keyboard and mouse that kills you. But on the NeXT, you end up using the mouse a lot, and you don't even notice the click-focus. Please, I know I have grossly over-generalized the Sun interface, but it was intended as a characature to make my point. Don't bother flaming me on that particular issue :-) Anyway, I don't miss the pointer-focus from the Sun, and I'd bet you six dollars you won't either. Glenn Reid -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
bennett@adobe.COM (Bennett Leeds) (11/08/90)
In article <1990Nov6.183235.27279@mcs.anl.gov> korp@atlantis.ees.anl.gov (Peter Korp) writes: >{...} Now, have NeXT put the >support for "pseudo" follow the cursor back into NeXTStep. It was there in >0.8 where by holding alt-cmd down and click would make a window input >sensitive but leave it where it was in the tree hierarchy. > >Why did this disappear? Will it come back? I would like to second this request. In keeping with a desktop metaphor, one does not have to bring every piece of paper one wishes to write on to the top of the stack. This is what NeXT forces you to do. Everytime. This makes it particularly difficult to read one window while typing in another app (the window being typed in pops to the top and covers the window being read). I usually resort to Command-clicking the new key window (this after clicking to make it key): thus sending it to the bottom of the stack, but keeping it the key window. Another related, but not as serious, problem occurs when trying to read panels in an app that automatically hide themselves when the app is not the current app. I can't read the information in the panel while I'm typing in Terminal or Edit (and, I can't select the infomation in the panel and copy it to the Pasteboard). I would appreciate having a means to select an app, telling the previously active app NOT to hide its panels (either for copying purposes or because I'm coming right back to it after starting this background task). >Is the Black Hole really gone forever? >Peter The recycler metaphor works better, IMHO. With a true black hole you would never be able to exceed the pull of gravity enough to get your files back out. With a recycling bin you can get your files out before the bin itself is dumped; after that you get the raw bits back to make into new files. Pretty smooth, if you ask me. Now, (smileys on :-} ) if you were to Command-drag your files to the recycler, then the bin icon should change to the black hole icon and act as if you did a Command-r (or for you Unix buffs an "rm") and destroy the file(s) with no hope of later data recovery. - Bennett
vesper@kong.gsfc.nasa.gov (Greg Vesper - RMS) (11/09/90)
In <10357@ubc-cs.UUCP> morrison@cs.ubc.ca (Rick Morrison) writes: >I moved from an X-windows environment to NeXTStep about a year and a half ago. >I too initially despised click to type. By now, of course, I am quite used >to it, and actually appreciate its conservative behaviour from time to >time. The problem that I still have with the interface is the marriage of >click-in-window with bring-window-to-top-and-make-current. It should >be possible to make a window current without bringing it to top. I >am forever shifting windows around in order to view some small >fraction of the contents of each window concurrently. I couldn't agree more.. Everytime I activate a window, even if its just for a quick keystroke, my whole desktop gets rearranged - menus change, windows overlap - yuk. Its very inelegant I think. -- Greg Vesper (vesper@kong.gsfc.nasa.gov) 301-286-5162 Goddard Space Flight Center; Greenbelt, Maryland "Two basic facts of life: 1) There is a God. 2) You're not him."
azure@portia.Stanford.EDU (Lai Heng Chua) (11/09/90)
8 - Nov - 1990 I wonder whether all this hair splitting is going to any good. Why don't we just have the following, (I'm numbering them so people can make their case) CLH 1. Text views - clicking on them once do not bring the windows they are in to the front. But key input goes to the clicked text view. Double clicking on them will bring the window to the front. This interface feature is patented by yours truly, so those guys at NeXT might want to talk to me. CLH 2. Windows - burying a window should be easy. Alt-click on the menu bar should bury the window. We want to bury windows when we are temporarily done with them. Iconifying windows is also good but placing them at the bottom of the screen is not so hot. They should be placed behind the Dock with some pixels showing. The title may be made bottom up on the left so we can see the title of the iconified windows (this technique is also patented by yours truly). These should be layered nicely so we can have another couple of layers of them. CLH 3. Scroll bars - problem is clicking on them causes the window to come to the front AND the window to scroll to the position of the click. The first behavior is fine but the second behavior is not desirable. If we want the second behavior then we should not have the first behavior (as in the case of iconify and close buttons). I think there are other interface design improvements that can be made. How should things work on a multiscreen NeXT? Write me. Well, to the more important issues. The last thing that NeXT should do is to rest on its laurels or become arrogant. The market place is just too deadly nowadays. SPARC stations with 30 MIPS and 4 MFLOPS 3-D and 24 bit color will be contending with them. NeXT needs a strategy to put equivalent power at the same time and stay ahead in software innovation (which they have a lead on now) for the coming years. There is much more software innovation opportunities. But things will be for naught if NeXT doesn't seize its market opportunities quickly.... I don't see them doing that. -- Lai Heng Chua
vesper@kong.gsfc.nasa.gov (Greg Vesper - RMS) (11/10/90)
In <314@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: >Anyway, I don't miss the pointer-focus from the Sun, and I'd bet you >six dollars you won't either. You're still missing the point.. You can tell somebody what you like, just don't tell them what they should like. I've been using the cube for several months and I still hate click-to-type.. -- Greg Vesper (vesper@kong.gsfc.nasa.gov) 301-286-5162 Goddard Space Flight Center; Greenbelt, Maryland "Two basic facts of life: 1) There is a God. 2) You're not him."
rca@cs.brown.edu (Ronald C.F. Antony) (11/12/90)
In article <Nov.5.13.41.53.1990.16444@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes: >jmann@angmar.sw.stratus.com (Jim Mann) writes: >>It is NOT just a vestige of non-multi-tasking systems. In saying this, you >>seem to be making the assumption that everyone would prefer the >>non-click-to-type method of activation. I disagree. > Irrelavent. This thread started with someone asking for the >OPTION to not have to click to type. No one has suggested that >everyone be forced to use non-click to type, and indeed X allows both >click to type and not. > And if you would find it horrible to have pointer-focus, >that's exactly how I feel about click-to-type. Different people have >different preferences, and NeXT won't make any sales by telling people >that their preferences are wrong. NeXTStep should provide an OPTION >for pointer focus, and, yes, this *is* a significnat factor in which >machine I buy (Sparc vs. Next). Although I hate to repeat myself, I think I have to post this again since this discussion about click to focus or point to focus is getting out of hand and starts being boring. There is a BIG difference between a window server (Xwindows) and a user interface (NeXT's Workspace manager). The WS is designed to help people with on of the problems of GUIs i.e. cluttered screens. In order to do so the WS hides certain sorts of windows (i.e. panels and menues) while an application is not in focus. Thus switching focus is sort of an strong function performed by the user. It involves hiding all the menues and panels of the currently focused application and exposing the panels and menues of the to be focused application. This results in a sometimes heavy change in the layout of the screen and takes also quite some cpu cycles. In order to save your (i.e. the users) eyes and the performance of the cpu, the WS requires you to click on a window of the application you want to focus on. Without this, a slight move of the mouse could result in 10 focus changes in half a second and thus you would see all the panels and menues flashing over your screen. Do you really want to option to hurt your eyes? The only thing that would be useful is if there was a way to alt-click to a window such that switching focus could be done without an auto-raise to click. (How about that NeXT?) Yes, X gives your more flexibility in this respect, but you have to do also all the work yourself to keep a screen on which you are able to work, NeXT does a lot of this for you without that you really notice. A little click may be annoying in the beginning, but as you have to move the mouse anyway, it does not hurt either. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Bernhard Shaw | rca@cs.brown.edu or antony@browncog.bitnet
rca@cs.brown.edu (Ronald C.F. Antony) (11/12/90)
In article <wbBh1o_00VQpQ3cGJe@andrew.cmu.edu> ea08+@andrew.cmu.edu (Eric A. Anderson) writes: >is the solution taken by many X applications. Alternately you can have >the menus pop up with a key held down ala xterm. I personally prefer >this strategy, I like my menus to be close to the window I'm working in >and having them right below the title bar or something like that is very There is a much nicer option built into WS, just enable the right mouse button. Then clicking on it brings up the menu right where you are. This is quicker than anything you mentioned. Now if NeXT just would ennable us to tear off submenues in this mode... BTW: If you move the menue off the screen (Preferences or dwrite) then you also save critical screen real estate with this strategy as well. Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Bernhard Shaw | rca@cs.brown.edu or antony@browncog.bitnet
purtill@morley.rutgers.edu (Mark Purtill) (11/13/90)
rca@cs.brown.edu (Ronald C.F. Antony) writes: >In article <Nov.5.13.41.53.1990.16444@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes: >> And if you would find it horrible to have pointer-focus, >>that's exactly how I feel about click-to-type. Different people have >>different preferences, and NeXT won't make any sales by telling people >>that their preferences are wrong. NeXTStep should provide an OPTION >>for pointer focus, and, yes, this *is* a significnat factor in which >>machine I buy (Sparc vs. Next). >Although I hate to repeat myself, I think I have to post this again >since this discussion about click to focus or point to focus is >getting out of hand and starts being boring. >There is a BIG difference between a window server (Xwindows) and a >user interface (NeXT's Workspace manager). Fine. Replace X-Windows with X-Windows + (say) VTWM. I don't see that as signifigantly different from NeXTStep. >The WS is designed to help people with on of the problems of GUIs i.e. >cluttered screens. In order to do so the WS hides certain sorts of >windows (i.e. panels and menues) while an application is not in focus. >Thus switching focus is sort of an strong function performed by the >user. This is red herring. It's already been pointed out that if switching windows takes all this time, you simply wait until the mouse is motionless in a window for wome small amount of time. And I don't understand the "problem" of cluttered screens. When I am not using a program, I iconify it. If it's on my screen, then there's a reason for it being there, e.g., I'm going to use it shortly. In other words, I'LL decide if my window is cluttered or not. Please do not presume to decide for me. >The only thing that would be useful is if there was a way to alt-click >to a window such that switching focus could be done without an >auto-raise to click. (How about that NeXT?) It's not the only thing, but it's certainly needed. >Yes, X gives your more flexibility in this respect, but you have to do >also all the work yourself to keep a screen on which you are able to >work, NeXT does a lot of this for you without that you really notice. >A little click may be annoying in the beginning, but as you have to >move the mouse anyway, it does not hurt either. I DON'T WANT the NeXT to do the "work" for me. If I wanted to be held by the hand, I'd buy a Mac. Please listen to what the pointer-focus people are saying: we want to do things a certain way. We do NOT want the NeXT or any other system to force us to do it a different way. It is IRRELAVENT whether the NeXT way is "better", we don't like it. OKay? Now, I'm not saying that X+window manager is the greatest thing since sliced bread. But at least it doesn't force you into a fixed way of doing things. ^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (201)932-4580 (O) ((")) P.O. Box 1179, Rutgers Univ., Piscataway, NJ 08855 (201)220-6905 (H)
peb@Autodesk.COM (Paul Baclaski) (11/13/90)
In article <56054@brunix.UUCP>, rca@cs.brown.edu (Ronald C.F. Antony) writes: > Although I hate to repeat myself, I think I have to post this again > ....In order to > save your (i.e. the users) eyes and the performance of the cpu, the WS > requires you to click on a window of the application you want to focus > on. Without this, a slight move of the mouse could result in 10 focus > changes in half a second and thus you would see all the panels and > menues flashing over your screen. I hate to repeat myself too, but there *is* another way: Sun solves spurious-window-activation-problem by having a 200 millisecond time filter in which your mouse must stop for 200 milliseconds before the active window is switched. Sun also allows click-to-type. Customizability is not inherently bad as long as you have good defaults. Compare GNU emacs with Unipress emacs: both are customizable, but Unipress does the right thing out of the box, while GNU demands that you make your arrow keys work (amoung other things). Sorry to beat a dead horse, Paul E. Baclaski peb@autodesk.com
jschultz@pyrtech.pyramid.com (J.W. Schultz) (11/13/90)
In article <2955@lectroid.sw.stratus.com> jmann@angmar.sw.stratus.com (Jim Mann) writes: >In article <FOX.90Nov5085517@papyrus.tempo.nj.att.com>, >fox@allegra.att.com (David Fox) writes: >|>In a multi-tasking operating system there is no need to activate >|>and de-activate applications, only a need to be able to see which >|>application is currently receiving input. The requirement of click- >|>to-type is a vestige of non-multi-tasking operating systems like >|>MS-DOS and MacOS. Even the Amiga window system can be configured >|>so there is no need to click on applications to direct the input >|>stream to them. This is a very disturbing revelation for someone >|>like me who has been thinking of buying a NeXT machine. >|> >It is NOT just a vestige of non-multi-tasking systems. In saying this, you >seem to be making the assumption that everyone would prefer the >non-click-to-type method of activation. I disagree. I think most people, >especially those NOT coming from a Sun environment, prefer the click-to-type >scheme. Perhaps this is in part because it is what they are used to from >Macs and PCs. One of the reasons I like my NeXT so much is that they DID >build on reflexes many of us had developed from the micros we'd worked >on: click to type, single click to select, double click to activate, drag >over to select a region and so forth. I find Sun to be the odd machine out. > > >Jim Mann >Stratus Computer >jim_mann@es.stratus.com Just to add my voice to the chaos; as one who is considering the NeXT box i find the lack of a configuration switch for keyboard focus somewhat disturbing. But to give my own preference: I perfer to click-on-focus rather than to merely place the pointer in the desired window. The reason for this is that I find having the mouse pointer in the active window distracting and that it sometime obscures the text that i need to see. This is one of the reasons I am using motif which allows me that _option_. J.W. jschultz@pyramid.pyramid.com
scott@mcs-server.gac.edu (Scott Hess) (11/13/90)
In article <543@autodesk.COM> peb@Autodesk.COM (Paul Baclaski) writes:
Sun solves spurious-window-activation-problem by having a 200 millisecond
time filter in which your mouse must stop for 200 milliseconds before
the active window is switched.
Sun also allows click-to-type.
I've been thinking on this, and I think that this is doable. It is
obvious, with the current setup of the NeXT "window manager" that
raw move-to-focus will not work. Too much application swapping, too
much busy-ness onscreen - it would be _annoying_.
But, I think that the Sun style would work. Proposal:
Click in a window makes that window the main/key window, and brings
it to the front - like it does now.
Move over a window and drop the mouse (for 200ms, or whatever) makes that
window the main/key window but leaves it where it is in the window
hierarchy (ie, covered if it is, or whatever).
Conceivably, have alt-click make a window main without bringing it forward,
just to be complete.
Now, can this be done? Yes, an excellent DPS programmer who knows the
internals of the window server could probably do it in a package. My
gut feeling (as if you'd be interested) about how the windows work is
that when you click on a window, the window server brings that window
to the front, then sends the mouse event to the app (actually, the context,
which handles the making-main stuff). I come to this conclusion by the
fact that you can click a window who's apps is busy, and it comes to the
front - so the app cannot be doing it.
I'd envision this as a loadable package, much like the package distributed
a long time ago (seems like it was over a year ago) to add the ability
to bind a command-command-keystroke to an app and command-up/down to
move windows up and down relative to other windows.
Generally, how does one go about finding out the neat things that
the window server does? I'd assume that all the clicking-in-window
stuff is in a window package, and thus in some dictionary or another,
but is there any documentation for this? Besides
/usr/lib/NextStep/windowPackage1.0.ps, that is :-)
Sorry to beat a dead horse,
Hit him again for me, please :-)
--
scott hess
scott@gac.edu
Independent NeXT Developer (Stuart)
GAC Undergrad (Horrid. Simply Horrid. I mean the work!)
<I still speak for nobody>vesper@kong.gsfc.nasa.gov (Greg Vesper - RMS) (11/14/90)
In <Nov.12.15.14.37.1990.383@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes: > I DON'T WANT the NeXT to do the "work" for me. If I wanted to >be held by the hand, I'd buy a Mac. Please listen to what the >pointer-focus people are saying: we want to do things a certain way. >We do NOT want the NeXT or any other system to force us to do it a >different way. It is IRRELAVENT whether the NeXT way is "better", we >don't like it. OKay? > Now, I'm not saying that X+window manager is the greatest >thing since sliced bread. But at least it doesn't force you into a >fixed way of doing things. Well said, (for the ump-teenth time). I couldn't agree more. To Ronald who sparked this reply: You can tell us what you like, but don't tell us what we should like. >^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (201)932-4580 (O) >((")) P.O. Box 1179, Rutgers Univ., Piscataway, NJ 08855 (201)220-6905 (H) -- Greg Vesper (vesper@kong.gsfc.nasa.gov) 301-286-5162 Goddard Space Flight Center; Greenbelt, Maryland "Two basic facts of life: 1) There is a God. 2) You're not him."
pegram@kira.UUCP (Robert B. Pegram) (11/15/90)
scott@mcs-server.gac.edu (Scott Hess) writes: ... (dots mark deletions) > But, I think that the Sun style would work. Proposal: > Click in a window makes that window the main/key window, and brings > it to the front - like it does now. > Move over a window and drop the mouse (for 200ms, or whatever) makes that > window the main/key window but leaves it where it is in the window > hierarchy (ie, covered if it is, or whatever). > Conceivably, have alt-click make a window main without bringing it forward, > just to be complete. ... > I'd envision this as a loadable package, much like the package distributed ... > Sorry to beat a dead horse, > Hit him again for me, please :-) All right, I will 8-). I don't have a NeXT, but if the gods are amenable, will someday. On my Atari ST (yes, I am getting the Mac emulator, much discussed here, gotta get more software 8-) there is an alternate shell (desktop) that allows something else that NeXT should provide. I'm surprised in fact, that this sort of thing isn't easily fixable in your much vaunted Objective C development environment. The feature is an extra button that sends its window to the back, behind all the other windows. It's very convenient, and I just wish that all ST (and Mac and NeXT) windows could do this, because window arrangement is then much less of a black art. I also like the idea expressed above, it would be nice on my xterm (I know, boo, hiss 8-) as well as on the Atari or a NeXT. Consider adding the window-to-the-back button to the window manager package you're thinking of making. Just my $0.02. Bob Pegram Internet: pegram@griffin.uvm.edu UUCP: ...uvm-gen!pegram
carlos@eeyore.caltech.edu (11/15/90)
As mentioned in a previous article, a. point-to-focus is generally better for keyboard intensive interfaces. b. click-to-focus is generally better for mouse intensive interfaces. A compromise would be to globally use click-to-focus to activate applications (since NeXTstep is by definition a mouse intensive interface) and either para- digm within an application according to that application's needs. For example: Terminal is keyboard intensive therefore it would probably use point-to-focus. This would only affect Terminal's windows. Point-to-click would activate other applications. (Window's should retain focus until the user switches focus to another window. You would still have focus even if the mouse was in the background window.) Draw is mouse intensive. It would use click-to-focus. Carlos Salinas "Use the NeXT Luke. Succumb to the dark side of the cube." "But which side is the dark side?"
gessel@carthage.cs.swarthmore.edu (Daniel Mark Gessel) (11/16/90)
In article <1990Nov14.210337.16130@uvm.edu> pegram@kira.UUCP (Robert B. Pegram) writes:
All right, I will 8-). I don't have a NeXT, but if the gods are
amenable, will someday. On my Atari ST (yes, I am getting the Mac
emulator, much discussed here, gotta get more software 8-) there is an
alternate shell (desktop) that allows something else that NeXT should
provide. I'm surprised in fact, that this sort of thing isn't easily
fixable in your much vaunted Objective C development environment. The
feature is an extra button that sends its window to the back, behind
all the other windows. It's very convenient, and I just wish that all
ST (and Mac and NeXT) windows could do this, because window
arrangement is then much less of a black art. I also like the idea
expressed above, it would be nice on my xterm (I know, boo, hiss 8-)
as well as on the Atari or a NeXT. Consider adding the
window-to-the-back button to the window manager package you're
thinking of making. Just my $0.02.
Bob Pegram
Actually, the right way to do this would be with a subclass of window. This is
really the only way (that I know of) to change the window structure (in
terms of buttons etc).
That is, the window manager doesn't determine what the windows look like, the
code of the window object does.
However, this would be hard to get on windows of applications that you don't
have the source code for, except . . .
The NeXT uses shared libraries, which if I understand it correctly, means that
the programs themselves don't have the library code linked in, this is done
at runtime (and there may only be one image in memory of a library routine,
I don't know if this feature falls under the same category). If there was
a way to substitute in your own code for the library routines that control the
window, people could customize their windowing systems all to heck.
There might be collisions between other subclasses of windows and new
class variations that could be installed in this way. It also may be hard
or potentially irriversable. It could, also, be the equivalent of a mac init,
which would allow people to customize their NeXT's. (there's also the problem
of multi users, etc).
You could probably write a subclass of window that has a tracking rect, that
put the focus (not a view type focus) when the mouse was moved into it, without
moving the window to the front.
Does anybody know if this kind of library routine substitution would work?
Dan
--
Daniel Mark Gessel Independent Software Consultant
Internet: gessel@cs.swarthmore.edu and Developer
My opinions are not necessarily representative of those of Swarthmore College.jerry@truevision.com (Jerry Thompson) (11/16/90)
In article <350@autodesk.COM> peb@Autodesk.COM (Paul Baclaski) writes: >Actually, on the Amiga, moonmouse (aka sunmouse) does not work perfectly >because all it does is interpose a click whenever the mouse moves into >a new window. This causes problems with editors that use the same I don't know about sunmouse, but try any of the other mouse accelerator/ screen blanker/macro key/etc. programs. They set the window underneath to be active without inserting a button event message. -- Jerry Thompson | // checks ___________ | "I'm into S&M, "What I want to know is, have | \\ // and | | | | Sarcasm and you ever seen Claude Rains?" | \X/ balances /_\ | /_\ | Mass Sarcasm."
lerman@stpstn.UUCP (Ken Lerman) (11/16/90)
In article <GESSEL.90Nov15114555@carthage.cs.swarthmore.edu> gessel@carthage.cs.swarthmore.edu (Daniel Mark Gessel) writes:
[...]
->The NeXT uses shared libraries, which if I understand it correctly, means that
->the programs themselves don't have the library code linked in, this is done
->at runtime (and there may only be one image in memory of a library routine,
->I don't know if this feature falls under the same category). If there was
->a way to substitute in your own code for the library routines that control the
->window, people could customize their windowing systems all to heck.
->
->There might be collisions between other subclasses of windows and new
->class variations that could be installed in this way. It also may be hard
->or potentially irriversable. It could, also, be the equivalent of a mac init,
->which would allow people to customize their NeXT's. (there's also the problem
->of multi users, etc).
->
->You could probably write a subclass of window that has a tracking rect, that
->put the focus (not a view type focus) when the mouse was moved into it, without
->moving the window to the front.
->
->Does anybody know if this kind of library routine substitution would work?
->
->Dan
->--
->Daniel Mark Gessel Independent Software Consultant
->Internet: gessel@cs.swarthmore.edu and Developer
->My opinions are not necessarily representative of those of Swarthmore College.
I am not a NeXT user, but have significant experience with the
Objective-C language in a large number of environments. I have a few
comments on your suggestion (please insert IMHO before all of the following):
1 -- It would NOT work if you added instance variables to your new
class, because your existing subclasses would not know about them.
But there are ways to get around that.
2 -- The poseAs() function in Stepstone's Objective-C runtime (I
believe it is called class-poseAs() by NeXT) is intended to be used
for this type of functionality.
3 -- You would probably have to do something special to cause your new
class to be loaded with the foreign applications. I am not familiar
enough with the NeXT runtime to suggest what, though.
4 -- This is precisely the type of problem that object-oriented
programming is supposed to help us solve.
5 -- It would probably be a lot easier if you had the source to the
NeXT runtime and window classes. I have not seen either.
Kenmouse@thunder.mcrcim.mcgill.edu (der Mouse) (11/18/90)
In article <56054@brunix.UUCP>, rca@cs.brown.edu (Ronald C.F. Antony) writes: > In article <Nov.5.13.41.53.1990.16444@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes: >> jmann@angmar.sw.stratus.com (Jim Mann) writes: >>> It is NOT just a vestige of non-multi-tasking systems. In saying >>> this, you seem to be making the assumption that everyone would >>> prefer the non-click-to-type method of activation. I disagree. Making assumptions about what "everyone" would prefer is dangerous. Almost all such assumptions are false. >> Irrelavent. This thread started with someone asking for the OPTION >> to not have to click to type. No one has suggested that everyone be >> forced to use non-click to type, and indeed X allows both click to >> type and not. >> And if you would find it horrible to have pointer-focus, that's >> exactly how I feel about click-to-type. Different people have >> different preferences, and NeXT won't make any sales by telling >> people that their preferences are wrong. > Although I hate to repeat myself, I think I have to post this again > since this discussion about click to focus or point to focus is > getting out of hand and starts being boring. > There is a BIG difference between a window server (Xwindows) and a > user interface (NeXT's Workspace manager). Go back and reread the pieces I've quoted with ">>". Most users can't see the difference in architecture between X and NextStep, and many of them wouldn't understand if you explained it. They just want it to work the way they want it to work, and aren't interested in excuses about what a lovely clean architecture this system uses when it means you can't get what you want. > The WS is designed to help people with on of the problems of GUIs > i.e. cluttered screens. In order to do so the WS hides certain sorts > of windows (i.e. panels and menues) while an application is not in > focus. Thereby eliminating any danger that the user could find any useful information in them when using some other app. Hmm. Thankee very much, but let *me* decide when those little windows should go away, okay? It's *my* screen layout. Grrr. > Thus switching focus is sort of an strong function performed by the > user. It involves hiding all the menues and panels of the currently > focused application and exposing the panels and menues of the to be > focused application. This results in a sometimes heavy change in the > layout of the screen and takes also quite some cpu cycles. In order > to save your (i.e. the users) eyes and the performance of the cpu, > the WS requires you to click on a window of the application you want > to focus on. Without this, a slight move of the mouse could result > in 10 focus changes in half a second and thus you would see all the > panels and menues flashing over your screen. Do you really want to > option to hurt your eyes? This is a specious argument. There is nothing wrong with move-to-type with a slight delay, such as requiring the mouse to sit still in the new window for some time - a fifth of a second should be good - before performing the switch. (Ideally, during this time keystrokes are queued somewhere, not delivered to the previous focus window.) And yes, I want the option. It is not your, or NeXT's, place to try to tell me what I want. And if you, or NeXT, tells me I can't have it, regardless of the reason, that will have a negative effect on my opinion of the UI. > Yes, X gives your more flexibility in this respect, but you have to > do also all the work yourself to keep a screen on which you are able > to work, NeXT does a lot of this for you without that you really > notice. Speak for yourself. > A little click may be annoying in the beginning, but as you have to > move the mouse anyway, it does not hurt either. Well, under X I *don't* have to move the mouse. I use neither click-to-type nor move-to-type, but rather type-to-type: to change windows I use a select-key paradigm. (That is, to type into a given window, I press my "select" key (F7 or F8 on this keyboard, depending on whether I want to also raise the window or not) and then the key corresponding to the window I want.) NeXTStep doesn't give me this. Neither does the supplied X distribution, but X supplies enough documentation to allow me to do it myself. The NeXT doesn't, unless several people around here are joined in a conspiracy to keep the relevant documentation away from me (postings in support of this notion please use alt.conspiracy :-). I don't use NeXTs much; this is a strong reason why, though there are others. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu