Subject: Re: FVWM: Re: "active focus" applications (MetaCard)

From: Dan Espen <[email-masked]>
Date: Thu, 24 Oct 1996 09:55:56 -0400

At first I found this whole discussion pretty  annoying, but I have to
complement some of you for some  interesting discussion of this topic.
I hope I am contributing a new viewpoint on this...

We haven't heard from  Chuck, but my guess  is  there is no  way fvwm2
would change its default focus policy.  The "sample.fvwmrc" that comes
with   fvwm2,  already assumes  a default   focus policy  and supplies
overrides of clicktofocus for:

FvwmButtons,  xbiff, Maker,  Appointment,  xcalc, xman,  xvgr, matlab,
xmag, xgraph, sppeed6, and  xmosaic.

Any change to the default  would break every .fvwm2rc  file around.  I
would hope that we would worry more about the existing fvwm2 user base
than some new users.  I think  this viewpoint is more significant than
which policy is the better default.  I, for  one, would feel compelled
to change the   source code before  installation, if   this change was
actually made.

My guess  is   that a  POLITE  request from  the  metacard  people for
metacard  to  be    added to   the  the   clicktofocus   list in   the
"sample.fvwmrc", might be    granted.   Although the arguments    that
metacard should  attempt to  get  their application to   work smoothly
under any focus policy seem pretty compelling.

--
Dan Espen                                    Phone: (908) 699-5570
[email-masked]
444 Hoes Lane  Room RRC 1C-214
Piscataway, NJ 08854
--
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: "Charles Hines" <[email-masked]>
Date: Thu, 24 Oct 1996 11:09:12 -0400

>>>>> "Dan" == Dan Espen <[email-masked]> writes:

Dan> At first I found this whole discussion pretty annoying, but I
Dan> have to complement some of you for some interesting discussion of
Dan> this topic.  I hope I am contributing a new viewpoint on this...

Dan> We haven't heard from Chuck,

Yes, I've been deliberately silent on this as I try to stay out of
'religious' issues of any type.  But since someone noticed I guess I
have to say something now... :)

Dan> but my guess is there is no way fvwm2 would change its default
Dan> focus policy.

Good guess.  I don't plan to change the default, although for what
it's worth I actually use ClickToFocus as my focus policy so changing
the default wouldn't bother me in the least.

But I see no compelling arguement to change this default at this
point.  It has been in there since the dawn of fvwm (and into it's
ancestor twm as well, if I remember correctly).  If people don't like
it, they can change it individually.

Dan> The "sample.fvwmrc" that comes with fvwm2, already assumes a
Dan> default focus policy and supplies overrides of clicktofocus for:

Dan> FvwmButtons, xbiff, Maker, Appointment, xcalc, xman, xvgr,
Dan> matlab, xmag, xgraph, sppeed6, and xmosaic.

Dan> Any change to the default would break every .fvwm2rc file around.

Probably a safe bet.

Dan> I would hope that we would worry more about the existing fvwm2
Dan> user base than some new users.

I worry about both actually, but I definitely don't want to piss off
the current users unless I feel a real need to do so, and I don't
think I need to in this case.

Dan> I think this viewpoint is more significant than which policy is
Dan> the better default.  I, for one, would feel compelled to change
Dan> the source code before installation, if this change was actually
Dan> made.

Dan> My guess is that a POLITE request from the metacard people for
Dan> metacard to be added to the the clicktofocus list in the
Dan> "sample.fvwmrc", might be granted.

Certainly.  Just need to know the window classes/resources to use in
the style lines.  And it would be easy for MetaCard to provide this
info as well in the README that Scott said they already supply telling
how to put other window managers into ClickToFocus mode.

Dan> Although the arguments that metacard should attempt to get their
Dan> application to work smoothly under any focus policy seem pretty
Dan> compelling.

I have to agree.  As long as the choice of focus policies is present
(and it is present in pretty much all of the window managers out there
as far as I know)

But, on a related note and partly what Scott's original note dealt
with, I do need to verify that fvwm is handling the 4 input handling
policies correctly according to the ICCCM, which I'm not 100% certain
that it does.

Here is the relevant section from the current ICCCM (thankfully
available online at http://www-ihm.lri.fr/~tronche/gui/x/icccm/):

======================================================================
ICCCM> 4.1.7. Input Focus
ICCCM>
ICCCM> There are four models of input handling:
ICCCM>
ICCCM>        No Input - The client never expects keyboard input. An example
ICCCM>        would be xload or another output-only client.
ICCCM>
ICCCM>        Passive Input - The client expects keyboard input but never
ICCCM>        explicitly sets the input focus. An example would be a simple
ICCCM>        client with no subwindows, which will accept input in
ICCCM>        PointerRoot mode or when the window manager sets the input
ICCCM>        focus to its top-level window (in click-to-type mode).
ICCCM>
ICCCM>        Locally Active Input - The client expects keyboard input and
ICCCM>        explicitly sets the input focus, but it only does so when one
ICCCM>        of its windows already has the focus. An example would be a
ICCCM>        client with subwindows defining various data entry fields that
ICCCM>        uses Next and Prev keys to move the input focus between the
ICCCM>        fields. It does so when its top-level window has acquired the
ICCCM>        focus in PointerRoot mode or when the window manager sets the
ICCCM>        input focus to its top-level window (in click-to-type mode).
ICCCM>
ICCCM>        Globally Active Input - The client expects keyboard input and
ICCCM>        explicitly sets the input focus, even when it is in windows the
ICCCM>        client does not own. An example would be a client with a scroll
ICCCM>        bar that wants to allow users to scroll the window without
ICCCM>        disturbing the input focus even if it is in some other
ICCCM>        window. It wants to acquire the input focus when the user
ICCCM>        clicks in the scrolled region but not when the user clicks in
ICCCM>        the scroll bar itself. Thus, it wants to prevent the window
ICCCM>        manager from setting the input focus to any of its windows.
ICCCM>
ICCCM> The four input models and the corresponding values of the input field
ICCCM> and the presence or absence of the WM_TAKE_FOCUS atom in the
ICCCM> WM_PROTOCOLS property are listed in the following table:
ICCCM>
ICCCM>  Input Model     Input Field   WM_TAKE_FOCUS
ICCCM>
ICCCM>  No Input        False         Absent
ICCCM>  Passive         True          Absent
ICCCM>  Locally Active  True          Present
ICCCM>  Globally Active False         Present
ICCCM>
ICCCM>
ICCCM> Passive and Locally Active clients set the input field of WM_HINTS to
ICCCM> True , which indicates that they require window manager assistance in
ICCCM> acquiring the input focus. No Input and Globally Active clients set
ICCCM> the input field to False , which requests that the window manager not
ICCCM> set the input focus to their top-level window.
ICCCM>
ICCCM> Clients that use a SetInputFocus request must set the time field to
ICCCM> the timestamp of the event that caused them to make the attempt. This
ICCCM> cannot be a FocusIn event because they do not have timestamps. Clients
ICCCM> may also acquire the focus without a corresponding EnterNotify . Note
ICCCM> that clients must not use CurrentTime in the time field.
ICCCM>
ICCCM> Clients using the Globally Active model can only use a SetInputFocus
ICCCM> request to acquire the input focus when they do not already have it on
ICCCM> receipt of one of the following events:
ICCCM>
ICCCM>        ButtonPress
ICCCM>        ButtonRelease
ICCCM>        Passive-grabbed KeyPress
ICCCM>        Passive-grabbed KeyRelease
ICCCM>
ICCCM> In general, clients should avoid using passive-grabbed key events for
ICCCM> this purpose, except when they are unavoidable (as, for example, a
ICCCM> selection tool that establishes a passive grab on the keys that cut,
ICCCM> copy, or paste).
ICCCM>
ICCCM> The method by which the user commands the window manager to set the
ICCCM> focus to a window is up to the window manager. For example, clients
ICCCM> cannot determine whether they will see the click that transfers the
ICCCM> focus.
ICCCM>
ICCCM> Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property may
ICCCM> receive a ClientMessage event from the window manager (as described in
ICCCM> section 4.2.8) with WM_TAKE_FOCUS in its data[0] field and a valid
ICCCM> timestamp (i.e. not CurrentTime ) in its data[1] field. If they want
ICCCM> the focus, they should respond with a SetInputFocus request with its
ICCCM> window field set to the window of theirs that last had the input focus
ICCCM> or to their default input window, and the time field set to the
ICCCM> timestamp in the message. For further information, see section 4.2.7.
ICCCM>
ICCCM> A client could receive WM_TAKE_FOCUS when opening from an icon or when
ICCCM> the user has clicked outside the top-level window in an area that
ICCCM> indicates to the window manager that it should assign the focus (for
ICCCM> example, clicking in the headline bar can be used to assign the
ICCCM> focus).
ICCCM>
ICCCM> The goal is to support window managers that want to assign the input
ICCCM> focus to a top-level window in such a way that the top-level window
ICCCM> either can assign it to one of its subwindows or can decline the offer
ICCCM> of the focus. For example, a clock or a text editor with no currently
ICCCM> open frames might not want to take focus even though the window
ICCCM> manager generally believes that clients should take the input focus
ICCCM> after being deiconified or raised.
ICCCM>
ICCCM> Clients that set the input focus need to decide a value for the
ICCCM> revert-to field of the SetInputFocus request.  This determines the
ICCCM> behavior of the input focus if the window the focus has been set to
ICCCM> becomes not viewable. The value can be any of the following:
ICCCM>
ICCCM>        Parent - In general, clients should use this value when
ICCCM>        assigning focus to one of their subwindows. Unmapping the
ICCCM>        subwindow will cause focus to revert to the parent, which is
ICCCM>        probably what you want.
ICCCM>
ICCCM>        PointerRoot - Using this value with a click-to-type focus
ICCCM>        management policy leads to race conditions because the window
ICCCM>        becoming unviewable may coincide with the window manager
ICCCM>        deciding to move the focus elsewhere.
ICCCM>
ICCCM>        None - Using this value causes problems if the window manager
ICCCM>        reparents the window, as most window managers will, and then
ICCCM>        crashes. The input focus will be None , and there will probably
ICCCM>        be no way to change it.
ICCCM>
ICCCM> Note that neither PointerRoot nor None is really safe to use.
ICCCM>
ICCCM>                               Convention
ICCCM>
ICCCM>        Clients that invoke a SetInputFocus request should set the
ICCCM>        revert-to argument to Parent.
ICCCM>
ICCCM> A convention is also required for clients that want to give up the
ICCCM> input focus. There is no safe value set for them to set the input
ICCCM> focus to; therefore, they should ignore input material.
ICCCM>
ICCCM>                               Convention
ICCCM>
ICCCM>        Clients should not give up the input focus of their own
ICCCM>        volition. They should ignore input that they receive instead.
======================================================================

And the corresponding section on how clients should react to these:

======================================================================
ICCCM> 4.2.7. Input Focus
ICCCM>
ICCCM> Clients can request notification that they have the input focus by
ICCCM> selecting for FocusChange events on their top-level windows; they will
ICCCM> receive FocusIn and FocusOut events. Clients that need to set the
ICCCM> input focus to one of their subwindows should not do so unless they
ICCCM> have set WM_TAKE_FOCUS in their WM_PROTOCOLS property and have done
ICCCM> one of the following:
ICCCM>
ICCCM>        Set the input field of WM_HINTS to True and actually have the
ICCCM>        input focus in one of their top-level windows
ICCCM>
ICCCM>        Set the input field of WM_HINTS to False and have received a
ICCCM>        suitable event as described in section 4.1.7
ICCCM>
ICCCM>        Have received a WM_TAKE_FOCUS message as described in section
ICCCM>        4.1.7
ICCCM>
ICCCM> Clients should not warp the pointer in an attempt to transfer the
ICCCM> focus; they should set the focus and leave the pointer alone. For
ICCCM> further information, see section 6.2.
ICCCM>
ICCCM> Once a client satisfies these conditions, it may transfer the focus to
ICCCM> another of its windows by using the SetInputFocus request, which is
ICCCM> defined as follows:
ICCCM>
ICCCM>                SetInputFocus
ICCCM>      focus : WINDOW or PointerRoot or None
ICCCM>  revert-to : { Parent , PointerRoot , None }
ICCCM>       time : TIMESTAMP or CurrentTime
ICCCM>
ICCCM>
ICCCM>                              Conventions
ICCCM>
ICCCM>     1. Clients that use a SetInputFocus request must set the time
ICCCM>        argument to the timestamp of the event that caused them to make
ICCCM>        the attempt. This cannot be a FocusIn event because they do not
ICCCM>        have timestamps. Clients may also acquire the focus without a
ICCCM>        corresponding EnterNotify event.  Clients must not use
ICCCM>        CurrentTime for the time argument.
ICCCM>     2. Clients that use a SetInputFocus request to set the focus to
ICCCM>        one of their windows must set the revert-to field to Parent.
======================================================================

So, if anyone out there has observed any violations of these
conventions that seem to need to be fixed in fvwm, please let me know
the details.

I'm also planning to add focus policy to the info outputted by
FvwmIdent for the next beta, but you can use xprop to figure out what
focus policy a window should have in the meantime.

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
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: "Charles Hines" <[email-masked]>
Date: Thu, 24 Oct 1996 17:16:04 -0400

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

>> it, they can change it individually.

SR> But only if they spend a lot of time wading around in config files
SR> (which new users especially are loath to do).

I'd say that depends on the person, but is probably generally true for
people who tend to be non "power users" of their tools.  But what is
the biggest response to newbie questions?  RTFM.  They may be loath to
do it, but must learn sometime...

SR> I recommend adding a button in the default root menu to change the
SR> focus model

I think this is a good idea.  It shouldn't be too bad to create a
simple menu to configure some simple things like that.  I'll see about
putting one in the next beta.

SR> (CDE and HP's Vue both come with preferences dialogs that allow
SR> you do make this change without reading a manual).

Just as a side note, FvwmConfig (in the extras dir) and The Dotfile
Generator can both be used to configure aspects of fvwm in an
interactive way, although I have to admit that I haven't really even
looked at either. :)  The latter supports fvwm 1.xx as well.

SR> Sounds like apps that work best with explicit focus are actually very
SR> common.  This is evidence that explicit should be the default, and
SR> xterm should have a pointer focus override...

Actually, I believe that the reason Rob put (most of) those in there
is because he never really wanted the focus to go to those while he
was moving the cursor about, particularily with sloppy focus, which I
believe he used.  I think that was also the motivator behind per
window focus policies to begin with.

>> Probably a safe bet.

SR> Maybe for fvwm 3 ;-)

Perhaps, but isn't that thinking a bit far ahead since I haven't even
managed to get an official version of 2.xx out? ;^)

>> how to put other window managers into ClickToFocus mode.

SR> The window class name is "MetaCard", but when I tried using the
SR> override it doesn't seem to make things much better.

Hm.  Well, I'll put that in the list anyways.  Do all of your
subwindows have that same class name as well?

>> policies correctly according to the ICCCM, which I'm not 100% certain

SR> It doesn't, and when using the default configuration ("sloppy
SR> focus"?)  MetaCard is basically unusable with fvwm2.  Changing the
SR> default to clickToFocus improves things somewhat, but there are
SR> still serious problems.

Well, according to what you said your app is Globally Active, which is
the one input policy that I was really thinking might not be being
handled correctly.  But I would not have imagined that it could make
any application unusable...

SR> The latest release of fvwm2 actually seems worse in general than
SR> 1.X was.

I assume you mean with respect to MetaCard.  If not, I'd like to know
what you feel the other problems are with it.

>> conventions that seem to need to be fixed in fvwm, please let me know

SR> I would be happy to help you work through these, and the problem about
SR> the missing configure notify message when an app raises its menu bar
SR> window.  Here is my original report agains 1.24r, and all of these
SR> problems also exist in 2.0.43:

I do have your original note, but didn't get a chance to reply before
my mailbox got flooded and finding the time to reply to long notes is
difficult sometimes...  I guess I'll reply now.

....
SR> 1) In the explict/click-to-type focus model, clicking in a window
SR> incorrectly automatically moves the keyboard focus to that window.
SR> The focus should remain in the source window until the application
SR> specifically requests it with XSetInputFocus.

Actually, this is true only for Locally & Globally Active windows
(those that have WM_TAKE_FOCUS defined) such as your application.
This is basically the situation that I thought fvwm might not be
handling correctly, although I haven't really investigated it yet.

I'll look the code over before the next beta and see if I can find any
holes.

....
SR> 2) In the pointer focus model, moving the mouse to a window doesn't
SR> always focus that window.  Reproduce by opening the MetaCard
SR> Message Box and moving the mouse back and forth between it an the
SR> Home stack.  Sometimes MetaCard thinks it has the focus (the
SR> cursor flashes in the Message Box) even when it doesn't,
SR> indicating either a missing FocusOut event, or the WM dropping (or
SR> getting confused by) MetaCard's XSetInputFocus call.

This seems a bit odd.  I guess I may actually have to download
MetaCard to check this out, which I was hoping to avoid.

SR> 3) Calling XRaiseWindow does not cause a configureNotify event to be
SR> sent to the application like it does with mwm.

Hm.  Are you sure this is supposed to happen?  I just used xev to
watch the events being sent to a window that I was manually raising
and lowering, and under both fvwm and mwm NEITHER actually showed a
ConfigureNotify event happening (basically just visibiltynotify
events).  Now, I was doing this under xmx, perhaps if I run them
normally...nope - same behavior that way.  I did see ConfigureNotify
events if I moved them though, but not when I raised them.

SR> PS: I had some trouble getting fvwm2 set up and working, due
SR> primarily to the fact that the installation program doesn't
SR> install a system.fvwm2rc file, the fact that you changed the name
SR> of the file yet supply only samples without the "2" in them,

Whoops - forgot to make that symbolic link, like I did with the man
page.  That'll be corrected for the next beta.

SR> the fact that the sample "system.fvwmrc" has "restart" wrong for
SR> fvwm2,

Another thing that slipped by - also will be corrected for the next
beta.  A side note, I'd like to enhance (clean up) Restart so if there
are no parms (or if it's say just a '-') that it will restart using
argv[0], so you don't need to know if it was named fvwm or fvwm2.
I'll try and get this into the next beta as well.

SR> and the fact that both the samples start up a bunch of things that
SR> don't work on the system I installed it on (a Linux 1.2.13 system
SR> (Caldera's)).

That I'd believe.  But they are samples after all and should probably
be customized before being installed at the end site.  Perhaps I
should make a "bare bones" version as well and make that the default,
and spell out what I just said explicitly in the INSTALL file.

Damn, this took way too long to type.  Gotta run!

Chuck

---

From: George Michaelson <[email-masked]>
Date: Fri, 25 Oct 1996 08:37:56 +1000

I have meta+<key> overrides in my .fvwmrc to do screen-shift stuff. I guess
thats pretty common. 

However I am continually freaked by netscapes insistance on grabbing focus
when I do a "save to disk" form of URL download. That, and the non-grabbing
of focus into input fields on transitional popups. The screen shift META
stuff doesn't work until the mouse is re-shifted off the download info window.

This thing exposes how subjective focus is. Some windows which have little
or no feedback (eg ones with only a cancel button) should not grab focus.

Others, which you explicitly requested with intent of filling in fields should.

Is this an app bug, a runtime wm config bug, or an unrealistic expectation?

-George

---

From: Scott Raney <[email-masked]>
Date: Thu, 24 Oct 1996 17:00:34 -0600 (MDT)

> or no feedback (eg ones with only a cancel button) should not grab focus.

I disagree.  The most efficient way to deal with these is to press the
return key to dismiss the dialog.  If they don't get the focus, you
can't do this.

> Is this an app bug, a runtime wm config bug, or an unrealistic expectation?

I'd say the latter, if you're expecting some magical way to get around
the limitations of pointer focus when using applications where your
actions can cause dialog boxes to open.
  Regards,
    Scott

PS: I've just discovered another interesting problem with fvwm that is
just more evidence that most people using it are not using real GUI
applications very much: it doesn't even enforce modal dialog behavior!
Both mwm and olwm have properties that an application sets to indicate
that a window is a modal dialog (e.g., an error message) and the user
must respond to that dialog before continuing to work with the main
window.  MetaCard sets both sets of properties, and fvwm is apparently
not honoring either of them...

-- 
***************************************************************
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: George Michaelson <[email-masked]>
Date: Fri, 25 Oct 1996 09:00:53 +1000

I don't think you want to do that on a popup with only one choice of input
(== cancel) if the input is auto-selected true. If its not auto-selected true
then because its grabbed focus and fvwm isn't snarfing the META sequences 
you need a mouse-shift to do normal desktop stuff.

(most downloads last a long time. You really don't want to interact with them
at all)

Yea, I kinda knew that.

cheers
	-George

---

From: John Gotts <[email-masked]>
Date: Thu, 24 Oct 1996 21:13:27 -0400

>not honoring either of them...

Robert Nation made this a compile-time option in fvwm 1.x.  I believe the
preprocessor macro he chose was -DMODALITY_IS_EVIL.

Modality is a feature that can almost always be avoided by better programming.
See 6A (O'Reilly's _Motif Programming Manual_), any other decent Motif
programing book, the Motif newsgroups, and the Motif FAQ for more information.

Here's an excerpt from _The Motif Style Guide_, written by the Open Software
Foundation:

             Modal secondary windows prevent the user from
             continuing to work in the existing window from which
             the secondary window was opened.  Only use modal
             windows in rare situations where there are extreme
                                                        ^^^^^^^
             conditions that prevent the user from working in the
             ^^^^^^^^^^
             existing window.  Even though users cannot interact
             with elements within the existing window, they should
             still be able to interact with the existing window
             itself.  As an alternative to providing modal secondary
             windows, use a modeless secondary window and make some
             of the choices in the primary window unavailable.  For
             more information, see Provide Modes when Appropriate.

When I started out with Motif, I thought modality was the best thing since
sliced bread, because I could be lazy.  After more experience, however, I
learned my lesson.  Modality sucks.  You should never force the user to only be
able to use one window.  If you'd like some concrete examples, I have many (as
I was a full-time Motif programmer over the summer).

Don't tell me I'm not using real GUI applications much; don't even tell me I'm
not a GUI programmer.  Are you looking to be flamed accusing people on a window
manager mailing list of not using "real" GUI applications?  Your words reveal
to me at least that you don't even know what "real" GUI applications are.

--
John GOTTS <[email-masked]> http://www-personal.engin.umich.edu/~jgotts
Senior, EE/Motif Programmer/SysAdmin/Linux Hacker/Amateur Radio Callsign N8QDW
--
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: Thu, 24 Oct 1996 20:45:13 -0600 (MDT)

> preprocessor macro he chose was -DMODALITY_IS_EVIL.

Correct, but this is not enabled in the default build, and yet fvwm
still doesn't honor the Motif-standard properties.

> Modality is a feature that can almost always be avoided by better programming.

And *almost* is the crucial word here.  Some conditions just have to
be dealt with this way.  Unless you can honestly say that it's *never*
required, then fvwm is broken.

> Here's an excerpt from _The Motif Style Guide_, written by the Open Software

(snip)

And here's a quote from IBM's CUA guide (which is what the Motif and
MS-Windows style guides are based on), page 9:

  Some types of modes are recommended by the user interface.  They are:
  Modal Dialogs

  Sometimes needs information to continue, such as the name of a file
  into which the users want to save something.  When an error occurs,
  users may be required to perform an action before they continue their
  task. 

And while we're on the subject, the Motif style guide specifically
states the explicit focus is the default (Section 2.1).  Apparently
what it says is good enough for your argument, but not good enough for
those who insist the fvwm default be different than the mwm and olwm
defaults.

> I was a full-time Motif programmer over the summer).

I agree that modality should be avoided whenever possible.  But this
is not a good reason for having fvwm not honor the request.  After
all, presumably the application developer knows what he or she is
doing, and it's not fvwm's place to prevent them from doing it.  The
result may be loss of data and very unhappy campers.

> to me at least that you don't even know what "real" GUI applications are.

If you'll take a look at some "real" GUI applications, such as
Netscape, most of the CDE tools, and MetaCard, you'll see that they do
use modal dialogs.  My hunch is that you can cause program crashes and
possibly even data loss with most of these if you intentionally poke
in the main window with fvwm not honoring the applications modality
requirements.  Maybe you'll be lucky enough to never have to create a
modal dialog, but I daresay your reputation as a GUI programmer
wouldn't be done any great good if some application you released
crashed or caused data loss because the window manager didn't work
like it was supposed to.

As a commercial product vendor we have to deal with all levels of
users, and fvwm's lack of support for modality is going to cause them
(and us) problems.
  Regards,
    Scott

---

From: Markus Gutschke <[email-masked]>
Date: 25 Oct 1996 17:52:58 +0200

> not honoring either of them...

If I remember correctly, then FVWM allows you to enable/disable
(system) modal dialogs. This is a very good thing! I just hate modal
dialogs! I cannot image any situation where they would really be
required. This is especially true for system modal dialogs. In most
cases, when applications sport modal dialogs, these have seriously
been getting in my way and they definitly decreased productivity.

In my opinion, modal dialogs show that the application programmer
mis-designed the application and that he does not understand how to
program event-driven GUI interfaces. These are relicts from the past
that should have been removed long ago.

Markus

---

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

> been getting in my way and they definitly decreased productivity.

All I can find in the 2.0.43 source regarding this is the
"MODALITY_IS_EVIL" #define which just changes the properties a Motif
window (I'm not sure why, perhaps it is just to tell the Motif window
that modal enforcement is not supported).

> that should have been removed long ago.

While I'd agree with you that they should be used sparingly, you'll
have even less luck convincing UI designers that they're obsolete than
I've had convincing pointer-focus afficianados that *that's* obsolete
;-) The fact that nearly all apps on MS-Windows and the Mac use modal
dialogs is pretty clear evidence that you're way out on the fringe on
this one.

And from [email-masked] (Alan Wild):

> Scott Raney wrote:
> Hmmm. . well, I'll admit that I am ignorant compared to many of the
> people who frequent this list when it comes X protocol.  However, by
> your own assertion, Netscape uses modal dialogs.  Now, given my
> ignorance, I am not sure that I have experienced a modal dialog, but
> Would not the Popup that is activated when I selected Options->"General
> Preferences" from the pull-downs be a modal dialog?
> 
> If it is, then fvwm handles this correctly, because I have used fvwm
> 1.24 and fvwm2 for about a year and a half and it has ALWAYS behaved the
> same; When this dialog is active, I cannot interact whatsoever with the
> main window.

Well Netscape does seem to *partially* do the right thing.  Apparently
they added some internal event-dispatching protection to handle the
case where the window manager doesn't properly handle the modal
request.  Still, it's not totally the right thing because the main
window still gets the focus (the window border changes and the
insertion cursor resumes flashing) and no feedback (beep) is given to
the user to indicate that they can't use the main window when they try
to.

> Again, My knowledge is limited, but from my minimal understanding, I
> have not experienced any problems.  In fact, I use fvwm2 on Linux, AIX,
> OSF/1 and HP-UX boxes and I have NEVER had the sorts of problems that
> you report.
> 
> Personally, I think that fvwm2 is one of the greatest programs ever
> developed.  Sure, the source is a bit sloppy and there are bugs, but
> fvwm lets me create attractive, functional desktop across any UN*X box
> I've used and always maintained an efficient level of memory usage.
> Fvwm works the way I like it to, and has outperformed almost every other
> window managers I've demo-ed.
> 
> But enough preaching. . . back to the point at hand.  Is the dialog box
> I mentioned a modal dialog, and if so, what behavior do you observe that
> is different from what I get?

The problem is that apparently there is no support whatsoever for
modal dialogs in fvwm (that I can find, anyway).  The key issue as far
as Motif applications is concerned is that fvwm is not looking at the
"input_mode" member structure stored in the _MOTIF_WM_HINTS atom.
According to the standard include file MwmUtil.h, the _MOTIF_WM_HINTS
atom is a structure with five elements:
    long	flags;
    long	functions;
    long	decorations;
    int		input_mode;
    long	status

In decorations.c, fvwm looks at the "decorations" member, but the
input_mode member isn't used anywhere I can find.  The values of that
member are one of:

/* values for MwmHints.input_mode */
#define MWM_INPUT_MODELESS          0
#define MWM_INPUT_PRIMARY_APPLICATION_MODAL 1
#define MWM_INPUT_SYSTEM_MODAL          2
#define MWM_INPUT_FULL_APPLICATION_MODAL    3

If there is support for modal dialogs in fvwm someplace I missed, it
shouldn't be hard to add support for the Motif-standard way of
specifying it.  If there really is no support, things get a little
more complicated, since all places where the focus is assigned to a
window will have to be modified (mwm doesn't allow the focus to go to
a window at all if a modal transient-for window is open, preventing
the user from getting confused by a window getting the focus and yet
not responding to key or mouse presses).  Furthermore, all mouse
buttons need to be grabbed when the mouse is in the window pointed to
by the transient-for prop (mwm beeps when you try to use that window).

> - -Alan
> 
> As a side-note:  FVWM is not just popular among it's developers and
> Linux users.  According to the X11 window manager homepage it is one THE
> most popular window manager across UNIX platforms.  If you notice,
> according to this page fvwm, fvwm95, and afterstep (all direct
> descendants of fvwm1.24r) are way more popular among voters than mwm and
> ol(v)wm.

There is obviously a *serious* survey bias problem here: I've never
even heard of "afterstep", yet it is the most popular wm on that
list.  The "real world" usage pattern is probably more like 95% mwm
and olwm.  We've only recently started getting bug reports about these
MetaCard/fvwm compatibility problems, despite MetaCard having been
available since 1992.

> You can review the numbers yourself at:
> 
> http://www.emptysky.com/xwinman/
> 
> And although the voting was recently reset, the present results are
> pretty consistent with the results of the list year and a half or so.

I think fvwm is a fine tool, and believe that all the popularity it is
acquiring is a Good Thing.  But its growing presence makes it even
more important that it properly support modal dialogs without
requiring apps (or toolkits) to do keyboard or pointer grabs.

There is one more point I should make: this is not just for us as an
application vendor: MetaCard is a GUI *development* tool, which means
that our *customers* are the ones deciding whether or not they need
modal dialogs, not us.  Unless you want to tell all of *them* and all
of *their* customers that it's OK that fvwm does not support modal
dialogs, then we should start figuring out how to implement this
functionality.  While we're willing and able to help fix the "active
focus" problems, I'm afraid that adding support for modal dialogs is
something that's going to require the attention of somebody that knows
fvwm internals very well.
  Regards,
    Scott

> - -- 
> Alan Wild <[email-masked]>           /T\ f/s/c lou95
> IT-HSC Consultant       Speed School Student Council        Speed News Guy
> http://www.spd.louisville.edu/~arwild01 or ==> ~triangle/ ~spdnews/ ~sssc/

---

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

> to change the   source code before  installation, if   this change was

I think you misunderstand my proposal. There is no need to change the
fvwm source code, just include a sample system.fvwm2rc file with the
following line (uncommented) in it:
Style "*" ClickToFocus

The fact that fvwm2 doesn't even install a system.fvwm2rc file seems
to me to be a significant problem, since the tool is nearly useless
without one (the fact that there isn't even a sample fvwm2rc
configuration file in the distribution is completely baffling to me).
My proposal is just that the fvwm2 "make install" should install a
sample system.fvwm2rc file, and that file should have ClickToFocus
enabled by default.  If you wanted to make the install process a
little smarter, you could even prevent it from overwriting any
system.fvwm2rc file you may have already installed.
  Regards,
    Scott

---

From: Markus Gutschke <[email-masked]>
Date: 26 Oct 1996 23:57:24 +0100

> that modal enforcement is not supported).

Yepp, this was the option that I had been thinking of. I cannot tell,
what difference it makes, because I enabled it ever since I compiled
my first copy of fvwm.

> dialogs is pretty clear evidence that you're way out on the fringe on

<FLAME MODE>
You see, that is one of the many reasons why I do not use these
environments ;-) I might be able to accept that some people actually
like modal dialogs, but I can see no reason whatsoever why this could
not be made an option. The only exception is, that you accept the
lazyness of the programmer being a valid excuse.
</FLAME MODE>

Although I feel very strong about this topic, it is not intended as
flame-bait. You said, that MetaCard is a developer's tool, thus you
might have some influence on setting policies. I would like to suggest
that your policies consider the needs of all potential
customers/users. Therefore, the ability to configure all "religously"
discussed features of the GUI should be the first and foremost design
criterion! (these topics include: pointer mode, modality, keyboard-
vs. mouse-driven, amount of colors, keyboard layout, ...) Leave the
final decision to the end-user, but provide default settings that you
consider sensible and that are commonly accepted in your target
market.

So far, the only seemingly good argument for modal dialogs appears to
be that they require your immediate attention if there has been a
serious error. The reasoning is, that you could not do anything else
anyways, before answering this dialog, so you might just as well be
forced to answer it. I do not believe this to be true:

Imagine a texteditor; when closing the window the text is supposed to
be autosaved, but a hard-error occurs and the system is unable to
write the file. Writing to a backup file fails just as well, so the
application needs your help and pops up a modal dialog asking you what
to do now. The options are 1) save under another name, 2) forget about
the whole thing and discard the data, 3) mail the file to you so that
you can recover it from your mailbox, 4) return to the main
application; unfortunately, many application programmers forget the
latter, because it complicates the program design.

As a user, I might be able to think of a couple of other options: 1) I
might want to select the entire text and after copying to the
clipboard, paste the contents to a different application, 2) I might
want to use "xv" to get a snapshot of the current window, if only it
was not obstructed by the modal dialog, 3) I want to select print-file
instead, so that I get a hardcopy of my work, 4) I know why this error
occured and I want to select another entry from the main window in
order to fix it, 5) I have to double check a couple of other options
in the main application before I can really decide on which button to
press.

Pro-modality people usually suggest that you could just as well close
the warning dialog and then (hopefully) return to where you left
off. Only 1) this does not work in all situations, 2) it is
counter-intuitive to the way that I work, 3) it might have taken
considerable effort to finally get to this stage where the box popped
up; closing it now would require me to re-do all this work after I
fixed the original error.

Markus