>>>>> "Dan" == Dan Espen <dane_at_bae.bellcore.com> 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 <chuck_hines_at_vnet.ibm.com>
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu Oct 24 1996 - 10:10:00 BST