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 raney_at_metacard.com 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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Oct 21 1996 - 22:16:55 BST