Subject: FVWM: fvwm 1.24r problems with "active focus" applications

From: Scott Raney <[email-masked]>
Date: Mon, 21 Oct 1996 20:52:41 -0600 (MDT)

We've discovered a couple of problems with fvwm 1.24r that make it
difficult to use with our application MetaCard.  The first two are
caused by the fact that MetaCard unusual in that it is an "active
focus" application that *requests* the keyboard focus when it needs it
(the XWMHints.input field is False, and the WM_TAKE_FOCUS atom is
set).  These are all with maximum mwm compatibility specified in the
config files, yet aren't a problem with mwm or olwm.

You can verify all of these problems by getting MetaCard 2.0.1 from
ftp://ftp.metacard.com/MetaCard.  You'll need an engine (precompiled
binary) for whichever platform you're using (e.g., SPARC.gz, Linux.gz,
etc.), the Home stack (mchome.mc.gz) and the tools stack
"mctools.mc.gz".  Gunzip all three parts, chmod +x the engine, then
run it.

1) In the explict/click-to-type focus model, clicking in a window
incorrectly automatically moves the keyboard focus to that window.
The focus should remain in the source window until the application
specifically requests it with XSetInputFocus.  Reproduce by clicking
in a window other than the MetaCard Home stack, then clicking back in
the MetaCard window.  It should only set the focus to the window if
you click on one of the icons in that window.

2) In the pointer focuse model, moving the mouse to a window doesn't
always focus that window.  Reproduce by opening the MetaCard Message
Box and moving the mouse back and forth between it an the Home stack.

3) Calling XRaiseWindow does not cause a configureNotify event to be
sent to the application like it does with mwm.  Our application raises
the menu bar window when the user clicks on a menu button, and needs
the configureNotify message to confirm that the menu has been raised
before opening the menu panel (otherwise, the menu bar can be raised
*after* the panel is opened if the window manager is slow to respond).
MetaCard has a 500 msec timeout for the wait for the message, but this
problem makes opening menus with fvwm very tedious.  Reproduce by
opening the MetaCard menu bar and clicking on a menu: there is a delay
between the click and the panel opening (this isn't a problem with
mwm).

======================================================================
And now for a plea for a change of default focus policy in fvwm from
pointer to explicit focus.  The current default of pointer focus is
provably inferior to explicit focus, and really puts Linux in
particular at a major disadvantage to Micro$oft products in the
marketplace because it is user-hostile and industry non-standard.  All
other workstations and/or operating systems ship with explicit (click
to type) focus by default, including Sun, HP, IBM, all vendors that
ship the COSE Desktop, Apple, NeXT, and Microsoft.  This industry
standard is the mode that 99.9% of current computer users are familiar
with, and has been shown to be easier for novice computer users to
grasp.

As for the provably inferior part, here are a few scenarios using our
product MetaCard, among the commercial X products that is most like
applications found on MS-Windows and the Mac:

A) Like many Mac and Windows applications, when the user opens or
traverses to editable text fields in MetaCard dialogs, the text in the
field is automatically selected to make it more efficient to change
the value (since you just type in the new value instead of having to
delete the old value first).  This doesn't work very well with pointer
focus, because every time you move the mouse out of the window, it
selects the text in some other window.  Not only is the flashing very
annoying, but it also makes it impossible to use the menu bar to
cut/copy/paste selections, since the selection changes when you move
the mouse up to the menu bar (which is in another window).  There is
no workaround for this problem other than using explicit focus.

B) Like many Mac and Windows applications, MetaCard relies heavily on
floating palettes and other modeless dialogs.  To facilitate this,
MetaCard is an "active focus" application, which means that the
keyboard focus doesn't necessarily go to these windows when the user
clicks in them (to select a tool, choose a menu, or run a layout
script).  This allows the user to designate the window to which the
operation should be applied by making it the focused window.  This
technique doesn't work with pointer focus, because the mere act of
moving to a tool palette focuses that palette, a useless operation
with potentially devistating consequences as the user may then lose
track of which window the operation will be applied to.

Continued use of pointer focus as the default will just demonstrate a
total lack of respect for industry standards by the fvwm developers,
prevents many advanced applications (such as MetaCard) from working
well on many Linux systems, annoys and confuses novice users, and is
generally detrimental to the success of products such as Linux that
deserve all the help they can get.
  Regards,
   Scott

-- 
***************************************************************
Scott Raney   [email-masked]   http://www.metacard.com
Tcl and ksh: syntactic gymnastics
MetaCard: it does what you think

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Alan Shutko <[email-masked]>
Date: 23 Oct 1996 00:33:33 -0500

>>>>> "SR" == Scott Raney <[email-masked]> writes:

SR> Continued use of pointer focus as the default will just
SR> demonstrate a total lack of respect for industry standards by the
SR> fvwm developers, prevents many advanced applications (such as
SR> MetaCard) from working well on many Linux systems, annoys and
SR> confuses novice users, and is generally detrimental to the success
SR> of products such as Linux that deserve all the help they can get.

Ouch!

First, the default focus policy is a site/distribution decision.  You
would be better off haranguing them.

Second, fvwm 2 allows the focus policy to be set on a per window basis,
so it could be MouseFocus for most things, but ClickFocus for
MetaCard.

--
Alan Shutko <[email-masked]> - The Few, the Proud, the Remaining.
IBM: Increasingly Bad Manufacturing
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Jim Nicholson <[email-masked]>
Date: Wed, 23 Oct 1996 10:57:06 -0400 (EDT)

On 23 Oct 1996, Alan Shutko wrote:

My apologies to Alan; I couldn't find Scott's original post...

> SR> fvwm developers, 

To quote Bruce, "Howls of derisive laughter, Bruce!"

_IF_ the "industry standards" were any good, I wouldn't be using fvwm.

> SR> prevents many advanced applications (such as

Insisting of click focus demonstrates both a lack of design flexibility
and a total lack of respect for user preferences by the MetaCard
developers, prevents many advanced system tools (such as Linux and fvwm)
from working well with MetaCard, annoys and confuses both novice users and
those of us who must support them (and the later group quite often
influence purchasing decisions), and is generally detrimental to the
success of products such as MetaCard that frankly may not deserve any
help.

> would be better off haranguing them.

I support 200 Win95 users. My most frequent request is to install Xmouse,
an unsupported (yet Microsoft-developed) extension to Win95 that
implements pointer focus for Win95.

> so it could be MouseFocus for most things, but ClickFocus for

Which only goes to show that the problem is MetaCard not supporting fvwm,
and not fvwm's lack of support for MetaCard.

- Jim Nicholson           [email-masked]
YAATTSA (Yet Another AT&T SysAdmin)

---

From: Michael Tiefenback <[email-masked]>
Date: Wed, 23 Oct 1996 12:28:46 -0400 (EDT)

Now, now, let's be gentle here....but I rather thought Mr. Raney's message 
looked unnecessarily flameable, too.

> > SR> demonstrate a total lack of respect for industry standards by the

Yes, Mr. Raney actually phrased things this way.  I think he must be
peeved at the different behavior of "standard" mwm and its brethren as
opposed to the occasionally idiosyncratic way fvwm appears to handle
things.  It is _possible_ that fvwm is rigorously enforcing the standard
protocol while other products are invoking nonstandard special handling. 
I am not in a position to assess the matter.  However, I can overlook the
rather strident form of Mr.  Raney's protest (posted about 9 pm after
perhaps a long day at work) and examine the content.

> _IF_ the "industry standards" were any good, I wouldn't be using fvwm.

Yes, I use pointer focus and detest click-to-focus and autoraise.  Not 
all users have the same opinions.  And yes, fvwm does attempt to support 
all options.  But Mr. Raney has identified purportedly exceptional 
circumstances.

> success of products such as MetaCard that frankly may not deserve any

If a developer is including the Linux world (and such of the commercial
world as use fvwm, which is a growing segment) in his market audience,
this seems good to me.  He does seem to be confusing Linux and fvwm,
however large the overlap may be.  He has some rational expectation that
his application will behave in similar ways under different
implementations of the applicable standards.  Mr.  Raney seems to be
complaining about the different behavior of his MetaCard application under
fvwm with respect to that under mwm.  His protest has some basis in fact. 
I have problems with a certain Motif application that appear similar to
those Mr. Raney mentions.  These problems may be due to the
ConfigureNotify message handling mentioned by Mr. Raney, as they involve
menu boxes being obscured as a result of a RaiseWindow event for the main
window executed after the menu creation (under fvwm/twm, but not
mwm/vuewm).  I am not sufficiently skilled in programming to follow up on
this, but I very much appreciate the specific suggestions he made, and I
filed his message away for future reference when and if I decide to
develop said skills. 

> > would be better off haranguing them.

Yes, a README for the MetaCard distribution would be an appropriate idea. 
But _if_ MetaCard programmers have found a misbehavior of fvwm, I would
think it appropriate to fix it.  The accompanying request to change the
default pointer focus behavior for fvwm is (I think) very much another
matter.  It is unreasonable to insist that the present focus default is
irresponsible.  If one were marketing fvwm, then it would be a question of
$ and market share, and the answer would come from a customer vote. 

> implements pointer focus for Win95.

This is encouraging, as I think it shows signs of independent thinking on 
the part of Microsoft users (;^)

> and not fvwm's lack of support for MetaCard.

See above reference to Mr. Raney's ConfigureNotify "bug" report.

Michael Tiefenback

---

From: Scott Raney <[email-masked]>
Date: Wed, 23 Oct 1996 11:33:19 -0600 (MDT)

> perhaps a long day at work) and examine the content.

Perhaps it was a bit strong, but we've been pointing out the inherent
and insurmountable problems of using pointer focus with real GUI
applications (as opposed to xterms) for years now, and have sent
requests in to the fvwm developers before with no effect.  And the
statement is true: explicit focus is the de facto industry standard,
and although having a contrarian streak is a stereotypical
characteristic of Linux users (and probably of fvwm users on other
platforms), there are times when playing nice with the other children
is the right thing to do.

> all options.  But Mr. Raney has identified purportedly exceptional 

I'm not arguing against choice, only that the *default* setting should
be the one that will benefit the most users.  It just seems unfair
(and unwise) to me that those who are least able to make the changes
(new users) are the ones who are stuck with the task.  *You* know how
to set up fvwm and will probably be changing the configuration anyway
to suit your needs, so why not just make the default the one that's
best for the X and UNIX community as a whole?

> > influence purchasing decisions) and is generally detrimental to the
> however large the overlap may be.

I realize that they are separate, and it's good that you realize that
the considerable overlap means that their destinies are intertwined.

> Yes, a README for the MetaCard distribution would be an appropriate idea. 

The MetaCard installation instructions include details about how to
change the focus model for mwm and olwm (which together account for
about 98% of our installed base).  But these two both come configured
with explicit focus from the vendors, so there's no need to change
them in most cases.  And although you're correct that this is a
site/distribution decision, I think you underestimate the importance
of the recommendations (in the form of default settings) made by the
developers of the individual packages.

> $ and market share, and the answer would come from a customer vote. 

Even though you're not selling fvwm, it is certainly in all of our
bests interest that the largest number of people find it easy to learn
and easy to use (especially on most Linux systems, where fvwm is the
default window manager).  Unless you care to dispute the fact that
most people are familiar with explicit focus, or that explicit focus
is easier to learn for novices, the correct default setting seems clear.

> the part of Microsoft users (;^)

I actually find it confusing, unless these Windows users are former
workstation users.  Windows is exactly the kind of environment that I
was refering to that doesn't work very well with pointer focus.
Actually the problems aren't as bad in Windows applications as they
are with X applications because Windows has floating palettes that
stay on top even when they lose the focus, and because there is no
way to do "active focus" applications in Windows (clicking in a window
always activates that window in Windows).

It's also confusing because pointer focus really only has advantages
when you're dealing primarily with xterm-type windows (as I invariably
discover is the standard tool of pointer focus afficianados).  When
your rarely or never use them, pointer focus is just a pain in the ass
because you're constantly having to move the mouse before you can type
in dialogs and such.

> > and not fvwm's lack of support for MetaCard.

This is really putting the cart before the horse: you buy a computer
to run applications, not a window manager.  If your applications work
with other window managers but not fvwm, it's fvwm that's broken, not
the applications.  We'd like to support Linux as best we can, and to
support choice in window managers on other workstations.  But to do
this we need better compatibility between fvwm and either mwm or olwm.
  Regards,
    Scott

---

From: Leeman Strout <[email-masked]>
Date: Wed, 23 Oct 1996 15:07:16 -0400 (EDT)

> is the right thing to do.

Well coming from the standpoint of a person that *started* windows-type
GUI interface use on Win3.1 (*blech*) and was migrated to olwm, the very
first thing I did in my search to customize olwm to my liking was find out
what the whole mouse focus thing was.  I instantly fell in love with mouse
focus, and have used it ever since (ol(v)wm, fvwm, win95, NT4).  As for
'de facto' standards, they just *happened* to pick click-to-focus as the
default back in the beginning (posibly influenced by MS, or who knows what
else) and it's stuck like that.  But that's not the point.  Whether or not
fvwm has click-to-focus as default, any software that expects to compete
on the market should *gracefully* handle the possibilities.  Whether or
not these problems are 'insurmountable' there are ways of at least dealing
with them.

> best for the X and UNIX community as a whole?

What I'd like to know is:  what 'new user' is going to be installing their
own copy of fvwm?  It's up to the site system admin to determine what he
wants as default for all his users.  I don't even know what the defaults
are for any of my software as I read the documentation and decide then
what behaviour I want.  It's the job of the admin to make the environment
suit those people he's maintaining systems for, not necessarily the
software developers responsibility.  It'd be nice if they supply a decent
set of defaults, and in the realm of fvwm I see that being what the
majority of users wants (not 'de facto' standard) which just happens to be
mouse-focus from what I've heard.

> developers of the individual packages.

What if the user doesn't *want* the focus to be click-to-focus?  And as
for the recommendations, obviously those are for the developers of each
individual package to make.  Maybe fvwm suggests mouse-focus because all
the development people like it more?  So be it.

> is easier to learn for novices, the correct default setting seems clear.

Whether or not the correct default setting is clear, you should be
allowing for the obvious fact that many people prefer mouse-focus, and
will continue doing so.

> because you're constantly having to move the mouse before you can type

Whether or not pointer(mouse)-focus is confusing is up to the individual
user.  I can't stand click-focus, it's bothersome.  Instead of moving my
mouse to within a windows constraints, I get to move it to any of the
handles (which I make miniscule as they get in my way) and with sheer luck
click on the handle to bring it to focus.  As you may have noticed,
pointer focus has it's main advantage with xterm (or single window input)
applications.  These are the realm of the developer.  Editors (whether
true X-editors or vi in an xterm) are my mainstay.  WordPerfect,
FrameMaker, and vi in an xterm.  So face it - fvwm started as a developers
choice, so obviously it's going to have remnants of that past even as it
becomes a favorite in mainstream useage.

As for having to move to the dialog box to type things in, I rather
appreciated the method olwm used.  If you explicitly activated the dialog,
warp the pointer and grab focus.  If not, map the window and don't grab
focus or warp the pointer.  The real beauty would be warping the pointer
to a dialog box, and then unwarping it back to its original position.

> this we need better compatibility between fvwm and either mwm or olwm.

I buy my computer to run apps, and get fvwm to have a window manager I
like, (with mouse-focus).  If my app doesn't work with my window manager
the way *I* want my window manager to work, it's the app that's broken.

Leeman Strout
[email-masked]

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Wed, 23 Oct 1996 15:46:03 -0400

>>>>> "SR" == Scott Raney <[email-masked]> writes:

    SR> Perhaps it was a bit strong, but we've been pointing out the
    SR> inherent and insurmountable problems of using pointer focus
    SR> with real GUI applications

I've never seen such a list posted to this forum.  Why don't you post
your list of problems and let us debate them point by point?  I'd
especially like to know what it is about your application that doesn't
work with pointer-focus.  I really don't buy the argument that
pointer-focus is inherently flawed.  And what is your definition of a
`real GUI application'?

    SR> And the statement is true: explicit focus is the de facto
    SR> industry standard

Hmm.
    
    SR> *You* know how to set up fvwm and will probably be changing
    SR> the configuration anyway to suit your needs, so why not just
    SR> make the default the one that's best for the X and UNIX
    SR> community as a whole?

Double hmm.

    SR> The MetaCard installation instructions include details about
    SR> how to change the focus model for mwm and olwm (which together
    SR> account for about 98% of our installed base).

Are you saying that if I wanted to use MetaCard I'd have to buy into
click-to-focus for my entire desktop?!  I have no idea what MetaCard
is or does, but not cooperating with pointer-focus would a huge
disincentive for me ever using a product -- especially if it were GUI
product!  (or at least I'd complain loudly and often on the bug list
:-) I'm sorry but that just seems very arrogant for an application to
force this global change on its users.  I certainly don't begrudge
those who like click-to-focus since its inherently a religious issue,
but remember, the key initial in GUI is `U'!  :-)

But maybe I'm jumping to conclusions about the interoperability
problems of MetaCard and pointer-focus.  Please clarify!

    SR> Unless you care to dispute the fact that most people are
    SR> familiar with explicit focus, or that explicit focus is easier
    SR> to learn for novices, the correct default setting seems clear.

Do you have statistics.  I'd really like to know how many of users
that are aware of having a choice between the two models, actually do
prefer to use click-to-focus, as opposed to just having no idea they
had a choice and using whatever mwm or dtwm gives them as a default.
You might be right, but I'd still like to see the results of a study.

> the part of Microsoft users (;^)

Thank goodness I found Xmouse on Microsoft's web pages.  Win95
suddenly because moderately useful for me.

    SR> I actually find it confusing, unless these Windows users are
    SR> former workstation users.

As I (unashamedly) admit I am.  And anyway, since I've begun using
Xmouse, I haven't had any problems with any of the Win95 applications
I use.
    
    SR> Windows is exactly the kind of environment that I was refering
    SR> to that doesn't work very well with pointer focus. Actually
    SR> the problems aren't as bad in Windows applications as they are
    SR> with X applications because Windows has floating palettes that
    SR> stay on top even when they lose the focus, and because there
    SR> is no way to do "active focus" applications in Windows
    SR> (clicking in a window always activates that window in
    SR> Windows).

Well, I'm still unconvinced that point-focus can't work just fine,
even for applications with lots of windows.  Take Grail
<http://monty.cnri.reston.va.us/grail/>, a free web browser we've
written that's implemented in Python/Tk.  In the next release, you'll
be able to drive the thing almost entirely from the keyboard, and even
as separate top level windows pop up and down (e.g. to interact with
the Bookmarks, History, or File dialogs), focus is managed correctly
to the subwindows without ever having to move the mouse (as long as
its one of the application's top level windows), even with
pointer-focus.  Okay, I'm not an Xpert so maybe there's some inherent
design flaw in X I'm not aware of.  I've just never seen it as a real,
unsurmountable problem with all the apps I've used over the years.
Even XEmacs (although it has some bugs) handles focus management in
subordinate top-level windows that do not contain the pointer.

    SR> It's also confusing because pointer focus really only has
    SR> advantages when you're dealing primarily with xterm-type
    SR> windows (as I invariably discover is the standard tool of
    SR> pointer focus afficianados).  When your rarely or never use
    SR> them, pointer focus is just a pain in the ass because you're
    SR> constantly having to move the mouse before you can type in
    SR> dialogs and such.

Nope, its just that not all applications manage active focus
correctly.  Its one of the main reasons why I can't stand Netscape on
X.  I hit Meta-O and the dialog that pops up doesn't get focus.  It
was nearly trivial for me to add this to Grail, *and* to move focus
back to the original window when finished interacting with the dialog.

    >> Which only goes to show that the problem is MetaCard not
    >> supporting fvwm, and not fvwm's lack of support for MetaCard.

    SR> This is really putting the cart before the horse: you buy a
    SR> computer to run applications, not a window manager.  If your
    SR> applications work with other window managers but not fvwm,
    SR> it's fvwm that's broken, not the applications.

Sorry, but this is backwards, unless I bought my computer to only run
MetaCard.  My applications should honor my environmental preferences.
They should not dictate to me what's for my own good especially for
such fundamentally religious issues as focus policy.

-Barry

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Wed, 23 Oct 1996 15:59:21 -0400

>>>>> "LS" == Leeman Strout <[email-masked]> writes:

    LS> As for having to move to the dialog box to type things in, I
    LS> rather appreciated the method olwm used.  If you explicitly
    LS> activated the dialog, warp the pointer and grab focus.  If
    LS> not, map the window and don't grab focus or warp the pointer.
    LS> The real beauty would be warping the pointer to a dialog box,
    LS> and then unwarping it back to its original position.

I don't think it's necessary in X to warp the pointer (usually a bad
thing) to redirect focus to any other top-level window within an
application.  I seem to remember this being called `passive' focus
model in X, but again, I'm not an Xpert.

-Barry

---

From: Ondrej Popp <[email-masked]>
Date: Wed, 23 Oct 1996 22:11:32 +0100

> You might be right, but I'd still like to see the results of a study.

maybe we should vote on this, to get some impression.
For me, I use pointer focus. I remember when I was first
introduced to the X-window system, I immediately adopted
the pointer-focus model. I have been using it since.
I remember that, when I was a novice with this, I found it counfusing
having the pointer in one window and typing in an other... 

Ondrej

---

From: Scott Raney <[email-masked]>
Date: Wed, 23 Oct 1996 14:39:29 -0600 (MDT)

> maybe we should vote on this, to get some impression.

A reasonable thing to do, but only if you ask the tens of millions of
Windows and Mac users and billions of non computer users to vote too.
After all, we're talking about what's best for most people, not the
few power users who know exactly what the issues are and what they
want.

> the pointer-focus model. I have been using it since.

You were probably not given any choice and accepted the default.  This
is a common event, and one we should recognize means that the default
setting is important.

> having the pointer in one window and typing in an other... 

Actually, early research at Apple clearly showed that the opposite was
more likely to be a problem, usually because a dialog opened.  For
example, the naive user's first reaction when a file selection dialog
opens should be to attempt to type in a file name.  This only works if
the dialog gets the focus when it's opened.  Unless you want to head
down the slippery slope of pointer warping, this means explicit focus.

Your confusion was undoubtedly due to the situation where you've got
multiple xterm windows open, since the opposite problem occurs when
you've got a modern GUI application (and by that I mean one that uses
dialogs and palettes).  It's still amazing to me that people who work
primarily with the "stone age" version of GUI technology (xterms) have
the nerve to stand up and say that pointer focus is superior and
should be the default.  My whole point is that given the choice, most
people want true GUI applications instead of command-line tools, and
that these applications work better with explicit focus.  A point that
no one has provided a defensible argument against.

If we can't do any better than xterms as a primary work environment,
the X market is going to continue its slide toward oblivion because
people just won't bother with it when there are GUI systems that give
them everything they want and need without having to use a
command-line interface.
  Scott

---

From: Jim Nicholson <[email-masked]>
Date: Wed, 23 Oct 1996 17:01:03 -0400 (EDT)

My apologies to the list for flaming. While I stand by the
substance of my comments, the tone was inappropriate. 

Focus style is a matter of personal preference. Applications should not
assume a certain focus style. If an application design requires a
particular focus style, the requirement should be documented and the
developer should make a good faith effort to either inform users of the
procedure for setting the desired style, or point users at the source of
this information. 

Explicit focus is fine in a novice setting, but it works against the user
who understands and wants to take advantage of a multitasking environment. 
Just because I do something that makes a program request input (i.e., I
click on an icon that brings up a dialog box) doesn't mean that I want to
(or even can) provide that input right away. Consider an analogy:  Let's
say that you call Bob and leave a message for him to get back to you, then
hang up and call Joe. While you are dialing Joe, Bob gets your message and
calls you back. In the explicit focus world, you don't get a choice: Joe
is put on hold (or hung up on - I can provide an example) and you have to
talk to Bob.

Why do developers treat free software differnet from commercial? Imagine
that you are porting a Windows app to a Motif environment, and you
encounter a similar difference between Windows' and Motif's way of doing
things. Would you threaten to not support Motif? Of course not; you would
alter your design. 

Some of us choose fvwm because the industry standard doesn't work
for us. If the only concern is to comply with "standards", why bother
developing for any other platform than Microsoft? That's where the
industry is. Thouse of us who choose to use free software such as Linux
and fvwm are natually testy about criticisom that amounts to  "it's not
the same as motif."

- Jim

---

From: Scott Raney <[email-masked]>
Date: Wed, 23 Oct 1996 15:13:49 -0600 (MDT)

(big snip)

> be able to drive the thing almost entirely from the keyboard,

Gee, and to think you could do this with Windows and OS/2 applications
5 years ago...

> and even
> pointer-focus. 

How, by warping the mouse?

> Okay, I'm not an Xpert so maybe there's some inherent

XEmacs is a pretty poor example of good UI design IMHO.  It's very
efficient to work with (we use it here), but if you tried to sell it
to a Mac or Windows user they'd laugh you right out of town.

> X.  I hit Meta-O and the dialog that pops up doesn't get focus.

I see, let's take the only decent UI that the vast majority of X users
have ever used and ruin it because it doesn't work well with the
environment that works well with xterm windows.  Your argument goes
*exactly* to my point: users new to computers are much more likely to
use Netscape than they are to use xterms.  Fvwm should come with the
defaults set to take this into consideration.

>  It

How?

> such fundamentally religious issues as focus policy.

So you're saying that application vendors have no right to expect any
sort of standardization of desktop environments?  Hope you like hand
building all your applications...

---

From: Robert Elz <[email-masked]>
Date: Thu, 24 Oct 1996 07:27:04 +1000

Date:        Wed, 23 Oct 1996 14:39:29 -0600 (MDT)
    From:        Scott Raney <[email-masked]>
    Message-ID:  <[email-masked]>

Most people like what they used first, that's what their belief
system is set up to believe is naturally correct.   This applies
to window systems, editors, operating systems, cars, ...

Most new users (first time users) I have observed can't believe
that you actually have to click the button to make a window active,
and keep forgetting.   Sure they learn soon enough, but it is by
no means intuitive.

yes, it certainly is, and should be mouse focus, not click, always.
    
    This only works if the dialog gets the focus when it's opened.

yes.

    Unless you want to head down the slippery slope of pointer
    warping, this means explicit focus.

Rubbish - simply create the dialog box under the pointer.   Then
you know the pointer will be in the window without warping.  What's
more it is more natural, as the pointer will be in the app window,
and thus in the area where the user is concentrating.   It is only
those rude applications that insist on putting pop-ups in the middle
of the screen which cause problems.

If you want to (and you probably do) work well with users who do
use click focus, and so may have moved the pointer somewhere in
oblivion, check if the pointer is in the window, if it is, put the
dialog under it, if it isn't, and the app still has focus, then
put the dialog anywhere over the window.  If the app doesn't have
focus, then the user is working elsewhere, and the dialog should
not demand attention in any case.

Your other complaint (pop-ups being obscured) I think was a
complaint about auto-raise, which I consider a heinous crime against
morality, and would like to ban totally, if the user wants a window
on top, let it be explicitly moved to the top, not just spring
there.

kre

ps: I use both xterms & true guis, whichever I use, pointer/mouse
focus always works better.  Some apps annoy me no end, because they
contrive to make life difficult rather than easy, but that isn't
the fault of the focus model.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Raymond Toy <[email-masked]>
Date: Wed, 23 Oct 1996 17:28:04 -0400

>>>>> "BAW" == Barry A Warsaw <[email-masked]> writes:

[discussion about Metacard and focus deleted]

    BAW> Sorry, but this is backwards, unless I bought my computer to only run
    BAW> MetaCard.  My applications should honor my environmental preferences.
    BAW> They should not dictate to me what's for my own good especially for
    BAW> such fundamentally religious issues as focus policy.

Hear, hear.  Barry hits it on the nose.

Ray

---

From: Ondrej Popp <[email-masked]>
Date: Wed, 23 Oct 1996 23:28:19 +0100

> is a common event, and one we should recognize means that the default

Well, actually as I remember it, click to focus was the default.
I guess because the window manager was motif based, and for motif
click to focus was the default. I just didnt like it. So I figured 
out how to change this. XmNkeyboardFocusPolicy was one of the first
resources
I learnt.

> down the slippery slope of pointer warping, this means explicit focus.

Well, I agree that its convenient when a dialog pops up, and the field
you want gets immediately the focus. But usually there is more than one
(text) field in this dialog. And the field you want is not always the
field
that has the explicit focus. For me, I found it always annoying
discovering
that I actually typed things into the wrong fields because I just forgot
to 'click'.
I know it works much better if you use the return and tab keys but
somehow I 
always liked pointer focus better. Especially if the application has the
'highlight on enter' resource set. It makes a much more lively
impression.
But, anyway, thats what I did.. I'll look around at my work, see what
other
people are using. 

Ondrej

---

From: Michael Tiefenback <[email-masked]>
Date: Wed, 23 Oct 1996 17:34:26 -0400 (EDT)

Scott,

(and the fvwm list; I include this because there may be programmers out
there who see ways to implement what may be worthwhile in what I have to
say.  I will contribute no more to this thread, but I'm trying to be 
constructive in this addition.)

Not to bash anyone or anything like that, but to my feeble understanding,
the dialog boxes you seem to be talking about are graphically disjoint
from the main window.  The features you seem to be favoring include the
dialog boxes logically in the main window focus (presumably a
multi-tasking machine is involved here and one should be able to receive
mail and such things without closing the application of primary interest),
but it should be possible to transfer the focus to another window.  

The ability to type into a dialog box which has snatched the focus from
the main window (we might choose to view it as an appendage of the main
window, attached by virtue of its being really the same application) is
useful.  But the fact that the dialog and main window are separated is
really an artificial thing.  If you have used (for instance) tcl/tk to
generate windows, you know that events calling for input information or
display features can result in either calling up another window or in
extending or otherwise repacking the existing window.  You may pass the 
focus around among the sub-widgets as you please.  The features you
mention seem to treat the dialogs as somehow extensions of the main
window, and you should be able to do the same thing even if they live in 
different windows.

Any implementation of pointer focus which forced each subwindow of an app
to be treated independently of its parent, and on equal footing with any
other window, *could* disable this feature.  I believe that the X wm
standards do not do this.  The X windows standard seems to allow dialogs
to be ignored by the window manager.  Can't you as the programmer
(institutionally) take the input focus which remains with the main window,
and knowing what dialog was requested, feed the input stream to that
dialog?  When you sense the dialog getting explicit focus or the main
window losing it as a result of a user's direct mouse actions, you could
go back to the other way of doing things.  Since the dialog is truly a
child of the parent process, they should have access to the same
information.  There seems to be no necessary conflict with either
click-to-focus or pointer-focus paradigms. 

> No, you click on a button (or choose from a menu, or activate a menu
> item with a mnemonic or accelerator) and it opens a dialog that gets
> the focus.  You then type whatever you want and then close it by
> pressing return, upon which the dialog closes and focus returns to the
> application window that had it before.  This is the most standard
> operating method of modern GUI applications, and it just doesn't work
> very well with pointer focus.

You seem to insist that in pointer-focus mode, there is no way to get the
info for the dialog without transferring focus to the sub-window.  This
seems to be a programming obstacle, not a window manager matter.  Today's
commonly used techniques are not those of a decade ago, and today's
techniques stand about as much a chance of being those of a decade from
now.  Developing programming techniques to handle both pointer- and
click-focus would give you a headstart for tomorrow's work.  It shouldn't
be a great obstacle, unless the program really can't know which window 
has focus.  In which case the standards should maybe be modified.  But 
then again, Scott's first message mentioned an apparent ConfigureNotify 
event failure from fvwm....

Michael Tiefenback

---

From: Merlin Hansen <[email-masked]>
Date: Wed, 23 Oct 1996 16:38:42 -0600 (CST)

[snip]
> Gee, and to think you could do this with Windows and OS/2 applications

Nice attitude! You have a problem and an opinion so you start flaming
others?!?  I would have thought you were attempting to initiate
conversation in a productive forum, not start a "my apps/opinions are more
advanced then your apps/opinions" war. 

> > X.  I hit Meta-O and the dialog that pops up doesn't get focus.
[snip]
> defaults set to take this into consideration.

Hmm, first off all the developers here use xterm based apps extensively so
to them an "environment that works well with xterm windows" is definitely a
priority.

[snip]
> building all your applications...
Secondly, I would like to thank the person who mentioned Xmouse.exe.  I
just got it, installed it and played with it; via swithing between several
apps, selecting options that open dialog boxes, etc.

I love it, and will definitely be keeping it!

Now Scott.  Have you checked out Xmouse and how it works?  Bring up an
application (it has focus :), open a dialog box by clicking one of the apps
buttons (what do you know, the dialog box has focus even though the mouse
is on the main windo :), type and press enter (dialog box closes and focus
returns to app WITHOUT moving the mouse :), try another dialog box then
while it is open move the mouse to another apps window (the new app gets
focus :), move the mouse back to the dialog OR the main window of the
dialogs app (the DIALOG box gets focus in BOTH cases :).

This is how pointer focus should work...IMHO.  Now I do not know if the
problem is with your application (MetaCard) or with fvwm (I doubt it, MO)
and I really don't care what the default focus paradigm is (I will change
it if necessary).  BUT if you application doesn't work with my enviroment
the way I think it should (pointer focus compatible) I will find another
application, NOT another window manager.

Merlin.

-- 
| Develcon Electronics    | E-mail   : [email-masked]        |
| 856-51 St. E, Saskatoon,| Web Site : http://www.develcon.com           |
| Saskatchewan, Canada.   | DISCLAIMER : These are my opinions & views,  |
| S7K 5C7                 | NOT necessarily those of my employers.       |
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Wed, 23 Oct 1996 20:59:54 -0400

Phew, so much traffic, so much misinformation, so much real work to
do, so many hunger pangs.  Well, I'll just dig in and try to remain
calm... :-)

    SR> A reasonable thing to do, but only if you ask the tens of
    SR> millions of Windows and Mac users and billions of non computer
    SR> users to vote too.

Ah, but do Mac and Windows users have a choice?  You can't even ask
such a question if they don't.  Here's one, of all the Windows users
that have tried Xmouse, how many like it and how many don't?  It's
still probably a useless point to argue, unless you really don't care
about selling product to pointer-focus users.
    
    SR> Actually, early research at Apple clearly showed that the
    SR> opposite was more likely to be a problem, usually because a
    SR> dialog opened.  For example, the naive user's first reaction
    SR> when a file selection dialog opens should be to attempt to
    SR> type in a file name.  This only works if the dialog gets the
    SR> focus when it's opened.

I agree so far.
    
    SR> Unless you want to head down the slippery slope of pointer
    SR> warping, this means explicit focus.

Here's where I disagree (details to follow).  And I think this
assertion is the crux of the current flamewar.

    SR> Your confusion was undoubtedly due to the situation where
    SR> you've got multiple xterm windows open, since the opposite
    SR> problem occurs when you've got a modern GUI application (and
    SR> by that I mean one that uses dialogs and palettes).

This is a red herring.  Let's instead talk about multiple disjoint
applications, by which I mean separate processes in the Unix sense
each with their own window, and a single process that can display
multiple windows.  So now we have two situations:

- Switching focus between processes requires the help of the window
  manager.  You can't solve this problem by advocating either focus
  model without focus grabs, pointer warpage, complex IPC's or other
  nasty things.  I don't really see how explicit focus could make
  anybody's life easier (or harder) in this situation.

- Switching focus between windows in a single, multi-window process.
  This can be done under X with pointer-focus policy and no pointer
  warpage or focus grabs.  I have two existance proofs: 1. In XEmacs,
  I can by way of keystrokes, create a bunch of new top-level window
  (i.e. ones whose parent is the FVWM root window).  By another couple
  of keystrokes I can switch focus back and forth between any of these
  windows.  2. In Grail, I can by way of keystrokes, pop up the
  Bookmarks dialog.  By another few keystrokes I can traverse around
  in the bookmarks tree, opening and closing nodes, even triggering
  Grail to visit a URL.  I can popup further top-level windows which
  allow me to change bookmark entries via a little form dialog.  When
  I hit return in the form dialog, my edits are applied and focus
  returns to the bookmark dialog.  I hit return again, my bookmarks
  get saved, the dialog gets withdrawn, and focus returns to my main
  browser window.

  IN NEITHER CASE IS THE POINTER WARPING ONE MILLIMETER!

    SR> It's still amazing to me that people who work primarily with
    SR> the "stone age" version of GUI technology (xterms) have the
    SR> nerve to stand up and say that pointer focus is superior and
    SR> should be the default.

Oh, please.  Come on, admit it, you're trolling!  I'm going to ignore
those snide remarks from now on.

    SR> Well, in *true* pointer focus there is no keyboard traversal
    SR> at all, you have to move the mouse into each field in turn to
    SR> fill out a form. I don't see too many people advocating we go
    SR> back to *that*.  Its about time we take the next step, or at
    SR> least reduce the incidence of corruption of new users by
    SR> making the default explicit focus.

How do you go from your "*true* pointer focus" to default explicit
focus?  You're completely ignoring the model where pointer location
designates the application that receives keyboard events, and the
application is free to redirect window focus to any top level window
under its control.  This is what XEmacs does.  This is inherent in Tk,
and thus Grail gets it for free (I take no claim for doing anything
more than reading the manpage and playing with some Python code to
understand what's possible :-).

    SR> No, you click on a button (or choose from a menu, or activate
    SR> a menu item with a mnemonic or accelerator) and it opens a
    SR> dialog that gets the focus.  You then type whatever you want
    SR> and then close it by pressing return, upon which the dialog
    SR> closes and focus returns to the application window that had it
    SR> before.

Sounds cool to me.
    
    SR> This is the most standard operating method of modern GUI
    SR> applications, and it just doesn't work very well with pointer
    SR> focus.

I must really be misunderstanding you, because I have no problem with
this in properly written applications using pointer focus.  I really
would like more detail on exactly what you think is the problem.

    Me> and even as separate top level windows pop up and down
    Me> (e.g. to interact with the Bookmarks, History, or File
    Me> dialogs), focus is managed correctly to the subwindows without
    Me> ever having to move the mouse (as long as its one of the
    Me> application's top level windows), even with pointer-focus.

    SR> How, by warping the mouse?

Nope.  Tk has a number of focus management commands and it imposes its
own rational focus management policy on the toolkit.  I won't
reproduce the entire Tk focus.n manpage here, since its free software
and you can get it and read it yourself.  Suffice to say that if I
have a window `.w' I can redirect focus to it with `focus .w' (well I
think I've accurately translated the Python equivalent into Tcl :-).
In Python, if `frame' is a Tkinter.Toplevel instance, then
frame.focus_set() redirects focus into the window.

    SR> XEmacs is a pretty poor example of good UI design IMHO.  It's
    SR> very efficient to work with (we use it here), but if you tried
    SR> to sell it to a Mac or Windows user they'd laugh you right out
    SR> of town.

First, we're not talking about overall UI design, and besides I think
XEmacs is well designed given what the application is.  It (more so
than FSF's Emacs IMHO) is one of the few applications that works
pretty well for novices but adapts to users as they gain their power
through experience.  And second, it sure is funny how many Mac and
Windows users I've heard, who need a such a powerful integrated
programming environment ask for Emacs on their platforms.  Oh well,
that's all tangential to the discussion at hand.

    Me> Nope, its just that not all applications manage active focus
    Me> correctly.  Its one of the main reasons why I can't stand
    Me> Netscape on I hit Meta-O and the dialog that pops up doesn't
    Me> get focus.

    SR> I see, let's take the only decent UI that the vast majority of
    SR> X users have ever used and ruin it because it doesn't work
    SR> well with the environment that works well with xterm windows.

Netscape or MSIE are probably the applications that most inexperienced
computer users are familar with.  I might argue about their decency,
but the specific problem I describe above is not inherent in the focus
policy.  It's either present because the toolkit they use is buggy, or
the application doesn't manage focus properly, or it was an explicit
design decision not to support this, or they just haven't gotten
around to ironing out its use for power users (or all their internal
power users really use Grail instead, but won't tell anybody :-)

    SR> Your argument goes *exactly* to my point: users new to
    SR> computers are much more likely to use Netscape than they are
    SR> to use xterms.  Fvwm should come with the defaults set to take
    SR> this into consideration.

Fvwm has nothing to do with it.  If, when the Open Location dialog was
popped up, Netscape redirected its application's focus to that window,
the problem would be solved.  It *can* be done with pointer-focus
policy, no pointer warping, no server grabs, and no need to pop the
window up under the cursor.  Your application, or toolkit, just has to
provide the right kind of focus management policy.  Maybe that's hard,
but that's an engineering problem, not made impossible by the design
of pointer-focus policy.

    Me> It was nearly trivial for me to add this to Grail, *and* to
    Me> move focus back to the original window when finished
    Me> interacting with the dialog.

    SR> How?

See the explanation above.  Read the Tk manpages.  Read the Tk source
or the XEmacs focus management source.  I encourage you to download
Python, install and Tk and play with it, and see for yourself.  As I
say, I'm not an Xpert so I can't tell you what's happening under the
hood.

    SR> So you're saying that application vendors have no right to
    SR> expect any sort of standardization of desktop environments?
    SR> Hope you like hand building all your applications...

So are you saying users have no right to customize their desktops to
increase their productivity?

    > This is commonly done using an application-modal keyboard grab
    > so that you don't have to move the pointer to type in the
    > window.  It can also be done via warping the mouse or popping
    > the dialog box up underneath the pointer.

    SR> Neither of these are practical, the first because warping the
    SR> pointer violates all GUI style guides (other than the finally
    SR> obsolete OpenLook), and the second because it could result in
    SR> the window opening partially off screen.

Agreed on both points.

    SR> I wasn't trashing his app, in fact it sounds very well
    SR> implemented. But I found it strange for him to be citing an
    SR> app as an example of how things should be done when it
    SR> obviously took considerable effort to make it work like
    SR> Windows and OS/2 and Motif applications are *required* to, and
    SR> have been for years.  If he didn't have to spend so much time
    SR> fighting with pointer focus, he could have implemented some
    SR> really cool new features instead.

Funny.  All I had to do was read the Tk manpages. :-)  Ousterhout did
the fighting for me.  Which is great because I (and the rest of the
Grail team) could implement lots of really cool new features.

    SR> And I certainly wouldn't claim that Netscape is perfect, but
    SR> it *is* Motif compliant which can't be said for xterm or most
    SR> other apps (including most Tk apps) that X users end up using.

All I can say here is that if the Motif toolkit doesn't allow you to
manage focus as flexibly and rationally as the Tk toolkit does, then
either the Motif toolkit implementation is buggy, or the Motif
specification is broken.  I suspect neither is the case, but I have
never written a Motif-toolkit based application so I wouldn't know.
It certainly isn't an inherent property of X, or other X-compatible
toolkits.

Not to say Tk is perfect, but at least for focus management it
provides exactly the abstration you need.

Time to go home.  I'm hungry. :-)

-Barry

---

From: Scott Raney <[email-masked]>
Date: Sat, 26 Oct 1996 16:33:13 -0600 (MDT)

> This is a red herring.

An application that opens dialog boxes is a red herring?  I disagree,
I think *that* is the most important class of applications.  If you
think xterms are more important, we'll just have to leave the argument
at that.

(snip)

> frame.focus_set() redirects focus into the window.

As best I remember (or can determine from the Tk documentation) the
focus comand only works with child windows within a toplevel window:
if your application opens a dialog box on a pointer focus system, you
*must* move the mouse into the dialog before you can star using it.

> but that's an engineering problem, not made impossible by the design

I think this is wrong, at least as I understand pointer focus.  Maybe
you're thinking of sloppy focus or something.  Pointer focus is where
the window with the mouse cursor in it has the keyboard focus.  There
are no exceptions to this rule, and warping the cursor is the only way
an application can ensure that one of its windows gets the focus.

> It certainly isn't an inherent property of X, or other X-compatible

Setting the focus to individual controls in Xt/Motif is as easy as it
is with Tk.

> provides exactly the abstration you need.

Maybe within a dialog window this is true, but since Tk doesn't
support modal dialogs, it's stuck recommending "grabs" as a standard
UI technique (see Chapter 24 of Ousterhout's Tcl book).  You think you
dislike explicit focus and modal dialogs, wait till you experience a
Tk app grabbing the whole server because that's the only way to do
this sort of thing in Tk.
  Regards,
   Scott

---

From: "Barry A. Warsaw" <[email-masked]>
Date: Sat, 26 Oct 1996 19:12:36 -0400

>>>>> "SR" == Scott Raney <[email-masked]> writes:

    SR> As best I remember (or can determine from the Tk
    SR> documentation) the focus comand only works with child windows
    SR> within a toplevel window: if your application opens a dialog
    SR> box on a pointer focus system, you *must* move the mouse into
    SR> the dialog before you can star using it.

You must be reading some old Tk documentation.  This is certainly not
the case any more.  FTR: I'm using Tk 4.1 and Python 1.4 (although
that shouldn't matter).

    SR> I think this is wrong, at least as I understand pointer focus.
    SR> Maybe you're thinking of sloppy focus or something.  Pointer
    SR> focus is where the window with the mouse cursor in it has the
    SR> keyboard focus.  There are no exceptions to this rule, and
    SR> warping the cursor is the only way an application can ensure
    SR> that one of its windows gets the focus.

This is just not true.  An application can manage focus internally
among its top-level windows, essentially redirecting focus to any of
their top-level windows (and of course to any widget within those
windows), as long as the pointer is in any one of the application's
windows.  I've appended a very simple Python/Tkinter application to
prove it.

Save this code in a file called Focus.py, and run it by typing `python
Focus.py' in your shell.  It will pop up a window with two buttons in
it.  Of course, make sure your FVWM is set up to do
focus-follows-mouse, and put the pointer into this window.  Now, hit
TAB until the `Dialog...' button is highlighted, then hit space.  A
second top-level window will pop up, and focus will be directed into
it.  Notice that FVWM does the Right Thing in that the dialog's border
is highlighted.  Notice further that the pointer has never left the
first window and no grab is in effect.  TAB until the `Done' button is
highlighted, and hit space.  The dialog will withdraw and the first
window will regain focus.

    SR> Maybe within a dialog window this is true, but since Tk
    SR> doesn't support modal dialogs, it's stuck recommending "grabs"
    SR> as a standard UI technique (see Chapter 24 of Ousterhout's Tcl
    SR> book).

You should check out the latest release of Tk.  I haven't got the
manpages here at home, but I don't think this is true with Tk 4.1.

-Barry

-------------------- snip snip --------------------Focus.py
import sys
from Tkinter import *

class Dialog:
    def __init__(self, master, num):
	self.__master = master
	self.__win = Toplevel(master)
	label = Label(self.__win, text=`num`)
	label.pack()
	btn = Button(self.__win, text='Done', command=self.done)
	btn.pack()
	self.__win.focus_set()

    def done(self):
	# must transfer focus before destroying the widget
	self.__master.focus_set()
	self.__win.destroy()

class App:
    __num = 1

    def __init__(self):
	self.__master = Tk()
	btn = Button(self.__master, text='Dialog...', command=self.popup)
	btn.pack()
	quit = Button(self.__master, text='Quit', command=self.quit)
	quit.pack()

    def go(self):
	self.__master.mainloop()

    def quit(self):
	sys.exit(0)

    def popup(self):
	d = Dialog(self.__master, self.__num)
	self.__num = self.__num + 1

if __name__ == '__main__':
    app = App()
    app.go()

---

From: Scott Raney <[email-masked]>
Date: Sat, 26 Oct 1996 18:42:22 -0600 (MDT)

> windows.  I've appended a very simple Python/Tkinter application to

I stand corrected: an application can do this by calling
XSetInputFocus on the other window without prompting by the WM to do
so (you can do this with MetaCard too by explicitly setting the focus
to a field within a dialog in an openCard or openStack handler).  Mwm
supports this behavior as well.

It should be possible to do this with Xt/Motif too, but I can't find
any Motif applications that work this way, and there are no built-in
Xt or Xm commands to do this, and so I'd guess they're very rare if
they exist at all.  I can't find any reference to this technique in
any of the style guides nor in any of the Motif books we have.	The
ICCCM is pretty vague in this area, other than to state that it's
important that you set the revert_to field correctly lest your app
screw up keyboard focus for all the others.

Thanks for pointing this out.  I don't find it surprising that this
technique isn't very commonly used, however.  Though I can see how it
is useful in getting around one of the major problems with pointer
focus, it has the feel of an unecessary hack to me.  Why should the
app developer have to deal with things at this low of a level?  The WM
should manage the direction of focus to dialogs when they open, and
they all do this correctly automatically if you use explicit focus.

  Regards,
    Scott

---

From: Kai Grossjohann <[email-masked]>
Date: 27 Oct 1996 12:12:33 +0100

>>>>> Barry Warsaw writes:

  Barry> Fvwm has nothing to do with it.  If, when the Open Location
  Barry> dialog was popped up, Netscape redirected its application's
  Barry> focus to that window, the problem would be solved.  It *can*
  Barry> be done with pointer-focus policy, no pointer warping, no
  Barry> server grabs, and no need to pop the window up under the
  Barry> cursor.  Your application, or toolkit, just has to provide
  Barry> the right kind of focus management policy.  Maybe that's
  Barry> hard, but that's an engineering problem, not made impossible
  Barry> by the design of pointer-focus policy.

>>>>> Scott Raney writes:

  Scott> I think this is wrong, at least as I understand pointer
  Scott> focus.  Maybe you're thinking of sloppy focus or something.
  Scott> Pointer focus is where the window with the mouse cursor in it
  Scott> has the keyboard focus.  There are no exceptions to this
  Scott> rule, and warping the cursor is the only way an application
  Scott> can ensure that one of its windows gets the focus.

Come on now!  Look at these claims side by side:

(1) Using PointerFocus, the *only* way for a window to get focus is if
    the mouse pointer is in the window.

(2) Using ClickToFocus, the *only* way for a window to get focus is if
    the user clicks on it.

Now, it is very clear that no program I know of obeys rule (2), so why
should any program obey rule (1)?  IMHO, the two rules above exactly
correspond to each other.

I propose that we invent DumbPointerFocus and DumbClickToFocus which
obey rules (1) and (2), respectively, and that we reserve PointerFocus
and ClickToFocus for the obvious improvements on the two rules above.

So far, Scott has been comparing ClickToFocus with DumbPointerFocus,
which just isn't fair.

Please feel free to correct me if you disagree,
kai
-- 
Life is hard and then you die.

---

From: Scott Raney <[email-masked]>
Date: Sun, 27 Oct 1996 14:01:08 -0700 (MST)

> correspond to each other.

This is a good point.  The reason why 2) isn't an accurate description
is because the most common way a for a dialog window to get the focus
in an explicit focus environment is for the window manager to give it
the focus automatically (or to tell it to take the focus) when the
window opens.  In pointer-focus mode, they doesn't do this.

> So far, Scott has been comparing ClickToFocus with DumbPointerFocus,

It it fair, but only because in ClickToFocus environments the wm is an
active participant in the focus management process, whereas in
pointer-focus environments it is passive and the
*application-developer* is responsible for figuring out where the
focus should go each time a window opens.  Since currently very few
developers do this (and I would guess you'll be in for a long wait if
you're expecting them to change), what you need is a "clever"
pointer-focus mode in which the window manager assigns focus to
dialogs when they open.  The transient-for prop would be one good cue
for the wm to use, with the MwmHints input_mode field being another
(e.g., if the dialog is modal, you *always* want the focus to go to
that window).

> Please feel free to correct me if you disagree,

I guess I don't, except that I think "DumbPointerFocus" mode is a not
a good label for behavior you describe in 1) above.  The fact that
most applications work this way in a pointer focus environment is the
result of the design of those applications and is not determined by
WM settings (which is what is generally meant by wm "modes").
  Regards,
    Scott

---

From: Kai Grossjohann <[email-masked]>
Date: 28 Oct 1996 10:40:12 +0100

>>>>> Scott Raney writes:

  Scott> This is a good point.  The reason why 2) isn't an accurate
  Scott> description is because the most common way a for a dialog
  Scott> window to get the focus in an explicit focus environment is
  Scott> for the window manager to give it the focus automatically (or
  Scott> to tell it to take the focus) when the window opens.  In
  Scott> pointer-focus mode, they doesn't do this.

I could equally well consider ClickToFocus window managers broken
because they always give focus to a newly appearing window.  What if I
want to start a program but *don't* want to give the newly appearing
window focus?  No joy, with ClickToFocus.

  Scott> I guess I don't, except that I think "DumbPointerFocus" mode
  Scott> is a not a good label for behavior you describe in 1) above.
  Scott> The fact that most applications work this way in a pointer
  Scott> focus environment is the result of the design of those
  Scott> applications and is not determined by WM settings (which is
  Scott> what is generally meant by wm "modes").

In a way, that's true.  I guess I must agree with you that you're
comparing Really Existing PointerFocus programs (wm's and other apps)
with Really Existing ClickToFocus programs.  But the applications
should be changed so that they're not so stupid when working with
PointerFocus.  You're writing an application, so you should do
something here.  IMHO.

kai

---

From: Jason L Tibbitts III <[email-masked]>
Date: 28 Oct 1996 11:36:23 -0600

[CC list nuked]

>>>>> "SR" == Scott Raney <[email-masked]> writes:
SR> This is a good point.  The reason why 2) isn't an accurate description
SR> is because the most common way a for a dialog window to get the focus
SR> in an explicit focus environment is for the window manager to give it
SR> the focus automatically (or to tell it to take the focus) when the
SR> window opens.

Are you trying to say that in ClickToFocus mode a window manager would
automatically give the focus to any window which opens?  You're kidding,
right?  This would drive me completely insane.

I've been staying out of this, but I need to say one thing: this is a
mailing list for FVWM.  I believe that there's an entire newsgroup for
window management issues, and if this isn't FVWM specific then I'd
appreciate everyone saving my bandwidth and moving to a more appropriate
place.  (I host this list.)
-- 
      Jason L. Tibbitts III - [email-masked] - 713/743-8684 - 221SR1
System Manager:  University of Houston High Performance Computing Center
                1994 PC800 "Kuroneko"      DoD# 1723
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Scott Raney <[email-masked]>
Date: Tue, 29 Oct 1996 11:09:24 -0700 (MST)

> PointerFocus.  You're writing an application, so you should do

As I've said before, it's not us we're concerned about, it's the
people that use our product to develop applications for *their*
customers.  You're just dreaming if you seriously expect more than a
small fraction of app developers to go to the extra trouble required
to transfer focus to their dialogs when they're run in a pointer focus
environment.

According to section 5.4 of the Motif style guide, the ability to do
this not only not required, it's not even guaranteed to work in
pointer focus mode.
  Regards,
    Scott

---

From: Scott Raney <[email-masked]>
Date: Tue, 29 Oct 1996 11:31:04 -0700 (MST)

> right?  This would drive me completely insane.

Must be a lot insane people out there then, because this is the way
all Mac and Windows applications work (disregarding floating palettes
and menus, of course, the former of which are unfortunately not
supported by any X11 WM that I know of).  It is also the way mwm works
in explicit focus mode (which is the default specified in the Motif
style guide).

> place.  (I host this list.)

I disagree with this: the focus policy that should be specified in the
default .fvwm2rc file is an important issue that should be discussed
on this list.  fvwm2's violations of the Motif style guide that I have
reported previously also deserve more complete coverage:

1) windows must autoraise when given the focus (Section 5.2.2)
2) enforcing modal dialog (Section 5.2.2)

---

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 29 Oct 1996 14:24:44 -0500 (EST)

Yes there are alot of insane people out there. I for one am so sick and
tired of this stipid "StealFocus" policy on windows95 (even with Xmouse
installed) that I am going to put a real operating system and an intelligent
window manager on this box in the very near future. I will of course let it
dual boot so I can ematize with all those suffering "insane" people out
there. (Besides my kids like the PC games....)

If you really want to be creative I would suggest you allow your code to
accept other religions. You will then be ahead of others if/when your
religion changes under you. (read: religion==window_manaer_of_choice)

Randall

On Tue, 29 Oct 1996, Scott Raney wrote:

: > 
: > Are you trying to say that in ClickToFocus mode a window manager would
: > automatically give the focus to any window which opens?  You're kidding,
: > right?  This would drive me completely insane.
: 
: Must be a lot insane people out there then, because this is the way
: all Mac and Windows applications work (disregarding floating palettes
: and menus, of course, the former of which are unfortunately not
: supported by any X11 WM that I know of).  It is also the way mwm works
: in explicit focus mode (which is the default specified in the Motif
: style guide).
: 
: > -- 
: >       Jason L. Tibbitts III - [email-masked] - 713/743-8684 - 221SR1

---

From: Tim Smithers <[email-masked]>
Date: Wed, 30 Oct 1996 10:27:47 +1100

> in explicit focus mode (which is the default specified in the Motif
Yep. I for one am an insane Windows user. At least half the time I do
not wish to use the window which has just popped up.

I do not wish to interact with my clock when I start it,
nor for instance my 'xload' windows. They are simply for the
display of information, *not* interaction.

Another reason, is the long delay in loading an application sometimes.
I have often started 'word', and then been asked to do something else.
I would start to do this & then the window for 'word' would finally 
appear, taking focus with it & whatever keys it was typing etc..
[ This is also dangerous if you accidently hit some buttons you shouldn't
have.]

	-mouse

P.S. I'm not sure that I for one particularly care for 'motif' style
guidelines. After all windows has click to front & click to focus,
and I wouldn't use their guidelines for quids.

-- 
Tim Smithers.
DMouse Pty. Ltd.
ph: 019 910 195
e-mail: [email-masked]

( Perfection is a hobby many pursue,
         but few have a chance of success )
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Jason L Tibbitts III <[email-masked]>
Date: 29 Oct 1996 23:13:03 -0600

>>>>> "SR" == Scott Raney <[email-masked]> writes:

[Quoting me]
>> place.  (I host this list.)

SR> I disagree with this: the focus policy that should be specified in the
SR> default .fvwm2rc file is an important issue that should be discussed on
SR> this list.

The discussion I'm seeing has little to do with the default value of
anything and has degenerated into you trying to tell other people what to
do.  I for one am tired of it, but that is my opinion.  I'm considering
killfiling the whole thing because it just isn't interesting to me any
more.

In any case I reiterate my _request_ that you keep the discussion strictly
relevant.  I believe that pointer focus is the default in most TWM
derivatives (it certainly is for the TWM and TVTWM most of my users use),
so you're probably better off complaining in a general group instead of
missing most of the audience.
-- 
      Jason L. Tibbitts III - [email-masked] - 713/743-8684 - 221SR1
System Manager:  University of Houston High Performance Computing Center
                1994 PC800 "Kuroneko"      DoD# 1723
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].