"pointer" vs. "explicit/click-to-type" keyboard focus policy
Scott Raney
the mouse in to a window gives that window the keyboard focus) with
"explicit" (also called "click-to-type" where the user must click on
the window to begin typing in it). A history of this issue would also
be useful.
As you may know, the old SunView and Apollo Domain systems both used
pointer focus. Almost all other systems (e.g. Mac, Windows, NeXTstep,
Motif, OpenLook) use explicit focus. The only references I've found
regarding this issue are in the Motif and OpenLook documentation (both
of these UI styles support pointer focus, though they aren't set up
that way by default). Unfortunately, the documentation is
non-judgemental nor does it even mention the pros or cons of the two
policies. Anybody know why most of the vendors chose to use explicit
focus?
Silicon Graphics is the only OEM to deliver workstations configured
with pointer focus by default, and I'm looking for references that
will help me to convince them to join the rest of the world's program.
I believe this switch is in the best interests of both users, who will
probably have to use other types of systems, and of developers, who
have problems supporting both policies.
Our problems are specifically related to our "active-focus"
application, which doesn't work very well in a pointer focus
environment. There are two big problems running MetaCard in a pointer
focus environment. The first is that MetaCard (a Motif application)
has the Mac-like feature of selecting the contents of a field when you
tab into it. Pointer focus wreaks havoc with this since the selection
bounces all over the place when you move the mouse. The second
problem is that, unlike most other Motif applications" MetaCard
supports Mac-like floating palettes and a floating menu bar. These
dialogs don't ever need the keyboard focus, and so clicking in them
shouldn't give the focus to them since this will take the focus away
from a window that needs it for text entry. This architecture works
great in an explicit focus environment, but doesn't in a pointer focus
environment since the window manager jerks the focus away from a
window even when there is no point in doing so.
Any assistance in this area would be appreciated. Followups, please,
to comp.human-factors, or email to me (ra...@metacard.com) and I'll
summarize.
Scott
--
***********************************************************************
* Scott Raney 303-447-3936 Remember: the better you look, *
* ra...@metacard.com the more you'll see -- Lidia *
***********************************************************************
Robert Banz
>I'm looking for studies comparing "pointer" focus policy (where moving
>the mouse in to a window gives that window the keyboard focus) with
>"explicit" (also called "click-to-type" where the user must click on
>the window to begin typing in it). A history of this issue would also
>be useful.
>Silicon Graphics is the only OEM to deliver workstations configured
>with pointer focus by default, and I'm looking for references that
>will help me to convince them to join the rest of the world's program.
>I believe this switch is in the best interests of both users, who will
>probably have to use other types of systems, and of developers, who
>have problems supporting both policies.
Sorry, I MUST disagree with you. I think pointer-focus is great, and
if a user doesn't like it, they can turn it off with the appropriate
default.
>Our problems are specifically related to our "active-focus"
>application, which doesn't work very well in a pointer focus
>environment.
So, what you're trying to say is, since it doesn't work for your
application, everyone has to change. No...that's not how the
world works...
----
Robert Banz (ba...@umbc.edu)
UMBC Academic Computing Svcs.
(410) 455-3962
http://umbc8.umbc.edu/~banz/
Dave Olson
| Silicon Graphics is the only OEM to deliver workstations configured
| with pointer focus by default, and I'm looking for references that
| will help me to convince them to join the rest of the world's program.
| I believe this switch is in the best interests of both users, who will
| probably have to use other types of systems, and of developers, who
| have problems supporting both policies.
I'm not in the UI group, but I can tell you that this issue has
been hashed out internally to SGI many times, and it is *extremely*
unlikely we will change the default as shipped. It provides
compatibility with our earlier releases, and all of our usability
tests (that I know of) have confirmed that people prefer the pointer
focus.
| Our problems are specifically related to our "active-focus"
| application, which doesn't work very well in a pointer focus
| environment. There are two big problems running MetaCard in a pointer
| focus environment. The first is that MetaCard (a Motif application)
| has the Mac-like feature of selecting the contents of a field when you
| tab into it. Pointer focus wreaks havoc with this since the selection
| bounces all over the place when you move the mouse. The second
| problem is that, unlike most other Motif applications" MetaCard
| supports Mac-like floating palettes and a floating menu bar. These
| dialogs don't ever need the keyboard focus, and so clicking in them
| shouldn't give the focus to them since this will take the focus away
| from a window that needs it for text entry. This architecture works
| great in an explicit focus environment, but doesn't in a pointer focus
| environment since the window manager jerks the focus away from a
| window even when there is no point in doing so.
So tell customers who want your product/app to change the focus policy.
That's not unreasonable, if they want it, and if it's necessary to the
design (and you don't want to change it).
--
The most beautiful things in the world are | Dave Olson
those from which all excess weight has been | Silicon Graphics
removed. -Henry Ford | ol...@sgi.com
Michael B. Johnson
>>ra...@teal.csn.org (Scott Raney) writes:
>>| Silicon Graphics is the only OEM to deliver workstations configured
>>| with pointer focus by default, and I'm looking for references that
>>| will help me to convince them to join the rest of the world's program.
>>| I believe this switch is in the best interests of both users, who will
>>| probably have to use other types of systems, and of developers, who
>>| have problems supporting both policies.
>>
>>I'm not in the UI group, but I can tell you that this issue has
>>been hashed out internally to SGI many times, and it is *extremely*
>>unlikely we will change the default as shipped. It provides
>>compatibility with our earlier releases, and all of our usability
>>tests (that I know of) have confirmed that people prefer the pointer
>>focus.
>>
Have any of these studies been published? I know of no one at the Media
Lab, for example, who prefers pointer focus, and there are plenty of people
here whose main computer is an SGI. I bop back and forth between NEXTSTEP
and my SGI, and I *hate* pointer focus.
I'm not trying to be rude, but I'd love to see the studies, if they've been
published, as I have to believe it was for some very specific task domain,
and not in the more general purpose computer system SGI seems to be trying
to position themselves, ala Indigo Magic.
--
--> Michael B. Johnson -- wa...@media.mit.edu
--> MIT Media Lab -- Computer Graphics & Animation Group
--> 20 Ames St. E15-023G -- (617) 547-0563 (day office)
--> Cambridge, MA 02139 -- (617) 253-0663 (night office)
Peter Ivimey-Cook
: Sorry, I MUST disagree with you. I think pointer-focus is great, and
: if a user doesn't like it, they can turn it off with the appropriate
: default.
: >Our problems are specifically related to our "active-focus"
: >application, which doesn't work very well in a pointer focus
: >environment.
: So, what you're trying to say is, since it doesn't work for your
: application, everyone has to change. No...that's not how the
: world works...
I agree. IMHO Pointer focus is MUCH nicer than click-to-type. I have
it set up on every system I use. Of the people I work there is about
a 50-50 split.
Regarding the application; yes, autoselection etc is nice, but DONT
EVER override the selections made by a user. They are there for a
purpose and many users like it that way. If you must add in these
features do it in such a way that people using pointer focus can ignore
the extra feature - e.g. turn it off, provide an alternative, or make
it work acceptably in both selection systems. The whole point of X
toolkits is not *just* that the code is already written, it is that
the user gets a standardised interface which is easier to understand
and interact with. You start changing that and you've lost something
very valuable.
If you are still wondering, why is it that *every* window manager I
have used has a way of setting both selection policies; surely it's
not just because they fancied all the extra work? :-)
Sorry if I sound evangelical, but I do feel strongly that people
should regard the user's preferences as paramount. It's just not
acceptable to ignore them.
Regards,
Peter.
Paul Bruggeman
>In article <2u00s5$i...@gazette.esd.sgi.com> ol...@anchor.esd.sgi.com (Dave Olson) writes:
>>>ra...@teal.csn.org (Scott Raney) writes:
>>>| Silicon Graphics is the only OEM to deliver workstations configured
>>>| with pointer focus by default, and I'm looking for references that
>>>| will help me to convince them to join the rest of the world's program.
>>>| I believe this switch is in the best interests of both users, who will
>>>| probably have to use other types of systems, and of developers, who
>>>| have problems supporting both policies.
>>>
>>>I'm not in the UI group, but I can tell you that this issue has
>>>been hashed out internally to SGI many times, and it is *extremely*
>>>unlikely we will change the default as shipped. It provides
>>>compatibility with our earlier releases, and all of our usability
>>>tests (that I know of) have confirmed that people prefer the pointer
>>>focus.
>>>
>
>Have any of these studies been published? I know of no one at the Media
>Lab, for example, who prefers pointer focus, and there are plenty of people
>here whose main computer is an SGI. I bop back and forth between NEXTSTEP
>and my SGI, and I *hate* pointer focus.
>
>I'm not trying to be rude, but I'd love to see the studies, if they've been
>published, as I have to believe it was for some very specific task domain,
>and not in the more general purpose computer system SGI seems to be trying
>to position themselves, ala Indigo Magic.
Why not start a survey? I vote for pointer focus.
Paul
brug...@netcom.com
Dave Olson
| Lab, for example, who prefers pointer focus, and there are plenty of people
| here whose main computer is an SGI. I bop back and forth between NEXTSTEP
| and my SGI, and I *hate* pointer focus.
No, these are internal tests. I'm sure that there are people (perhaps many)
who prefer the alternate method. Particularly if you frequently switch
systems that do it the other way. But if you like it the other way, just
set the resource in your local resource files.
| I'm not trying to be rude, but I'd love to see the studies, if they've been
| published, as I have to believe it was for some very specific task domain,
| and not in the more general purpose computer system SGI seems to be trying
| to position themselves, ala Indigo Magic.
No, these were general, pretty much across the board, both 'naive' and
'expert' users. It wasn't a huge population, but the results were pretty
conclusive, as I recall.
I personally hate the explict focus policy, and prefer pointer focus,
but them I'm an old fart, who grew up with ascii terminals ;)
Arthur Tateishi
Michael B. Johnson <wa...@media.mit.edu> wrote:
>In article <2u00s5$i...@gazette.esd.sgi.com> ol...@anchor.esd.sgi.com (Dave Olson) writes:
>>>compatibility with our earlier releases, and all of our usability
>>>tests (that I know of) have confirmed that people prefer the pointer
>>>focus.
Thank you, Dave!
>Have any of these studies been published? I know of no one at the Media
>Lab, for example, who prefers pointer focus, and there are plenty of people
>here whose main computer is an SGI. I bop back and forth between NEXTSTEP
>and my SGI, and I *hate* pointer focus.
Then change it on the SGI! At least you can. I also presume the MIT
Media Lab is also dominated by emacs users. I have a belief that many
institutions develop common (yeah I know, there's always some rebels)
preferences from the defaults and learning materials made available.
I've had a few people mention how they hate the click-to-focus default
in mwm but never take the time to change it. It's a very small sample
but half didn't even know mwm could be changed to pointer-policy.
Well to respond to you, I **HATE** click-to-focus!! (So there!
Hrumph!) What really drives me nuts are platforms like the Macs, MS
Windows, and OS/2 that don't have any way to change it.
One thing I've tended to see around here is that people weened on
click-to-focus have less problems shifting to pointer-focus than the
other way around.
I can even tell you why I (my opinions) like pointer-focus. Computer
displays are never big enough (I usually work at 1152x900 with 16-19"
monitors) and never have enough resolution. Therefore, windows tend to
overlap. However, a bit of care in placing windows usually allows me
to use various apps/xterms with partially obscured windows just fine.
Further, pointer-policy has fewer abrupt changes moving from app to
app and I still have the ability to "raise" my current window easily
enough if I have to. Keep in mind I also consider myself to be
mouse-impaired^H^H^H^H^H^H^H^Hchallenged especially when it comes to
clicking on small controls.
>I'm not trying to be rude, but I'd love to see the studies, if they've been
>published, as I have to believe it was for some very specific task domain,
>and not in the more general purpose computer system SGI seems to be trying
>to position themselves, ala Indigo Magic.
So would I. I'd also like to see the studies that support the
click-to-focus strategy to see how they came to differing conclusions.
arthur
--
Choices don't scare me. However, a lack of choices does.
Arthur Tateishi ruh...@turing.utoronto.ca
Rob Silvers
>In article <1994Jun19.1...@news.media.mit.edu> wa...@media.mit.edu (Michael B. Johnson) writes:
>>
>>Have any of these studies been published? I know of no one at the Media
>>Lab, for example, who prefers pointer focus, and there are plenty of people
>>here whose main computer is an SGI. I bop back and forth between NEXTSTEP
>>and my SGI, and I *hate* pointer focus.
>>
>>--> MIT Media Lab -- Computer Graphics & Animation Group
>>--> 20 Ames St. E15-023G -- (617) 547-0563 (day office)
>>--> Cambridge, MA 02139 -- (617) 253-0663 (night office)
I think pointer focus is much better, as long as the window does not
raise to front on focus. I cannot think of a reason in the world why
you would prefer to click on a window to focus it. OpenWindows on
the Sun (which I think everyone hates) requires the click. I go
insane after a few minutes. SGI is now my main computer -- a default
of pointer focus is one of the many small reasons why I like the
system. I used to but no longer have the energy to change default
X windows configurations -- if it feels broken (like the Sun) I just
will not use it.
--Rob
Jerry Natowitz
Rob Silvers <rsil...@media.mit.edu> wrote:
>I think pointer focus is much better, as long as the window does not
>raise to front on focus. I cannot think of a reason in the world why
>you would prefer to click on a window to focus it. OpenWindows on
>the Sun (which I think everyone hates) requires the click. ...
This works very well for me in .Xdefaults:
OpenWindows.SetInput: followmouse
The PROPERTIES menu item will also get you there.
--
Jerry Natowitz - j...@spdcc.com
David Finch, The Mail Reader
|>I think pointer focus is much better, as long as the window does not
|>raise to front on focus. I cannot think of a reason in the world why
|>you would prefer to click on a window to focus it. OpenWindows on
|>the Sun (which I think everyone hates) requires the click. I go
^ the OpenLook style is much better looking and easier to
understand than Motif, but this is a moot point.
|>insane after a few minutes. SGI is now my main computer -- a default
RTFM - Workspace menu, select under Utilities the Properties.
set the Category to 'Miscellaneous'. There is an option 'Set
Input Area' set it to 'Move Pointer'. Press 'Apply' button.
|>of pointer focus is one of the many small reasons why I like the
|>system. I used to but no longer have the energy to change default
|>X windows configurations -- if it feels broken (like the Sun) I just
|>will not use it.
It is not broken on the Sun. I use it in Pointer focus
mode everyday and all day. Infact the OpenLook Spec specificaly
states that all functions will work in both mode. Last time
I used Motif even if you set the decoration to use the same
colour in active window mode it still changes the decoration
colour what a stupid interface.
--
/ Chair of 1996 British Roleplaying Convention Bid Committee
/\|/\ Ban the Orange Book - root:0 is non-divisable
| K | All Hail Discordia - 0 is the First Chaotic Prime
\___/ david...@vger.demon.co.uk & sa...@monosys.com
Ralph Betza
+ In article <CrM0M...@csn.org>, ra...@teal.csn.org (Scott Raney) wrote:
+ a) Errors as a function of pointing devices:
+ 1) pointing devices needing static surface (i.e., mouse)
+ 2) pointing devices independent of surface (i.e., trackball)
+
+ b) Errors as a function of environment:
+ 1) clean desk and no visitors
+ 2) messy desk with visitors
+ 3) airliner passenger
+ 4) car passenger on an interstate at speed-limit
No, I think that's wrong. I think that expressing the test in that
manner might bias the results.
Here's a better idea:
a) measure the number of button clicks needed to go from
window A to window B, pick up some text there, and paste it back
in to window A.
b) measure the number of button clicks needed to go from one
window to another in general.
I think my experiment is much fairer.
:-)
Mike O'Connor
ruh...@turing.toronto.edu (Arthur Tateishi) writes:
:I can even tell you why I (my opinions) like pointer-focus. Computer
:displays are never big enough (I usually work at 1152x900 with 16-19"
:monitors) and never have enough resolution. Therefore, windows tend to
:overlap. However, a bit of care in placing windows usually allows me
:to use various apps/xterms with partially obscured windows just fine.
:Further, pointer-policy has fewer abrupt changes moving from app to
:app and I still have the ability to "raise" my current window easily
:enough if I have to. Keep in mind I also consider myself to be
:mouse-impaired^H^H^H^H^H^H^H^Hchallenged especially when it comes to
:clicking on small controls.
I have the same problem. Since I exist in a Motif and MS-Windows
environment for the most part, I use the Alt-Tab combination and
hotkey through the various windows rather than take one of my hands
OFF the keyboard to invoke the mouse. Only problem with that is,
this only works with explicit focus. I'd love to have my mouse move
within the same window that I Alt-Tab to, but I've never seen a
window manager that does that and I lack the necessary expertise to
hack it into fvwm or some other window manager still being developed.
...Mike
--
Michael J. O'Connor | Internet: m...@jobone.srl.ford.com
Ford Motor Company, OPEO | UUCP: ...!fmsrl7!opeo!mjo
20000 Rotunda, Bldg. 1-3001 | Phone: +1 (313) 248-1260
Dearborn, MI 48121 | Fax: +1 (313) 323-6277
Casper H.S. Dik
>I think pointer focus is much better, as long as the window does not
>raise to front on focus. I cannot think of a reason in the world why
>you would prefer to click on a window to focus it. OpenWindows on
>the Sun (which I think everyone hates) requires the click. I go
>insane after a few minutes. SGI is now my main computer -- a default
>of pointer focus is one of the many small reasons why I like the
>system. I used to but no longer have the energy to change default
>X windows configurations -- if it feels broken (like the Sun) I just
>will not use it.
It's funny that you say that everyone hates OpenWindows.
Thus far I have met *far* more people who prefer OpenLook over
Motif than the otehr way around. People may not like Sun's
Xserver implementation, but since they dropped NeWS even that
works well. OpenLook does not require click-to-type.
It is the default, but it can be changed.
I have many more problems with Motif's defaults than with OWs
defaults.
I use one of the *twm window managers, which comes with
pointer-following and one of the reasons I hate macs
is click-to-type.
Casper
mathew
Robert J. Wilson <bwilson@hwhelp@fedex.msfc.nasa.gov> wrote:
>The experimental protocol should involve tanscribing text following
>instructions from a small window into a fixed number (7?) of fixed
>overlapping (25%?) windows.
It would also be interesting to see how machine load and general sloth
affected the results.
mathew
--
http://www.mantis.co.uk/~mathew/
Looking for: Bug-tracking systems for UNIX, DOS and Windows
Brian A. Mellor
|>
|> >In article <1994Jun19.1...@news.media.mit.edu> wa...@media.mit.edu (Michael B. Johnson) writes:
|> >>
|> >>Have any of these studies been published? I know of no one at the Media
|> >>Lab, for example, who prefers pointer focus, and there are plenty of people
|> >>here whose main computer is an SGI. I bop back and forth between NEXTSTEP
|> >>and my SGI, and I *hate* pointer focus.
|> >>
|> >>--> Michael B. Johnson -- wa...@media.mit.edu
|> >>--> MIT Media Lab -- Computer Graphics & Animation Group
|> >>--> 20 Ames St. E15-023G -- (617) 547-0563 (day office)
|> >>--> Cambridge, MA 02139 -- (617) 253-0663 (night office)
|>
|> I think pointer focus is much better, as long as the window does not
|> raise to front on focus. I cannot think of a reason in the world why
|> you would prefer to click on a window to focus it. OpenWindows on
|> the Sun (which I think everyone hates) requires the click. I go
|> insane after a few minutes. SGI is now my main computer -- a default
|> of pointer focus is one of the many small reasons why I like the
|> system. I used to but no longer have the energy to change default
|> X windows configurations -- if it feels broken (like the Sun) I just
|> will not use it.
|>
|> --Rob
|>
|>
get a result and write it in the lab book. As all devices are fighting for the same
real estate, the mouse invariably gets knocked. So, next time I come to type
something with a point to focus interface, I end up typing in the wrong window.
With a click to focus, I no longer have to co-ordinate, in real time, the mouse
and the keyboard.
I guess it all depends on environment, which was alluded to earlier today when
a poster detailed a series of experimental conditions to test the usability of
various schemes. Imagine trying to use a point to focus system on a small boat,
every time you take your hand off the mouse, it slides across the table, taking
the focus with it. However, in my limited experience of voice driven
workstations, it is apparent that point to focus is essential.
Horses for courses, I know, but you did say that you couldn't imagine any
scenarios for click to focus.
It could also be about machine control - with click to focus the user feels more
in control.
Cheers
Brian
Tom Horsley
able to pick different widgets to require click to focus and others to use
pointer focus.
When I'm using an application with lots of controls (in this case a
debugger), I've got buttons I can push as well as a command input window for
complex commands which don't map easily to buttons.
What I'd *like* to do is leave keyboard focus on the command window all the
time (so I can type a complex command without having to move the mouse or
click on the command input area), but I'd also like to be able to leave the
mouse over a commonly used button (single step, for instance) and click it
repeatedly.
If I use pointer focus, I have to move the mouse back to the command window
when I want to type a command. If I use click-to-focus, the stupid button
grabs the focus away from the command window whenever I click it.
I've tried both models and they both suck :-).
--
=============================================+======================
Tom Horsley email: taho...@csd.harris.com | Nuclear warning for
Harris snail: 511 Kingbird Circle | local residents!
Computer Systems Delray Beach, FL 33444 | Details at 11...
Eric J. Schwertfeger
: Then change it on the SGI! At least you can. I also presume the MIT
: Media Lab is also dominated by emacs users. I have a belief that many
: institutions develop common (yeah I know, there's always some rebels)
: preferences from the defaults and learning materials made available.
: I've had a few people mention how they hate the click-to-focus default
: in mwm but never take the time to change it. It's a very small sample
: but half didn't even know mwm could be changed to pointer-policy.
Agreed. There don't seem to be too many problems allowing it to be
user definable, I just wish more (Non-X) systems allowed it.
: Well to respond to you, I **HATE** click-to-focus!! (So there!
: Hrumph!) What really drives me nuts are platforms like the Macs, MS
: Windows, and OS/2 that don't have any way to change it.
pointer-policy annoys me, but I can live with it. On the Amiga, there were
several utilites to give the focus pointer-policy, but my big gripe was that
I don't want the mouse pointer over the window I'm working on, because
sooner or later, I have to work on something under the mouse, and wind up
moving the mouse. I did a hack on the Amiga that I'd love to see under an X
window manager. The mouse pointer would blank as soon as I pressed a key,
and wouldn't unblank until I moved the mouse. Unfortunately, I'm not an X
programmer yet (unless you count tcl/tk), so I don't know how to do this.
The other problem is mouse drift. My desk is never clean, and every once in
a while, the mouse pointer will slowly drift across the screen (or not so
slowly, if my cat is around), due to some papers pushing the mouse.
: One thing I've tended to see around here is that people weened on
Robert Andrew Ryan
"explicit.. Tom Hor...@ssd.csd.harr (1207)
> I find that what I want is a model that doesn't even exist. I want to be
> able to pick different widgets to require click to focus and others to use
> pointer focus.
Actually it does exist to some extent in the Andrew User Interface
System (aka Andrew and ATK). (I work with and design parts of it, so
note my bias :-) The normal focus model is that clicking in a widget
gives it the input focus. However the widget implementer can decide
whether and which mouse clicks on it should cause it to require the
input focus. For example our button widget accepts the focus only on a
right click, and a left click triggers the button. Unfortunately AUIS's
model currently lacks support for shifting input focus via the keyboard.
We plan to fix that fairly soon, and it should be supported in the next
public release. (after AUIS 6.3)
I believe applications should be designed to work with click-to-focus,
or pointer-focus for top-level windows and to use click-to-focus among
widgets interior to the top level. Careful consideration should be
given to each widget to decide whether it should request the input focus
for just any button click or only a particular one.
-Rob Ryan
Andrew Consortium
Keith Freedman
rsil...@media.mit.edu (Rob Silvers) writes:
>I think pointer focus is much better, as long as the window does not
>raise to front on focus. I cannot think of a reason in the world why
> you would prefer to click on a window to focus it. OpenWindows on
> the Sun (which I think everyone hates) requires the click. I go
> insane after a few minutes. SGI is now my main computer -- a default
> of pointer focus is one of the many small reasons why I like the
> system. I used to but no longer have the energy to change default
> X windows configurations -- if it feels broken (like the Sun) I just
> will not use it.
First of all, gross generalizations such as these are pretty absurd and
indicative of irrational and selfish tendancies. all that aside, when
bashing a product, such as OpenWindows, by claiming a lack of funcitonality,
it is probably a good idea to verify that the functionality doesn't exist.
In OpenWindows (i.e. olwm or olvwm) you can change the defaults via
edit .Xdefaults and then xrdb .Xdefaults (the xrdb isn't necessary
except for the first time) or use the properties menu option to set these.
Also, what I have, since I may wish to dynamically change the behavior
during a session, but not change it forever, is an added menu option in
my .openwin-menu:
"FlipDrag" FLIPDRAG
"FlipFocus" FLIPFOCUS
Flip Drag changes the dragging option (i.e. drag by showing a window frame
or by animating the entire window move--both are useful for different reasons).
Flip Focus changes the window focus option (i.e. click or pointer focus).
Tom Horsley <t...@ssd.csd.harris.com> wrote:
>I find that what I want is a model that doesn't even exist. I want to be
>able to pick different widgets to require click to focus and others to use
>pointer focus.
>
I agree wholeheartedly. It would be nice to be able to "Force Focus" on
a given window (perhaps through the window frame pull-down menu) and click
on other buttons. I believe, with olwm/olvwm, you are able to set click
to focus and choose a window--clicking buttons in another window doesn't
change focus, clicking the frame will. --I think - I'm using HP-VUE right
now - UGH! --
Keith freedman
--
Keith Freedman
Colorado State University
Department of Computer Science
sheldon White
>In article <1994Jun19.1...@news.media.mit.edu>,
(text deleted)
>Well to respond to you, I **HATE** click-to-focus!! (So there!
>Hrumph!) What really drives me nuts are platforms like the Macs, MS
>Windows, and OS/2 that don't have any way to change it.
>
I can't stand click-to-focus, and most people I've worked with use pointer focus
as well. The people I've known who like click-to-focus have tended to be
macintosh users.
>One thing I've tended to see around here is that people weened on
>click-to-focus have less problems shifting to pointer-focus than the
>other way around.
IMHO, that's because it's a more intuitive style of operation. :^)
However, I'm not really interested in long philosophical debates on the relative
merits of one or another. Like all semi-religious issues, it can never be fully
resolved...
-sheldon white- :^/
Jay Schmidgall
|> I don't want the mouse pointer over the window I'm working on, because
|> sooner or later, I have to work on something under the mouse, and wind up
|> moving the mouse. I did a hack on the Amiga that I'd love to see under an X
|> window manager. The mouse pointer would blank as soon as I pressed a key,
|> and wouldn't unblank until I moved the mouse.
There's an app out there called unclutter which does something very close
to this. Might be on the r5 contrib branch at ftp.x.org.
--
: jay j...@vnet.ibm.com My opinions and ideas, not my employer's.
: shmd...@rchland.vnet.ibm.com (c) Copyright 1994. All rights reserved.
: DNA. RNA. RDA?
Scott Byer
Tom Horsley writes:
Tom> I find that what I want is a model that doesn't even exist. I want to
Tom> be able to pick different widgets to require click to focus and others
Tom> to use pointer focus.
Tom> I've tried both models and they both suck :-).
I'd _really_ like "think-to-focus". The computer should be able to read my
mind as to where I want the characters to go. :-)
Barring that, I'd accept "look/blink to focus". It would at least be better
than some of the crummy mice they throw onto these systems (Hell is full of
optical mice :-). ((Heaven, of course, has nice, palm-sized trackballs as
an option) :-).
...
I find that the distinction between top window / focus window isn't enough.
Especially when some &#$^#& application pops a window to the top and steals
focus. I'd really like window focus to be follow-pointer, while keyboard
focus would be click. Of course, it would be nice to sometimes not have to
click to move keyboard focus. But that's only in special circumstances, and
when the moon is full, and...
(Knowing what sort of thrashing goes on inside window systems, I'll usually
put up with clicking.)
--
Scott Byer NeXTMail: by...@mv.us.adobe.com
Adobe Systems Incorporated These are *my* opinions, and
1585 Charleston Road, P.O. Box 7900 do not necessarily reflect
Mountain View, CA 94039-7900 the opinions of my employer.
=== ===
Trip Martin
>In article <1994Jun19.1...@jarvis.csri.toronto.edu>
>ruh...@turing.toronto.edu (Arthur Tateishi) writes:
>:I can even tell you why I (my opinions) like pointer-focus. Computer
>:displays are never big enough (I usually work at 1152x900 with 16-19"
>:monitors) and never have enough resolution. Therefore, windows tend to
>:overlap. However, a bit of care in placing windows usually allows me
>:to use various apps/xterms with partially obscured windows just fine.
>:Further, pointer-policy has fewer abrupt changes moving from app to
>:app and I still have the ability to "raise" my current window easily
>:enough if I have to. Keep in mind I also consider myself to be
>:mouse-impaired^H^H^H^H^H^H^H^Hchallenged especially when it comes to
>:clicking on small controls.
>I have the same problem. Since I exist in a Motif and MS-Windows
>environment for the most part, I use the Alt-Tab combination and
>hotkey through the various windows rather than take one of my hands
>OFF the keyboard to invoke the mouse. Only problem with that is,
>this only works with explicit focus. I'd love to have my mouse move
>within the same window that I Alt-Tab to, but I've never seen a
>window manager that does that and I lack the necessary expertise to
>hack it into fvwm or some other window manager still being developed.
TWM will do this. I use it all the time. The only problem is that
TWM won't recognize the Alt key as a modifier. :-(
Just do something like the following in your .twmrc:
"Tab" = m : all : f.warpring "next"
(this uses the meta key instead of the alt key)
--
Trip Martin ** Friends don't let friends eat meat
ni...@acm.rpi.edu **
Keith Freedman
>Excerpts from netnews.comp.windows.x: 20-Jun-94 Re: "pointer" vs.
>"explicit.. Tom Hor...@ssd.csd.harr (1207)
>
>> I find that what I want is a model that doesn't even exist. I want to be
>> able to pick different widgets to require click to focus and others to use
>> pointer focus.
>
>Actually it does exist to some extent in the Andrew User Interface
>System (aka Andrew and ATK). (I work with and design parts of it, so
>note my bias :-) The normal focus model is that clicking in a widget
>gives it the input focus. However the widget implementer can decide
>whether and which mouse clicks on it should cause it to require the
>input focus. For example our button widget accepts the focus only on a
>right click, and a left click triggers the button. Unfortunately AUIS's
>model currently lacks support for shifting input focus via the keyboard.
> We plan to fix that fairly soon, and it should be supported in the next
>public release. (after AUIS 6.3)
>
should be a window manager decision. The user should be able to decide
how THEY want the system to function. If the programmr decides this
functionality, then you have cases where certain programs behave differently
than other programs in the same setting. This seems bad.
---
Scott Raney
>I find that what I want is a model that doesn't even exist. I want to be
>able to pick different widgets to require click to focus and others to use
>pointer focus.
>When I'm using an application with lots of controls (in this case a
>debugger), I've got buttons I can push as well as a command input window for
>complex commands which don't map easily to buttons.
>What I'd *like* to do is leave keyboard focus on the command window all the
>time (so I can type a complex command without having to move the mouse or
>click on the command input area), but I'd also like to be able to leave the
>mouse over a commonly used button (single step, for instance) and click it
>repeatedly.
This is *exactly* the behavior that MetaCard gives you with explicit
focus. Since it is an active focus application, clicking in a window
(such as a menu bar or a tools palette) *doesn't* change the keyboard
focus. You can type new commands into the Message Box (MetaCard's
command-line interface) without having to reselect the Message Box
window after having pressed a button in another window.
This is *exactly* the behavior we're trying to encourage people to
use, and since it's impossible to support this with pointer focus, I
made the original posting asking for information to support this
design.
This topic has generated a lot of heat, but almost no light :-(
Back to the original question: does anyone know of any HCI experiments
in this area, or why the Motif and Open Look designers decided to make
explicit focus the default?
Scott
>=============================================+======================
>Tom Horsley email: taho...@csd.harris.com | Nuclear warning for
>Harris snail: 511 Kingbird Circle | local residents!
>Computer Systems Delray Beach, FL 33444 | Details at 11...
Bear Giles
>
>overlap. However, a bit of care in placing windows usually allows me
>to use various apps/xterms with partially obscured windows just fine.
As I read this, I'm switching between three windows. One (on top) is
my news reader, and two others (partially obscured) are windows into
two source directories where I'm trying to track down a nasty template-
related compiler.
Using pointer-focus, I can easily work in all three windows; if I get an
unexpected error message I can pop that window to the top but normally
I can do the necessary work in the 20-character wide space.
If I had to use click-to-focus, I couldn't read news as well -- it would
be too disruptive constantly having the various windows pop to the top
of the display.
You don't always need the extra functionality of pointer focus, but when
you need it, you *need* it. Click-to-focus just won't work.
--
Bear Giles
be...@fsl.noaa.gov
Robert Zawalski
>Here on my cluttered desk is a mouse and mat, a keyboard and a lab
>book. I type, get a result and write it in the lab book. As all
>devices are fighting for the same real estate, the mouse invariably
>gets knocked. So, next time I come to type something with a point to
>focus interface, I end up typing in the wrong window. With a click to
>focus, I no longer have to co-ordinate, in real time, the mouse and
>the keyboard.
Try running an emacs and view some file you call 'log' or such. Leave
only the bottom line or so exposed. Position this window to your
favorite (default) mouse-pointer position so you can very easily paste
whatever "result" you would otherwise document to a lab book.
This should be good so long as you're not doing things that might
break your kernel or file-system. If so, you'll want the lab book I
suppose :-)
>I guess it all depends on environment, which was
>alluded to earlier today when a poster detailed a series of
>experimental conditions to test the usability of various schemes.
>Imagine trying to use a point to focus system on a small boat, every
>time you take your hand off the mouse, it slides across the table,
>taking the focus with it. However, in my limited experience of voice
>driven workstations, it is apparent that point to focus is
>essential. Horses for courses, I know, but you did say that you
couldn't imagine any scenarios for click to focus. It could also be
>about machine control - with click to focus the user feels more in
>control.
Good points Brian, but for these most unusal circumstances perhaps the
user should be expected to switch to the normally needlessly awkward
'click-to-focus' mode ? Should we all be prepared for rough seas at
our desks ? I still have fortran_77 for the Atari ST on a floppy
somewhere in case the need should arise :-)
Idle speculation:
Under a voice driven system, would one not address the windows and
other objects by their names (or aliases), saying things like "append
lines five six seven from newswindow to best-of-news" (eg. an iconified
emacs buffer) ?
We have objects on our screens with names, the vocal shell should have
access to the window manager and deal with them by name.
bob zawalski bo...@crl.com
Robert Zawalski
>I find that what I want is a model that doesn't even exist. I want to be
>able to pick different widgets to require click to focus and others to use
>pointer focus.
<< example deleted >>
>What I'd *like* to do is leave keyboard focus on the command window all the
>time (so I can type a complex command without having to move the mouse or
>click on the command input area), but I'd also like to be able to leave the
>mouse over a commonly used button (single step, for instance) and click it
>repeatedly.
Here's how I see it:
Some windows are editable, and others are merely selectable. Focus
should NOT be affected by making positioning the mouse cursor over a
merely 'selectable' window that is a child of an editable window. I'm
not an X programmer, so I'm unaware of an "attribute" or "context"
variable which might be exploited to allow a window manager to make
the necesary distinction. If such an attribute (eg unsigned short
followable-by-window-manager) doesn't exist then the widgets would
have to be re-written to somehow identify the previous "focus" and to
force focus back ... . Either way, the bulk of X apps would need
re-writing since window manager authors would surely have implemented
this already had widget programmers set such attribute variables :-(
>If I use pointer focus, I have to move the mouse back to the command window
>when I want to type a command. If I use click-to-focus, the stupid button
>grabs the focus away from the command window whenever I click it.
The current work-around is to hope that "hot-keys" have been
implemented in your favorite applications.
>I've tried both models and they both suck :-).
>--
Yes, but better to have this "extra-click" problem only within several
applications than to live with it constantly :-)
bob zawalski bo...@crl.com Small Crusade: Use getit or angeftp
rather than plodding interactively
with ftp. Encourage archivists to
supply: find . -print >INDEX files.
Torgeir Veimo
|> Tom Horsley <t...@ssd.csd.harris.com> wrote:
|> >I find that what I want is a model that doesn't even exist. I want to be
|> >able to pick different widgets to require click to focus and others to use
|> >pointer focus.
|> >
|> I agree wholeheartedly. It would be nice to be able to "Force Focus" on
|> a given window (perhaps through the window frame pull-down menu) and click
|> on other buttons. I believe, with olwm/olvwm, you are able to set click
|> to focus and choose a window--clicking buttons in another window doesn't
|> change focus, clicking the frame will. --I think - I'm using HP-VUE right
|> now - UGH! --
Why don't someone pick this up and implement a function in ones favourite
window manager called eg. 'force_focus()'. In this way the window manager could
be set up to add a button-decoration or a key/mouse combination to get a
window into 'force focus' mode, where the general focus is on the 'forced
window' while one can use the mouse outside the window for selecting text or
pressing buttons. The 'forced focus' could easily be deselected by having
another function called 'free_focus()'.
If this was implemented in fvwm, I would suggest using some crtl/meta/alt
button in combination with the left button, making the top bar depressed
continuously while in force focus mode, while deselecting force focus would
be done simply by clicking with the mouse on the top bar, making it pop out
again.
This would give metacard developers what they want, making it possible to
select tools from the palette menu, while still having the keyboard focus in
the main window.
Hey, why don't metacard develop such an extension themselves and give it to
us, if they are so eager to have their app. work both in pointer- and
explicit focus environments.
It wouldn't take more than to make shure that all apps not having the focus
receive a EnterNotify/FocusEnter and a LeaveNotify/FocusLeave before and
after the mouse button event. (Ok, maybe this isn't just a simple window
manager extension...)
This would solve the problem, wouldn't it?
Torgeir @ http://www.ii.uib.no/~torgeir/
Hans de Graaff
>Agreed. There don't seem to be too many problems allowing it to be
>user definable, I just wish more (Non-X) systems allowed it.
There is a program for MS-Windows called WinX which allows point-to-focus
with MS-Windows.
>pointer-policy annoys me, but I can live with it. On the Amiga, there were
>several utilites to give the focus pointer-policy, but my big gripe was that
>I don't want the mouse pointer over the window I'm working on, because
>sooner or later, I have to work on something under the mouse, and wind up
>moving the mouse.
There is a program called unclutter which does this. Get it from
ftp.twi.tudelft.nl:/pub/unix/X11/unclutter.tar.gz
BTW, I'm a point-to-focus man myself.
Hans
--
Hans de Graaff J.J.de...@TWI.TUDelft.NL
Delft University of Technology Department of Information Systems
-----------------------------------------------------------------------
<a href=http://www.twi.tudelft.nl/People/J.J.deGraaff.html>WWW link</a>
Jay Schmidgall
|> Using pointer-focus, I can easily work in all three windows; if I get an
|> unexpected error message I can pop that window to the top but normally
|> I can do the necessary work in the 20-character wide space.
|>
|> If I had to use click-to-focus, I couldn't read news as well -- it would
|> be too disruptive constantly having the various windows pop to the top
|> of the display.
Hmmm. Seems to me I can do the same thing whether I have
focus-follows-pointer or click-to-focus. Whether or not I have to click
to get focus in a window doesn't affect whether or not I can type in that
twenty character space without raising the window.
On the other hand, if you had focus-auto-raise on, I could sort of see
your point, but not entirely.
Peter Shenkin
>t...@ssd.csd.harris.com (Tom Horsley) writes:
>>What I'd *like* to do is leave keyboard focus on the command window all the
>>time (so I can type a complex command without having to move the mouse or
>>click on the command input area), but I'd also like to be able to leave the
>>mouse over a commonly used button (single step, for instance) and click it
>>repeatedly.
>
>This is *exactly* the behavior that MetaCard gives you with explicit
>focus. Since it is an active focus application, clicking in a window
>(such as a menu bar or a tools palette) *doesn't* change the keyboard
>focus....
A question: if clicking in a window doesn't change the keyboard focus
to that window, then how DO you change the keyboard focus to a window?
I thought the definition of explicit focus is that clicking in a window
changes the focus to that window; this is the way the Mac works,
doesn't it? What am I missing?
>This topic has generated a lot of heat, but almost no light :-(
>Back to the original question: does anyone know of any HCI experiments
>in this area, or why the Motif and Open Look designers decided to make
>explicit focus the default?
I'm not sure this is the best way to cast light on the matter. Perhaps
we can ask: what could be done in a pointer focus environment to
enable the behavior you want?
It would have to be something that allowed you to make a text window
"sticky"; then there would have to be some method to deselect it.
Imagine the following, then.
With pointer focus, a text window becomes active when the mouse pointer
is in it. Suppose you then set things up so that if you click the mouse
in the window, it becomes sticky; you would want to make it change color,
or border, or something, too, so the user would know it's sticky. To
deselect it, the user would have to click in it again; this would
return him to the normal pointer focus. As a second deselection method,
the user might be able to change the keyboard focus selection to a
new text window by clicking in the text window of another MetaCard
widget supporting the same method.
One can imagine other mechanisms as well for making a given window
"sticky" temporarily in a pointer focus environment; for example,
holding the shift-key down could be used. The shift-lock key could
then be used to make this a toggle. This is the method that SGI's
Snapshot program uses; it works fine.
Or if you don't want to use the shift key or the mouse, use one of the
function keys, or some escape sequence.
Thus I would contest your conclusion that the behavior you would
like to present is "impossible" in a pointer-focus environment.
-P.
--
********** After the revolution, everyone will have a home page... **********
Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
New York, NY 10027; she...@still3.chem.columbia.edu; (212) 854-5143
***** (... but the Internet will be too busy for anyone to access it.) ******
Dick Schoeller
Smileys aside. The first example is a classic measure of the effectiveness
of a UI technique. The latter is a measure designed to favor a particular
technique and to disregard the bottom (ie: productivity).
Without doing actual measurements, we can look at some of the arguments in
favor of each.
For pointer:
1) Fewer actions to change focus.
2) Possibly, less accuracy of motion to change focus.
3) Don't have to worry about moving the insertion cursor when clicking in
a text window.
For explicit:
1) Don't have to leave the pointer obscuring your text input window.
2) Don't have to go to the mouse to point at new dialog boxes when they
popup (big complaint that I have with default behavior of Mosaic).
3) Don't have the pointer based focus interfering with keyboard based focus.
For any given user/environment/appliction you are likely to find that the
factors for one outweigh the other. Without specific measurement it becomes
impossible to judge.
The advantage of a customizable system (Motif or OpenLook vs. Windows or Mac)
is to take advantage of preferences or learned habits of specific users.
Especially important for users that are switching regularly among environments.
Thus it should be obvious that in Motif, all applications should function
correctly in either model. It might be the case that certain behaviors are
not as convenient in one model or the other, but that is a given.
Dick Schoeller
Dr. William E. Willis
|>Path: taco.cc.ncsu.edu!gatech!howland.reston.ans.net!spool.mu.edu!sdd.hp.com!col.hp.com!csn!qwerty.fsl.noaa.gov!bora.fsl.noaa.gov!bear
|>From: be...@bora.fsl.noaa.gov (Bear Giles)
|>Subject: Re: "pointer" vs. "explicit/click-to-type" keyboard focus policy
|>Message-ID: <1994Jun21.0...@fsl.noaa.gov>
|>Sender: ne...@fsl.noaa.gov (USENET News System)
|>Organization: Forecast Systems Labs, NOAA, Boulder, CO USA
|>References: <2u00s5$i...@gazette.esd.sgi.com> <1994Jun19.1...@news.media.mit.edu> <1994Jun19.1...@jarvis.csri.toronto.edu>
|>Date: Mon, 20 Jun 94 23:42:04 GMT+5:00
|>Lines: 25
|>Xref: taco.cc.ncsu.edu comp.windows.x:84606 comp.windows.misc:6859 comp.human-factors:9085 comp.sys.sgi.apps:4071 comp.sys.sgi.misc:11031
Explicit click to focus has absolutely nothing to do with which window is on
top. I use explicit focus policy but I can click on a covered window and give
it focus without raising the window.
Here are the resources I use:
Mwm*autoKeyFocus: True
Mwm*focusAutoRaise: False
Mwm*deiconifyKeyFocus: True
Mwm*enforceKeyFocus: True
Mwm*keyboardFocusPolicy: explicit
Here are the button bindings for mwm...
Buttons DefaultButtonBindings
{
<Btn1Click2> icon f.normalize
<Btn1Down> frame f.raise
<Btn1Down> icon f.move
<Btn2Down> root f.menu AppMenu
<Btn2Down> icon f.post_wmenu
<Btn2Down> frame f.raise
<Btn3Down> root f.menu MgrMenu
<Btn3Down> icon f.post_wmenu
<Btn3Down> frame f.lower
Meta<Btn1Down> window|icon f.post_wmenu
Meta<Btn2Down> window|icon f.raise
Meta<Btn3Down> window|icon f.lower
}
As you can see, you have to click on the frame of a window to raise it. Any
click inside of a window will give focus to that application and it will
remain despite mouse movement. That means you can pick up a piece of paper and
move the mouse without loosing focus. Better yet, when a dialog pops up for
you to type into, you do not have to reach for the mouse....
Bill Willis
--
Dr. William E. Willis
Stephen Baynes
: I'm looking for studies comparing "pointer" focus policy (where moving
: the mouse in to a window gives that window the keyboard focus) with
: "explicit" (also called "click-to-type" where the user must click on
: the window to begin typing in it). A history of this issue would also
: be useful.
: As you may know, the old SunView and Apollo Domain systems both used
: pointer focus. Almost all other systems (e.g. Mac, Windows, NeXTstep,
The apollo also moved the text cursor automatically to the mouse cursor
in the text editor. [Effectivly there was only one cursor.]
: Motif, OpenLook) use explicit focus. The only references I've found
: regarding this issue are in the Motif and OpenLook documentation (both
: of these UI styles support pointer focus, though they aren't set up
: that way by default). Unfortunately, the documentation is
: non-judgemental nor does it even mention the pros or cons of the two
: policies. Anybody know why most of the vendors chose to use explicit
: focus?
: Silicon Graphics is the only OEM to deliver workstations configured
: with pointer focus by default, and I'm looking for references that
: will help me to convince them to join the rest of the world's program.
: I believe this switch is in the best interests of both users, who will
: probably have to use other types of systems, and of developers, who
: have problems supporting both policies.
-snip-
Tell them to keep it and get the rest of the world to change to use pointer
focus - its much more natural. I _hate_ explicit focus. However the apollo
moving the text cursor to match the mouse cursor in a text editor can be an
irritation sometimes.
--
Stephen Baynes bay...@mulsoc2.serigate.philips.nl
Philips Semicondutors Ltd
Southampton My views are my own.
United Kingdom
Grant Edwards
: ruh...@turing.toronto.edu (Arthur Tateishi) writes:
: >Therefore, windows tend to
: >overlap. However, a bit of care in placing windows usually allows me
: >to use various apps/xterms with partially obscured windows just fine.
: As I read this, I'm switching between three windows. One (on top) is
: my news reader, and two others (partially obscured) are windows into
: two source directories where I'm trying to track down a nasty template-
: related compiler.
: Using pointer-focus, I can easily work in all three windows; if I get an
: unexpected error message I can pop that window to the top but normally
: I can do the necessary work in the 20-character wide space.
: If I had to use click-to-focus, I couldn't read news as well -- it would
: be too disruptive constantly having the various windows pop to the top
: of the display.
I work the same way (several actively used but paritally obscured
windows), and when I first switched from SunOS 4.1.3 to 5.2 (and
hadn't installed _my_ window manager) the "click-to-focus" business
drove me nuts. The click-to-focus itself wasn't the problem it was
that when I wanted to focus on a window, it raised the window to the
top. I had the windows where I wanted them dammit - I'm not stupid! I
just wanted to type stuff into them, but I couldn't without them
constantly popping forward. It was _tres_ annoying. I only suffered
long enough to get fvwm compiled and installed. Now all my computers
act and look the same (SunOS 4.1.3, SunOS 5.2, and three machines
running two different distributions of Linux).
Sheesh -- between home and office and lab I've got five computers
running Unix that talk to each other using various combinations of
ehternet, slip, uucp, modems and one cellular phone. Do I qualify for
some kind of geek award or what?
--
Grant Edwards |Yow! Do I have a lifestyle
Rosemount Inc. |yet?
|
gra...@rosemount.com |
Michael Stegbauer
|>
|> I personally hate the explict focus policy, and prefer pointer focus,
|> but them I'm an old fart, who grew up with ascii terminals ;)
|> --
|>
|> The most beautiful things in the world are | Dave Olson
|> those from which all excess weight has been | Silicon Graphics
|> removed. -Henry Ford | ol...@sgi.com
Well, I'm a young fart, who grew up with a 4D35TG :) and I don't particularly
care for explicit focus either. Just one more button to press!
The only problem I have with pointer focus is the "can't see what you're
typing" feature (and my typing sucks) which is why I use AutoRaise.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Michael Stegbauer - MikeS - stegbau...@tandem.com - formerly mikesteg
Tandem On-Line Support Center, Austin, TX - TNSC UNIX Support Analyst
1992 Laser RS AWD, Red - 1993 750 Nighthawk, Blue - trekkie(TOS,TNG,DS9,V)
"A good pointer focus policy is what separates us from the animals"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Cooney
> I've tried both models and they both suck :-).
One thing I haven't seen mentioned is that you can force one window to
have the focus in an implicit-focus environment. In my .twmrc:
RightTitleButton ".focus.icon" = f.focus
clicking on this button forces focus to stay on the button until I click
on it again. I'm not sure how to do this in other windowing environments,
unfortunately.
-Kevin
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Kevin W. Cooney |
coo...@cmu.edu | http://www.contrib.andrew.cmu.edu:8001/usr/kc2z/home
Graeme Gill
>In article <CrpMD...@yuma.ACNS.ColoState.EDU>, free...@CS.ColoState.EDU (Keith Freedman) writes:
>|> Tom Horsley <t...@ssd.csd.harris.com> wrote:
>|> I agree wholeheartedly. It would be nice to be able to "Force Focus" on
>|> a given window (perhaps through the window frame pull-down menu) and click
>|> on other buttons. I believe, with olwm/olvwm, you are able to set click
>|> to focus and choose a window--clicking buttons in another window doesn't
>|> change focus, clicking the frame will. --I think - I'm using HP-VUE right
>|> now - UGH! --
>Why don't someone pick this up and implement a function in ones favourite
>window manager called eg. 'force_focus()'. In this way the window manager could
Gee, even this ancient twm window manager already has this feature -
"Focus Input" and "Unassign focus"
from a .twmrc file:
menu "button1"
{
"Focus Input" f.focus
"Unassign Focus" f.unfocus
}
Graeme Gill.
Dick Schoeller
orthogonal behaviors. You can have click-to-focus in mwm without pop-to-top.
One way to do this is to set things up so that the pop only happens if you
click on the border, but focus change happens either from a border click or
in the window.
The strongest arguments for pointer focus are not the pop-to-top arguments
but rather 1) the other side effects of clicking (like moving the insertion
point) and 2) the extra actions in explicit focus possibly slowing the user
down or increasing the error rate.
Note that noone has yet pointed to a published study indicating that item 2
is indeed the case. Have any such studies been done? Are they public?
Dick Schoeller
Arthur Tateishi
Peter Shenkin <she...@still3.chem.columbia.edu> wrote:
>In article <raney.772164751@teal>, Scott Raney <ra...@teal.csn.org> wrote:
>>This is *exactly* the behavior that MetaCard gives you with explicit
>>focus. Since it is an active focus application, clicking in a window
>>(such as a menu bar or a tools palette) *doesn't* change the keyboard
>>focus....
>
>A question: if clicking in a window doesn't change the keyboard focus
>to that window, then how DO you change the keyboard focus to a window?
>I thought the definition of explicit focus is that clicking in a window
>changes the focus to that window; this is the way the Mac works,
>doesn't it? What am I missing?
I believe the idea is that windows that don't accept Key events should
not get the keyboard focus or cause the focus to change under
click-to-focus. However, then I don't see how keyboard traversals would
work.
Arthur Tateishi
Jay Schmidgall <j...@vnet.ibm.com> wrote:
>In article <1994Jun21.0...@fsl.noaa.gov>, be...@bora.fsl.noaa.gov (Bear Giles) writes:
>|> Using pointer-focus, I can easily work in all three windows; if I get an
>|> unexpected error message I can pop that window to the top but normally
>|> I can do the necessary work in the 20-character wide space.
>|>
>|> If I had to use click-to-focus, I couldn't read news as well -- it would
>|> be too disruptive constantly having the various windows pop to the top
>|> of the display.
Sounds like he's on my side but a little confused.
>Hmmm. Seems to me I can do the same thing whether I have
>focus-follows-pointer or click-to-focus. Whether or not I have to click
>to get focus in a window doesn't affect whether or not I can type in that
>twenty character space without raising the window.
>On the other hand, if you had focus-auto-raise on, I could sort of see
>your point, but not entirely.
Yes. He was assuming raise-on-focus. This harkens back to what I said
about default environments and not RTFM. Alternatives are often not
widely known. I may dislike the default behaviour of mwm but I've gone
throught the man page and understand it has a lot of flexibility and
have changed my setup accordingly. It seems various MSWin stuff like
WinX and unclutter help out Windoze users. I still haven't seen any
champions for my cause (pointer-focus) under OS/2. What about the Mac,
too?
Perhaps instead of bickering at each other, we should all lobby
inflexible systems to allow adequate customization.
Andy_Witterick
of HCI was to design to allow the user to work in the way that they found most
suitable to the task in hand, all other things being equal. Then surely whether
the pointer focus should be explicit or not should be left to the user, i.e. it
ought to be customisable. This is the way Sun's openwindows and X works,
unfortunately microsoft Windows gives one no choice and I can't speak about the
Mac.
Andy
Dan Janowski
>I'm looking for studies comparing "pointer" focus policy (where moving
>the mouse in to a window gives that window the keyboard focus) with
>"explicit" (also called "click-to-type" where the user must click on
>the window to begin typing in it). A history of this issue would also
>be useful.
>
>Silicon Graphics is the only OEM to deliver workstations configured
>with pointer focus by default, and I'm looking for references that
>will help me to convince them to join the rest of the world's program.
>I believe this switch is in the best interests of both users, who will
>probably have to use other types of systems, and of developers, who
>have problems supporting both policies.
Be careful here. I have worked with both explicit-focus and pointer-focus
window systems and from my POV the pointer-focus systems are FAR superior.
I have found that doing CG production work typically involves more than
five windows or applications at a time. The point to focus policy is really
fast and avoids having to place the hand on the mouse in such a way as to
be able to hit the mouse button. In addition, a bunch of GUI apps on a
screen work really well together with pointer-focus, just move the pointer
to the button or slider, etc and do what you want. An explicit system
would require another step of establishing focus and then doing the
work.
Mice and GUIs are enough of a pain (like typing with one finger) but
to add another operation to every focus change seems insane to me.
IMHO the explicit-focus approach should go away.
Dan
David Friedlander
>This works very well for me in .Xdefaults:
>OpenWindows.SetInput: followmouse
>The PROPERTIES menu item will also get you there.
And for those of us regular OpenWindows users who occasionally use
Motif-based systems:
Mwm*keyboardFocusPolicy: pointer
Ernie Pittarelli 301-794-2032 S833
>In article <TOM.94Ju...@amber.ssd.csd.harris.com>,
>rsil...@media.mit.edu (Rob Silvers) writes:
>
> <stuff deleted>
>
>First of all, gross generalizations such as these are pretty absurd and
>indicative of irrational and selfish tendancies. all that aside, when
>bashing a product, such as OpenWindows, by claiming a lack of funcitonality,
>it is probably a good idea to verify that the functionality doesn't exist.
>
>In OpenWindows (i.e. olwm or olvwm) you can change the defaults via
>edit .Xdefaults and then xrdb .Xdefaults (the xrdb isn't necessary
>except for the first time) or use the properties menu option to set these.
>Also, what I have, since I may wish to dynamically change the behavior
>during a session, but not change it forever, is an added menu option in
>my .openwin-menu:
Which brings up another point. Why should the user have to fool with
.Xdefaults files and resource names at all? Any proper window manager
should also be delivered with the capability to change these settings from
a user preferences menu. An example that comes to mind is the DECwindows Motif
menu that comes up when you press the right mouse button. DEC may not be the
popular choice anymore, but at least they don't expect the user to have to
edit invisible resource files to change a simple focus policy setting!
Oh, and by the way, my vote is for pointer focus without auto-raise.
Ernie Pittarelli
---------------------------------------------------------------------
When will the Unix world abandon vi for a standard mouse-based editor???
---------------------------------------------------------------------
Jim Cathey
>What I'd *like* to do is leave keyboard focus on the command window all the
>time (so I can type a complex command without having to move the mouse or
>click on the command input area), but I'd also like to be able to leave the
>mouse over a commonly used button (single step, for instance) and click it
>repeatedly.
You can do this under NeXTSTEP. Generally it is a click-focus-and-raise
system (which I prefer, since my desk is messy and mouse knocks are a
fact of life), but at least some buttons in some windows can be actuated
without bringing them to the front.
Mouse clicks can probably be assumed to always be deliberate, but mouse
moves can't always be. On the Mac, buttons that can't be actuated in
the background are supposed to be greyed out so that it is apparent they
can't operate. Possibly annoying, but at least there should be few
ugly surprises. (There seems to be a theme there!)
I suppose there are really lower-level terms needed here? Not focus,
but raising, keyboard focus, TE selection. Maybe more. Your ideal
will be some combination of behaviors.
The NeXTSTEP interface mostly pleases me, being somewhat Mac-like. The
only thing I wished it had is what _my_ window manager has, which is a
means from the keyboard to move keyboard focus. The one I use most
swaps the two frontmost windows (raises #2) and switches keyboard focus
to the raised window. It's suprising how often that's all I need, and
it's very quick to type. NeXTSTEP lets you raise windows from the
keyboard, but you still need to hit the mouse to move the keyboard
focus. Annoying.
Disclaimer: I don't use X or Windoze anyway, nor do I want to.
--
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC-Bunker Ramo
! II CC ! TAF-C8; Spokane, WA 99220
! IISSSS CC ! UUCP: uunet!isc-br!jimc (ji...@isc-br.isc-br.com)
! II CCCCCC ! (509) 927-5757
Robert Brodersen
The worst aspect of click-to-type focus policy is that in some
implementations (ms windows) the application actually consumes the
activation click! Boy what a pain. It is bad enough that I have to
click the mouse button (as opposed to just moving it a bit), now I
have to find a safe place to click! Since most locations in the
application are sensitive to mouse clicks, the best spot is the title bar.
This is an awfully small region to be aiming at though, and I often miss!
Sigh. If ms weren't such a dominant player, I would boycott their
system entirely! I wonder if Chicago will change (fix) this policy!
--
Thanks- rbro...@oracle.com -Bob Brodersen (415)-506-2189
Applications Architect, Applications Technology Group, Applications Division
Oracle Corporation, Redwood Shores, CA 94065
Scott Raney
>In article <raney.772164751@teal>, Scott Raney <ra...@teal.csn.org> wrote:
>>t...@ssd.csd.harris.com (Tom Horsley) writes:
>>>What I'd *like* to do is leave keyboard focus on the command window all the
>>>time (so I can type a complex command without having to move the mouse or
>>>click on the command input area), but I'd also like to be able to leave the
>>>mouse over a commonly used button (single step, for instance) and click it
>>>repeatedly.
>>
>>This is *exactly* the behavior that MetaCard gives you with explicit
>>focus. Since it is an active focus application, clicking in a window
>>(such as a menu bar or a tools palette) *doesn't* change the keyboard
>>focus....
>A question: if clicking in a window doesn't change the keyboard focus
>to that window, then how DO you change the keyboard focus to a window?
>I thought the definition of explicit focus is that clicking in a window
>changes the focus to that window; this is the way the Mac works,
>doesn't it? What am I missing?
MetaCard is an "active focus" application. Whether or not a window
gets the focus when a control inside it is clicked on is decided by
the control, not the window manager. If you click on an editible
field, it will ask the window manager for the focus. If you click in
a non editable field or on a button with keyboard traversal disabled,
it won't.
Of course, you can always set the focus to any window by clicking in
the border.
"active focus" is supported by both mwm and olwm in explicit focus
mode, but can't be supported (barring a major rewrite of these window
managers) in pointer focus mode. Applications of this type are very
rare, because the Xt/Motif and Open Look toolkits don't support this
behavior. It is a very useful design however: many applications on
the Mac and MS-Windows have equivalent functionality.
> -P.
>--
>********** After the revolution, everyone will have a home page... **********
>Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
>New York, NY 10027; she...@still3.chem.columbia.edu; (212) 854-5143
>***** (... but the Internet will be too busy for anyone to access it.) ******
Keith Freedman
>I'll add my vote for pointer keyboard focus policy!
>
>system entirely! I wonder if Chicago will change (fix) this policy!
It's people not boycotting their stupid systems that's made them
such a dominant player. I say, "Do you're part to get rid of them
and let someone with a more user oriented view step in" and boycott
'em anyways. You can get Solaris or NeXTStep or Linux for intel machines
and do your work your way instead of gates way.
Stepping off my soap box, :)
---
Keith Freedman
Colorado State University
Department of Computer Science
Peter Castine
>
> I cannot think of a reason in the world why
>you would prefer to click on a window to focus it.
Because, if the mouse gets moved for any reason whatsoever, all
keyboard input goes to never-never land (or from the newsreader
to the console window).
God, I *hate* pointer focus. Hate, hate, hate. I'll bet the computer
used by the devil in the Simpsons has pointer focus.
Sorry, had to get that out of my system.
--
Peter Castine | Dr. Who quote du jour:
pcas...@prz.tu-berlin.de | Have you noticed the way people's
===========================| intelligence capabilities decline sharply
``Have Mac, will travel'' | the minute they start waving guns around?
Mark Dobie
>MetaCard is an "active focus" application. Whether or not a window
>gets the focus when a control inside it is clicked on is decided by
>the control, not the window manager. If you click on an editible
>field, it will ask the window manager for the focus. If you click in
>a non editable field or on a button with keyboard traversal disabled,
>it won't.
>Of course, you can always set the focus to any window by clicking in
>the border.
>"active focus" is supported by both mwm and olwm in explicit focus
>mode, but can't be supported (barring a major rewrite of these window
>managers) in pointer focus mode. Applications of this type are very
>rare, because the Xt/Motif and Open Look toolkits don't support this
>behavior.
I'm still not sure I understand the problem here. I write Open Look
applications using xview and I run them under olvwm in pointer focus
mode.
If I have a panel and I move the mouse into it the keyboard focus goes
to the first editable field in the panel. When I press keys they go to
the text item (or whatever it is). If I click on a checkbox or move a
slider and then press keys, they still go to the text item. I can
change the keyboard focus to another editable field by clicking on it
(or I can use TAB).
Basically, anytime that panel has the focus (ie the mouse is over it)
keypresses will go to an editable field, even if you last clicked on
a button. Is that what you want?
Presumably this is part of Open Look, but I don't know if it is
implemented by other Open Look toolkits.
Mark
PS I agree that the behaviour of, say, xxgdb where clicking on a button
takes focus from the command line is awkward, but not enough to make me
use click to type focus selection :)
--
Mark Dobie MS Windows? Linux and X!
University of Southampton M.R....@ecs.soton.ac.uk
Alessandro Forghieri
In article <Crr4s...@ukpsshp1.serigate.philips.nl> bay...@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
: Silicon Graphics is the only OEM to deliver workstations configured
: with pointer focus by default, and I'm looking for references that
: will help me to convince them to join the rest of the world's program.
: I believe this switch is in the best interests of both users, who will
: probably have to use other types of systems, and of developers, who
: have problems supporting both policies.
-snip-
Tell them to keep it and get the rest of the world to change to use pointer
focus - its much more natural. I _hate_ explicit focus. However the apollo
moving the text cursor to match the mouse cursor in a text editor can be an
irritation sometimes.
By all means. I hate explicit focus, too - I find it very handy to
have the capability to type a few commands in an xterm which is partly
obscured by some large, graphical window without having to pop that
window on top. Comparisons to the Windows environment are not to the
poin IMHO - every window app. has to carry around its whole user
interface, but under Unix I use a lot of applications who use both a
graphical window and a CLI (e.g., gnuplot). So I say, down with explicit
focus - and anyway, why discussing this at all, if one can configure
the thing to its liking? I feel a religion war approaching.....
Regards
Alessandro Forghieri
--
Alessandro Forghieri
Control Data Italy phone: ++39 2 2174253
Palazzo Bernini Milano 2 fax: ++39 2 26414187
20090 Segrate (MI), ITALY email: a...@orchid.cdi.cdc.com
Christoph Weber
: In article <1994Jun19.2...@news.media.mit.edu>,
: Rob Silvers <rsil...@media.mit.edu> wrote:
: >I think pointer focus is much better, as long as the window does not
: >raise to front on focus. I cannot think of a reason in the world why
: >you would prefer to click on a window to focus it. OpenWindows on
: >the Sun (which I think everyone hates) requires the click. ...
: This works very well for me in .Xdefaults:
: OpenWindows.SetInput: followmouse
: The PROPERTIES menu item will also get you there.
: --
: Jerry Natowitz - j...@spdcc.com
Yeah, what we really need are *nice*, easy-to-use tools to change defaults.
Most users will not change them, if they have to edit obscure files.
I second various other users that once you use pointer focus, you're hooked.
I certainly am.
Any application that will not work nicely under either regime is a pain.
I hope this does not insult the original poster.
--
Christoph Weber email: cwe...@oci.unizh.ch
OCI Uni Zurich phone: +41 1 257 4925
Winterthurerstr. 190 FAX: +41 1 361 9895
CH-8057 Zurich, Switzerland
der Mouse
> moving the mouse in to a window gives that window the keyboard focus)
> with "explicit" (also called "click-to-type" where the user must
> click on the window to begin typing in it).
As usual, you can get whatever results you want out of such studies by
choosing your favorite set of metrics and conditions. For example:
"pointer" will win if your metric is "operations required to transfer
focus"; "explicit" will win if your metric is "usability when the mouse
continually gets randomly bumped". Both of these are metrics I've seen
people cite on the net as explanations for their preferences.
Personally, I don't like either style; having to take my hands off the
keyboard to switch windows is unacceptable to me.
der Mouse
der Mouse
> would be too disruptive constantly having the various windows pop to
> the top of the display.
You're confusing click-to-focus with click-to-focus-and-raise.
der Mouse
David Bell
|> ra...@teal.csn.org (Scott Raney) writes:
|> | Silicon Graphics is the only OEM to deliver workstations configured
|> | with pointer focus by default, and I'm looking for references that
|> | will help me to convince them to join the rest of the world's program.
|> | I believe this switch is in the best interests of both users, who will
|> | probably have to use other types of systems, and of developers, who
|> | have problems supporting both policies.
|>
|> been hashed out internally to SGI many times, and it is *extremely*
|> unlikely we will change the default as shipped. It provides
|> compatibility with our earlier releases, and all of our usability
|> tests (that I know of) have confirmed that people prefer the pointer
^^^^^^^^^^^^^^^^^^^^^^^^^
|> focus.
^^^^^
Most definitely - the first thing that I do when I am getting started
on a new system is change the focus to follow the pointer; I really
hate to have to press the mouse button just to start working in
a window. I can move the mouse much more quickly than I can move the
mouse and push the mouse button. Likewise, most (all?) of my
associates have also changed their environments to pointer focus. I
applaud SGI for being the ``only OEM to deliver workstations configured
with pointer focus by default.''
|>
|> | Our problems are specifically related to our "active-focus"
|> | application, which doesn't work very well in a pointer focus
|> | environment. There are two big problems running MetaCard in a pointer
|> | focus environment. ...
|> | ... This architecture works
|> | great in an explicit focus environment, but doesn't in a pointer focus
|> | environment since the window manager jerks the focus away from a
|> | window even when there is no point in doing so.
|>
|> So tell customers who want your product/app to change the focus policy.
|> That's not unreasonable, if they want it, and if it's necessary to the
|> design (and you don't want to change it).
|> --
|>
I wouldn't necessarily say it isn't unreasonable. If I come across
a piece of software that makes me change my environment (which I have
spent years perfecting to suit my needs/tastes), then I am more likely
to discard the software than change my environment. This is
particularly true with pointer focus - I hate it when MS Windows
forces me to click in a window to work there (this is even more
annoying in MS Windows, since it also brings the window to the front;
there are many times that I WANT the window in the back while I work
in it). I understand that it complicates issues with this particularly
software (MetaCard) to have pointer focus, but if it is feasible I would
recommend that you try to accomodate us people who really, really like
pointer focus and who really, really, really hate explicit focus.
--
Capt. David E. Bell, USAF, Ph.D. da...@ppws18.plk.af.mil
Leader, Computational Plasma Physics (505) 846-4479
High Energy Plasma Physics Division DSN 246-4479
Phillips Laboratory, Kirtland AFB, NM, USA
Chris Bitmead
>I think pointer focus is much better, as long as the window does not
>raise to front on focus.
I always use autoraise, and when I told the other programmers where I used
to work about it, 4 out of 5 switched to it. Hands up who prefers
autoraise!
Thomas Sippel - Dau
In article <1994Jun23....@prz.tu-berlin.de>, pcas...@jake.prz.tu-berlin.de (Peter Castine) writes:
- Because, if the mouse gets moved for any reason whatsoever, all
- keyboard input goes to never-never land (or from the newsreader
- to the console window).
About the first useful contribution in this long fruitless discussion.
Yes, I would like an application that collects keyboard input that no
other application wants, and that keeps it ready for pasting into where it
was meant to go. Any offers ?
Thomas
--
*** This is the operative statement, all previous statements are inoperative.
* email: cma...@ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
* voice: +44 (1)71 594 6904 (day), or +44 (1)71 594 6957 (fax)
* snail: Imperial College of Science, Technology and Medicine
Thomas Sippel - Dau
In article <2uddoi$3...@wombat.cssc-syd.tansu.com.au>, chr...@cssc-syd.tansu.com.au (Chris Bitmead) writes:
- I always use autoraise, and when I told the other programmers where I used
- to work about it, 4 out of 5 switched to it. Hands up who prefers autoraise!
I think autoraise is the most abominable feature ever implemented, and I wish
those people who use it would have at least the decency to keep quiet about
their disgusting habits.
Peter Castine
>
>As usual, you can get whatever results you want out of such studies by
>choosing your favorite set of metrics and conditions. For example:
>"pointer" will win if your metric is "operations required to transfer
>focus"; "explicit" will win if your metric is "usability when the mouse
>continually gets randomly bumped". Both of these are metrics I've seen
>people cite on the net as explanations for their preferences.
How about if that old bugbear "Consistency" were used as a metric?
Which would win then?
On the system I use, moving the mouse does *nothing* other than move
the mouse cursor. To initiate an action, you click. Doesn't matter
if it's a button, a menu, a picture, or a window. No clicky, no action.
I have spent hours cursing systems where moving the mouse to a magical
position caused menus to fall down automagically. "Don't move the mouse
into the menu bar" the GEM congregation would say. I look forward to
the day, when in the interest of shaving milliseconds off interaction
time and picojoules off physical effort, *all* user interface objects react
simply to pointer movement.
Whatever else you can say about it, it will be an exciting user interface
when you need to manoveur the mouse from your news window to your mail
window whilst avoiding the "Format Hard Disk" icon. :-\
--
Peter Castine | Dr. Who quote du jour:
pcas...@prz.tu-berlin.de | Have you noticed the way people's
Process Control Center | intelligence capabilities decline sharply
Technical University Berlin | the minute they start waving guns around?
Peter Castine
>
>I think autoraise is the most abominable feature ever implemented, and I wish
>those people who use it would have at least the decency to keep quiet about
>their disgusting habits.
Gosh, that's the way I feel about pointer focus. Maybe John Major should
make a statement about it.
Noam Bernstein
: pcas...@jake.prz.tu-berlin.de (Peter Castine) wrote:
: > How about if that old bugbear "Consistency" were used as a metric?
: > Which would win then?
: >
: > On the system I use, moving the mouse does *nothing* other than move
: > the mouse cursor. To initiate an action, you click. Doesn't matter
: > if it's a button, a menu, a picture, or a window. No clicky, no action.
: > [...]
: Agreed. I feel that this is _far_ more important than shaving a few
: seconds here or there.
I'm all for consistency. I'm also all for pointer focus w/o autoraise.
A click in a window (text of various sorts) means move the insertion
points (or something of the sort) to the clicked location. Click to
focus interferes with this if you want consistency.
: ___________________________________________________________________________
: Robert S. Mah -=- One Step Beyond -=- 212-947-6507 -=- rm...@panix.com
God, I hate click to focus. I've had far, far more experiences with my
input going to the wrong window on a Mac because I didn't click than
my input going to the wrong X-window (where I have it configured for
pointer focus).
I haven't seen this good a religious argument in ages (this is genuinely
meant as a compilment to the discussion). Emacs vs. vi just doesn't cut
it anymore.
Peter Castine
>
>pcas...@jake.prz.tu-berlin.de (Peter Castine) wrote:
>
>> How about if that old bugbear "Consistency" were used as a metric?
>> Which would win then?
>>
>> On the system I use, moving the mouse does *nothing* other than move
>> the mouse cursor. To initiate an action, you click. Doesn't matter
>> if it's a button, a menu, a picture, or a window. No clicky, no action.
>
>Agreed. I feel that this is _far_ more important than shaving a few
>seconds here or there.
I would claim milliseconds, but let's not be fussy ;-0
>Many people still feel that computers are unpredictable and arbritrary
>beasts. To make software "easier to use" and more approachable,
>consistant operation, and the dogma of no suprises, is in my opinion,
>of overriding concern.
Nice to know that someone agrees with me :-)
I would like to qualify the consistency argument a little, because this
needs to be treated with intelligence, not dogma. Sometimes there can
be potent reasons to be inconsistent. For instance, pointer focus
makes a lot of sense for some people with special needs (for example,
limited finger dexterity). In one of the eternal discussions about
the Macintosh drag-disk-to-trash gesture for unmounting disks, I have
argued that there are overriding considerations that justify the
inconsistency perceived by some (not all!) users.
Now, the added cognitive load and time needed to click on a window
(instead of just moving the pointer over it) is minute. A good deal
of the cognitive processing takes place *while* you're busy moving
the mouse, so it's not as if there's any real efficiency gain from
pointer focus (I'm shooting from the hip here--anyone want to do a
GOMS model?).
Alternately, someone might want to argue that there are significant
differences in the user models of applications/processes/windows
on, say, OSF Motiv GUIs used on Workstations as opposed to the GUIs
used on personal computers. (My reference is Macintosh, but I don't
see really significant differences in the basic UI models used on
Macs, Windoze, or even GEM). I'm not promising to be convinced by
such arguments, but it should make for an interesting discussion.
In the interest of bandwidth, what say follow-ups to comp.h-f?
computers
a90...@pluto.tiuk.ti.com
>
>What I'd *like* to do is leave keyboard focus on the command window all the
>time (so I can type a complex command without having to move the mouse or
>click on the command input area), but I'd also like to be able to leave the
>mouse over a commonly used button (single step, for instance) and click it
>repeatedly.
For openlook apps. built with xview you can get the behaviour you want
(at least in pointer focus, I know I have apps that behave like that!).
olwm only sets focus to windows which are children of root window,
within the window it is up to the application.
Eric J. Schwertfeger
: Personally, I don't like either style; having to take my hands off the
: keyboard to switch windows is unacceptable to me.
Then get a window manager that lets you bind warpring or the equivelent to
Ctrl-Tab or some such key. That will cycle the windows. Then, if there are
a few programs you always have open, you can assign Fn keys to directly warp
to that window. This works with either focus model (at least with twm and
fvwm).
Frank Leahy
approximately 99.99% of the respondents are computer scientists (or play
one during the day), which creates an incredibly lopsided set of
responses. The lopsidedness comes from the fact that you all work on
machines that allow or default to pointer focus. In fact though, most of
the world's computer users (I believe the number is well over 90%) work
on either Windows or Macintosh machines, both of which use click to
focus. If you want other opinions (flames?!) you might try cross-posting
to other boards.
If what you want is real information rather than a lot of opinions, there
is an enormous amount of HCI literature out there, e.g. you could start
with the SIGCHI bulletins. Alternatively you might try getting some of
the HCI community involved here, there's a group at the University of
Maryland, under Ben Schneiderman (sp?), Don Norman (author of "The Design
of Everyday Things" and other very readable books on human interface
design) formerly at UC San Diego is at Apple now, and of course Bruce
Tognazzini who is now at Sun (probably t...@sun.com) is always EXTREMELY
quotable. I'm guessing that click to focus came from work done on the
LISA, and was implemented because of user testing that took place at that
time (they did a lot of user testing for LISA) and Larry Tesler or Alan
Kay at Apple could confirm this (I may be wrong about this, it may
instead have originated at PARC).
-- Frank Leahy
...former Apple employee, and click to focus bigot...
David Fox
] While I understand that you may personally dislick the click-to-do-anything
] model, I can't imagine how one could be confusued about where keystrokes
] go on a Mac. Text input goes to the active window or dialog box. And the
] insertion bar blinks. No active window or no blinking insertion bar, no
] text input. Seems, pretty simple to me.
Well, you must be one of those people who looks at the screen
before typing. My experience with click-to-type comes from
NeXTStep, where for religious reasons it is *not* configurable.
I prefer pointer focus, but only because I've been using it for
about ten years.
--
David Fox xoF divaD
NYU Media Research Lab baL hcraeseR aideM UYN
Robert S. Mah
> rm...@panix.com (Robert S. Mah) writes:
>
> ] While I understand that you may personally dislick the click-to-do-
> ] anything model, I can't imagine how one could be confusued about where
> ] keystrokes go on a Mac. Text input goes to the active window or
> ] dialog box. And the insertion bar blinks. No active window or no
> ] blinking insertion bar, no text input. Seems, pretty simple to me.
>
> Well, you must be one of those people who looks at the screen before
> typing. My experience with click-to-type comes from NeXTStep, where
> for religious reasons it is *not* configurable. I prefer pointer
> focus, but only because I've been using it for about ten years.
Seems to me that pointer focus has a greater requirement for looking at
the screen before typing. Or can some people magically figure out where
the cursor is without looking?
With active-window-focus, you can even type stuff _before_ the window
comes up (well, on the Mac at least, and yes, I know it's only because
of certain idiosycracies in its event handling model). It helps make
up for the pokiness of the slower models.
P.S. If you like pointer-focus, by all means use it. I just don't think
that model makes sense for the general populace or as a default.
Cheers,
Rob
Nem Schlecht
This is a moot thread really. Who is to say that peas are better
than carrots? Is somebody more correct than I am if they have been
using computers for a longer time? I guess a researcher who has
thoroughly studied the subject may postulate a "correct" answer,
although it would only apply to a certain percentage of people,
which might include me. The point is, I like peas, you like
carrots. Luckily, if I start liking carrots, the X Windows system
is diverse enough to allow me to change. With a few exceptions, I
think every window manager allows a user to switch from one to the
other, usually in less than 5 minutes. Trying to convince somebody
that likes peas that carrots are better is futile. Let's just all
agree that vegetables are good. Just my 2 cents worth...
-----
Nem Schlecht schl...@sonic.cc.ndsu.NoDak.edu
304B Seim Hall SIGUSR! Manager
Computer Science NDSU SysAdmin Group
IACC Room 208E Phone: 298-1076
N.D.S.U. Information Services UNIX and X Windows Consultant
-----------------------------------------------------------
Scott Raney
>How about if that old bugbear "Consistency" were used as a metric?
>Which would win then?
>On the system I use, moving the mouse does *nothing* other than move
>the mouse cursor. To initiate an action, you click. Doesn't matter
>if it's a button, a menu, a picture, or a window. No clicky, no action.
>I have spent hours cursing systems where moving the mouse to a magical
>position caused menus to fall down automagically. "Don't move the mouse
>into the menu bar" the GEM congregation would say. I look forward to
>the day, when in the interest of shaving milliseconds off interaction
>time and picojoules off physical effort, *all* user interface objects react
>simply to pointer movement.
Hey, don't blame the GEM team for that kluge (I was part of it).
Originally, GEM worked just like the Mac. We had to change the
behavior at the 11th hour due to the threat of a lawsuit by Apple. We
were just lucky that the solution wasn't even worse than the
"drop-down" behavior that one of the many creative engineers on the
team came up with. It certainly wasn't an attempt to improve the UI.
>Whatever else you can say about it, it will be an exciting user interface
>when you need to manoveur the mouse from your news window to your mail
>window whilst avoiding the "Format Hard Disk" icon. :-\
One rule of thumb here: any time you run into a UI technique or design
that you really hate, check to see if maybe it's Apple's fault. From
the design of the MS-Windows file/program manager, to ToolBook's
language, to GEM, to Motif, Apple's litigious nature has had a
tremendous negative impact on this whole industry.
>--
>Peter Castine | Dr. Who quote du jour:
>pcas...@prz.tu-berlin.de | Have you noticed the way people's
>Process Control Center | intelligence capabilities decline sharply
>Technical University Berlin | the minute they start waving guns around?
Charles Bryant
bwilson@hwhelp@fedex.msfc.nasa.gov "Robert J. Wilson" writes:
> In article <CrM0M...@csn.org>, ra...@teal.csn.org (Scott Raney) wrote:
> > I'm looking for studies comparing "pointer" focus policy
>
> Any such experiment should test the following:
>
> a) Errors as a function of pointing devices:
...
> b) Errors as a function of environment:
...
Why pick errors as the measure of superiority? Why not speed of entry? Or
user satisfaction? Or some other measure.
> There
> should be an instructional period prior to the test but record the number
> times it is used.
This seems to assume that the users being tested are not familiar with the
different policies. It seems quite possible that a user who is well
accustomed to a policy may prefer it while initially having disliked it.
--
Charles Bryant (c...@chch.demon.co.uk)
der Mouse
>> the keyboard to switch windows is unacceptable to me.
That wasn't a complaint.
I already have a window manager that doesn't require me to take my
hands off the keyboard when I switch windows. I wrote it myself and it
mostly does what I want; the deficiencies aren't severe enough to make
me get off my duff and fix them....
der Mouse
Mike Gaffney
>I think pointer focus is much better, as long as the window does not
>you would prefer to click on a window to focus it. OpenWindows on
>
> --Rob
>
>
I can think of one. Using the clicking required setup, I can (ironically)
move from window to window WITHOUT ever touching the damned mouse! Granted,
if you have 30 windows up cycling through them one by one is a pain and
using the mouse is preferable. In general though, I try not to let my fingers
stray from the keyboard. It isn't so much that I like to click on a
window, as much as I hate to use the mouse for everything and anything.
MJG
--
------------------------------------------------------------------------------
These neural nuggets are mine, all mine. I wouldn't let my company take
credit for them even if they _wanted_ to.
Jurgen Botz
thread I like using focus-follows-pointer mode on my X workstation.
This is convenient because it allows me to switch between several text
windows fairly rapidly and allows me to type into partially obscured
windows, operations that are very common because the primary user
interface on my X (Unix!) workstation is the /command line shell/, and
GUIs are secondary.
But I do feel that click-to-focus is more /generally/ useable... in terms
of predictable behavior for novice users as well as a model for more
GUI-oriented systems.
One example where strict adherence to focus-follows-pointer drives me up
the wall are text-entry widgets in Motif... when focus-follows-pointer you
have to move the mouse to focus on every single text field, an operation
that quickly becomes very cumbersome when you have several fields even
aside from the fact that the pointer itself constantly gets in the way of
seeing what you're typing.
On a different but related note... how do people feel about selections and
the insertion point being disjoint? (as opposed to the i-point being an
empty selection.)
--
Jurgen Botz, jb...@mtholyoke.edu | ``Accountability is the price of openness''
South Hadley, MA, USA | - Daniel Geer
Ralph Betza
+ pcas...@jake.prz.tu-berlin.de (Peter Castine) wrote:
+
+ > How about if that old bugbear "Consistency" were used as a metric?
+ > Which would win then?
+ >
+ > On the system I use, moving the mouse does *nothing* other than move
+ > the mouse cursor. To initiate an action, you click. Doesn't matter
+ > if it's a button, a menu, a picture, or a window. No clicky, no action.
+ > [...]
+
+ Agreed. I feel that this is _far_ more important than shaving a few
+ seconds here or there.
+
+ Many people still feel that computers are unpredictable and arbritrary
+ beasts. To make software "easier to use" and more approachable,
+ consistant operation, and the dogma of no suprises, is in my opinion,
+ of overriding concern.
I've been using computers for more than 25 years,
and by no means do I feel that computers are unpredictable and
arbitrary machines.
It is possible that click-to-type is better for beginners.
(Although there is no proof) (Note A), or casual users.
It is likely that click-to-type is better if you are using a
computer on the back of a pickup truck going lickety-split
down a bumpy road (or if you're in California :-).
People who already know what they're doing and are using computers
in normal places seem to prefer pointer focus.
(Note A:)
Finding experimental subjects who've never used a computer
might be difficult.
There might also be cultural differences.
Germans might prefer click-to-type and Italians might prefer pointer.
Who knows?
Avinash Chopde
for a long time, and I think I used them as shipped, so used the pointer-focus
policy.
Then, I moved over to a diferent job, where my primary machine is now a
Mac. When I got to add a SGI box to my office, the first thing I
did was to immediately change it over to explicit-focus policy!
And, I did not understand why the SGI users who came over took some
getting used to my Desktop! Now I understand...
So, I guess I am one of the persons who moved from preferring pointer focus
to explicit focus...did not think anything out, just found it more
convenient to my usage style...
--
----
Avinash Chopde
avi...@acm.org
Warner Losh
(Jurgen Botz) writes:
>One example where strict adherence to focus-follows-pointer drives me up
>the wall are text-entry widgets in Motif... when focus-follows-pointer you
>have to move the mouse to focus on every single text field, an operation
>that quickly becomes very cumbersome when you have several fields even
>aside from the fact that the pointer itself constantly gets in the way of
>seeing what you're typing.
Object Interface (OI) implements focus follows pointer such that you
can still tab through the fields if you so desire. When an object
that takes focus is entered, that objects gets focus (when OI is
running in follows-pointer mode). When you tab from object to object,
you get focus in the object that has the focus frame (just like in
click to type mode). This lets you fill out long forms where you want
to move quickly to one part of the form and then go sequentially from
there.
Another problem with OSF/Motif's focus model is that in follows pointer
you get no focus frame :-(.
Warner
P.S. I work for ParcPlace on the OI library.
--
Warner Losh i...@boulder.parcplace.COM ParcPlace Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
more serious personality disorders"
Broken Hill Proprietary
(I came to this discussion from comp.sys.sgi.misc, but I am not an SGI
user (at least not yet). I missed the original post, but the discussion
seems to be "What is better, pointer or click to focus?")
I run some scientific applications on dual headed Tatung SPARCstations
(also some Sun's) where it is necessary to move from window to window,
screen to screen, to select various data (in the form of points on a
very dense seismic section display) for processing. Adding a click
on each window to focus it would add considerable time to the selection
process and undoubtedly lead to errors.
I can well imagine in the near future going to three monitors, there
simply are not enough pixels on a single monitor to give us the resolution
needed for several windows at a time. If we stacked the windows and
used explicit focus and raise, we would spend all our time watching
redraws.
Most applications run in a single main window with the odd auxilliary
pop-up window and various screen overlaying pop-out widgets. This would
not work in our case. Of course, a single window cannot span multiple
framebuffers (monitors).
We have looked at a number of window managers that give us extra virtual
screen space, but they all have the redraw delay problem.
There have been allegations in this thread that pointer focus is preferred
only by computer "weenies". Well, here is a scientific user (albeit,
if modesty permits, a "power" user) who has a clear reason for preferring
pointer focus.
Thank you,
Will Morse
Grant Edwards
: |> Seems to me that pointer focus has a greater requirement for looking at
: |> the screen before typing. Or can some people magically figure out where
: |> the cursor is without looking?
: Sure. I've never seen a computer mouse walk around all by it's own, and
: as long as the apps I use are so nice as to not call XWarpPointer()...
Is that the call that moves the mouse pointer? Gawd, how I hate it
when a dialog box pops up and moves the pointer -- it must have been a
SunView/OpenWindows thing, X apps don't do it very often, but it drove
me nuts the first few days with Solaris 2.2. Between that and click
to focus (which raised the window), I was about to start screaming and
throwing things.
If I ever have to use an app that insists on misbehaving in that
manner, I swear I'll replace that routine in Xlib with one that
doesn't do anything.
--
Grant Edwards |Yow! Hiccuping & trembling
Rosemount Inc. |into the WASTE DUMPS of New
|Jersey like some drunken
gra...@rosemount.com |CABBAGE PATCH DOLL, coughing
|in line at FIORUCCI'S!!
Arthur Tateishi
>I haven't seen this good a religious argument in ages (this is genuinely
>meant as a compilment to the discussion). Emacs vs. vi just doesn't cut
>it anymore.
An old comp.editors chap.
Hehe. That's because vi won and the emacs heretics went over to
alt.religion.emacs for meetings of their support group.
:-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-):-)
arthur
--
Choices don't scare me. However, a lack of choices does.
Arthur Tateishi ruh...@turing.utoronto.ca
Peter Shenkin
Arthur Tateishi <ruh...@turing.toronto.edu> wrote:
>In article <Crx7z...@das.harvard.edu>, Noam Bernstein <noamb@cmtg1> wrote:
>>I haven't seen this good a religious argument in ages (this is genuinely
>>meant as a compilment to the discussion). Emacs vs. vi just doesn't cut
>>it anymore.
>
>An old comp.editors chap.
>Hehe. That's because vi won and the emacs heretics went over to
>alt.religion.emacs for meetings of their support group.
Why is it that emacs users always get sheepish looks on their faces
whenever I catch them using vi for simple edits? :-)
-P.
--
********** After the revolution, everyone will have a home page... **********
Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
New York, NY 10027; she...@still3.chem.columbia.edu; (212) 854-5143
***** (... but the Internet will be too busy for anyone to access it.) ******
Peter Shenkin
Grant Edwards <gra...@reddwarf.rosemount.com> wrote:
>Michel Eyckmans (MCE) (eyck...@imec.be) wrote:
>: rm...@panix.com (Robert S. Mah) writes:
>
>: Sure. I've never seen a computer mouse walk around all by it's own, and
>: as long as the apps I use are so nice as to not call XWarpPointer()...
>
>when a dialog box pops up and moves the pointer ....
>
>If I ever have to use an app that insists on misbehaving in that
>manner, I swear I'll replace that routine in Xlib with one that
>doesn't do anything.
Interesting. Do you use explicit or pointer focus? One of the
arguments against pointer focus has been that when a dialog box
comes up, you have to move the mouse to click in it.
I was thinking that when pointer focus is in use, the application
might be kind if, when bringing up a dialog box that required
immediate attention, the it would warp the mouse cursor to the
default button. Then it could be warped back to its previous
position after a click.
Would you hate this, too? (Of course, if you use explicit focus,
there would probably be no need for this.)
Jack Morrison
>Gawd, how I hate it
>when a dialog box pops up and moves the pointer -- it must have been a
>SunView/OpenWindows thing, X apps don't do it very often, but it drove
>me nuts the first few days with Solaris 2.2. Between that and click
>to focus (which raised the window), I was about to start screaming and
>throwing things.
And *I* hate it when a Motif app pops up a warning dialog, and prevents me
from doing anything until I pick up the mouse, move the cursor over the
little "ok" button, and click. Another thing that OPEN LOOK got right, IMHO.
And another thing (besides click-to-focus and such) that resource-file-impaired
users can customize without even touching the keyboard, if you don't like
the default behaviour. Use the Properties windows from the root menu, and
stop griping.
---
"How am I typing? Call 1-818-354-7782" ja...@robotics.jpl.nasa.gov
Jack Morrison/Jet Propulsion Lab/MS107-102 4800 Oak Grove Dr, Pasadena CA 91109
Jack Morrison
>Gawd, how I hate it
>when a dialog box pops up and moves the pointer -- it must have been a
>SunView/OpenWindows thing, X apps don't do it very often, but it drove
>me nuts the first few days with Solaris 2.2.
And *I* hate it when a Motif app pops up a warning and prevents me from doing
anything until I pick up the mouse, point the cursor precisely at the
"ok" button, and click. Another thing OPEN LOOK got right, IMHO.
For the resource-file-impaired, this is another thing (besides pointer focus
and other stuff) that you can customize without even touching the keyboard, using
the "Properties" program available from the root menu.
Don Bennett
> whenever I catch them using vi for simple edits? :-)
Not me. Simple edits call for MicroGnuEmacs. :-)
--
Don Bennett (415)390-2145
d...@sgi.com
Silicon Graphics
Alan Braggins
By all means. I hate explicit focus, too - I find it very handy to
have the capability to type a few commands in an xterm which is partly
obscured by some large, graphical window without having to pop that
window on top.
Explicit focus is a valid personal preference (though not mine).
Auto-raise is a different issue - it is possible under either
focus policy, and in both cases is an invention of the devil, and an
abomination in the sight of anyone with any sense, and only barely
tolerable if it is an obscure option which weirdos can turn on if they
really want to. So there.
--
Alan Braggins ar...@setanta.demon.co.uk abra...@cix.compulink.co.uk
"Any technology distinguishable from magic is insufficiently advanced"
Claude Lecommandeur
is used, because they never use the mouse to change the focus. They use the
keyboard to do this.-)
Claude Lecommandeur
Service Informatique Central
Ecole Polytechnique Federale de Lausanne
1015 LAUSANNE (SWITZERLAND)
E-Mail : Claude.Le...@epfl.ch
Tel : +41 21 693-22-97
Dick Schoeller
Actually what this testing approach assumes is that even users who are
familiar with a particular paradigm make errors and that the error rate
among experienced users is an important metric. Probably a more important
metric is overall through-put across a working day experienced and
inexperienced users in each of the paradigms. The reason is that a high
error rate as a negative may not overwelm a high input rate as a positive.
Dick Schoeller
5 more days at di...@zk3.dec.com
Patrick McTiernan x8738
For the record, I use olvwm running on a SUN, with a Tektronix Xterminal
supplying an 1192x900 window. I prefer click-to-type.
I often have to help other users with problems, since I support some
products that use X-windows, so I often use pointer-following focus too.
Pointer focus has the problem on high-res screens that it can be hard to see
the pointer, and not everyone has colours which make it totally obvious where
focus currently is. Also, most users have plenty of paper on their desks, and
mice often "jiggle" their way about causing loss of focus at the least expected
times. Even worse, dialogues which pop up from other places occasionally
hit the mouse and get focus. Also, I like to push the cursor away from the area
I am typing in once something is selected; this often leaves me with focus in
the wrong window. With a big stack of windows on screen, you never know where
you might be typing...
More importantly, perhaps, I used to do more programming at home than at
work (and I still do quite a bit). My machine is an Acorn Archimedes, which
has a co-operative multi-tasking windowing system which gets round most of
the problems of focus in a variety of ways. It is possible to add modules
to the operating system to emulate mouse-following focus, but the system
is primarily click-to-type. Applications which put up a dialogue needing
focus can grab focus, and return it to its former holder when focus is no
longer required. This makes it possible to have an application which grabs
focus when a window is entered, but returns focus to its former owner when
you leave the window; thus the question of focus policy is left to the
application for the most part. This means that the behaviour is usually
rather more intuitive and appropriate to each individual application
than under X (or Windows or Mac system-7), IMO. I sometimes think I might
write a module to allow a button press to move around windows which might
take focus... but it works so well now I find I have better things to do.
The opinions expressed here are entirely personal, and do not reflect those
of my company (except by coincidence).
Tom Davis
>I haven't seen this good a religious argument in ages (this is genuinely
>meant as a compilment to the discussion). Emacs vs. vi just doesn't cut
>it anymore.
So there were two guys sitting in a bar, and one says to the other,
"That was a very intelligent remark you just made. What's your IQ?".
The other guy says, "178." The first guy says, "Well, mine's 182.", and
they go on to have a great discussion of the newest developments in the
grand unification theories in physics.
A couple of seats down, two other guys overhear the discussion, so one
turns to the other and says, "My IQ's 101." The other says, "Well,
mine's 99. How do you think the 49ers are going to do this year?" And
they begin to become great friends.
At the far end of the bar, both conversations are overheard by a third
pair. One says to the other, "My IQ's 48." The other says, "Great,
mine's 45. Do you use Emacs or vi?"
Carl Brewer
Ernie Pittarelli 301-794-2032 S833 <er...@niccolo.gsfc.nasa.gov> wrote:
>---------------------------------------------------------------------
>When will the Unix world abandon vi for a standard mouse-based editor???
When you can use a mouse on any terminal ever made, even terminals without
mice ... and in single user mode on a headless server, and ... you get the
point by now :) mouse, schmouse ... if I wanted a Mac, I'd buy one!
--
Carl Brewer Ph :61-9-380-1893 | #include \
Systems/Network Officer, Reid Library Fax:61-9-380-1012 | <std_disclaimer.h>
University of Western Australia ca...@oversteer.library.uwa.edu.au
Merlin, where are you? Call your Dragon, to weave a mist .... "BEABLE"
Gina Faber
rsil...@media.mit.edu (Rob Silvers) writes:
>I think pointer focus is much better, as long as the window does not
>raise to front on focus.
I always use autoraise, and when I told the other programmers where I used
to work about it, 4 out of 5 switched to it. Hands up who prefers
autoraise!
A vote from a programmer/user interface designer:
pointer focus - same reasons as have been posted
no autoraise - I sometimes want to see what's on the original window
when typing in the newly focused window...You can't do that at
all with autoraise!
Gina Faber
--
Gina Faber Cimflex Teknowledge Corporation
gfa...@teknowledge.com / gfa...@netcom.com (415) 424-0500
"Everybody wants prosthetic foreheads on their real heads" -TMBG
Gina Faber
Roger Tinkoff
>> whenever I catch them using vi for simple edits? :-)
It's sort of like being caught masturbating. I.e. using the quick and
dirty method of getting the job done, as opposed to the more fun,
more effort-requiring, elegant method!
-rogt
Michael Sargent
: One example where strict adherence to focus-follows-pointer drives me up
: the wall are text-entry widgets in Motif... when focus-follows-pointer you
: have to move the mouse to focus on every single text field, an operation
: that quickly becomes very cumbersome when you have several fields even
: aside from the fact that the pointer itself constantly gets in the way of
: seeing what you're typing.
I feel the same way. Our product, currently in Beta, has the same problem
with text fields. I would like to be able to have users press TAB to go to
the next field. I know this can be done, as the SGI CD-ROM player does this.
Can anyone tell me how to convince a Motif widget that it has focus from a
program, rather than requiring the user to move the mouse (and possibly
requiring a click)?
Thanks,
Mike
Grant Edwards
: Grant Edwards <gra...@reddwarf.rosemount.com> wrote:
: >
: >: Sure. I've never seen a computer mouse walk around all by it's own, and
: >
: >....Gawd, how I hate it
: >when a dialog box pops up and moves the pointer ....
: >
: >If I ever have to use an app that insists on misbehaving in that
: >manner, I swear I'll replace that routine in Xlib with one that
: >doesn't do anything.
: Interesting. Do you use explicit or pointer focus? One of the
: arguments against pointer focus has been that when a dialog box
: comes up, you have to move the mouse to click in it.
I use pointer focus.
I just don't like stuff moving around by itself. I know where the
pointer is, and it's disconcerting when it's suddenly somewhere else.
Maybe it's just me, but part of using X11 efficiently was developing
an unconcious awareness of where the pointer is. I think I
unconciously keep track of where it is and it's jarring when it's not
where I last left it.
Besides, if some application is constantly moving the pointer from the
bottom of the screen to the middle, then I have to pull it back
down. Since the mouse moves down but not up, I actually have to pick
up the mouse and move it back to the middle of the pad each time to
avoid running out of room.
: I was thinking that when pointer focus is in use, the application
: might be kind if, when bringing up a dialog box that required
: immediate attention, the it would warp the mouse cursor to the
: default button. Then it could be warped back to its previous
: position after a click.
: Would you hate this, too?
I'm afraid so. I don't like the pointer moving by itself. I don't
like windows that auto-raise either. I don't like automatic
transmissions either, so maybe there's a trend here...
[Yikes, I'm starting to sound like my dad. You should have heard him
complain when he bought his first car that had an automatic choke!]
: (Of course, if you use explicit focus, there would probably be no
: need for this.)
Explicit focus would be tolerable without auto-raise, but the two seem
to go together by default.
This is all just my personal preference. As long as the window manager
and/or application can be configured to the my taste, it matters not a
whit what others choose to do.
--
Grant Edwards |Yow! I am covered with pure
Rosemount Inc. |vegetable oil and I am
|writing a best seller!
gra...@rosemount.com |