FVWM: wine / fvwm focus bunfight

[luke.leighton]

g'day all, i'm a long-time fvwm user (15 years so far), mostly because
it's lightning-quick to start up, doesn't get in my way and gives me
the ability to run 24 (6x4) virtual screens. hurrah.

i've started using ORCAD 16.3 under Wine (yes, amazingly it actually
works) and here's where the problems start: mouse focus when dialog
boxes are created. i've raised a bugreport on winehq and it was
instantly closed with the accusation "it's fvwm's fault!". well...
we'll leave that judgement aside - i've encountered issues where mfc42
c++ code was written incorrectly that quotes worked quotes on w95 but
the exact same program wouldn't work on nt 3.51

so the symptoms are: first dialog popup window has correct focus: the
bar at the top of the dialog box goes its lovely reddish colour. type
some data in, press ok, all is well. click another action (usually
but not always) right-mouse to edit properties, second (or sometimes
third or fourth) dialog box comes up: no focus.

move the mouse into the dialog box: no focus.

move the mouse around in the main window: no focus.

move the mouse onto the bar at the top of the main window: this is
where it gets strange. sometimes the dialog box will get focus,
sometimes the main window will get focus.

move the mouse outside of the main window and then back again: again
this doesn't work as expected - sometimes the dialog box will get
focus, sometimes the main window will.

the only way that i found which will *reliably* get focus into the
dialog box is to follow this procedure:

1) have an xterm hiding behind the main window whose drag bar is just
visible behind the main window
2) get the popup dialog created (by whatever action)
3) move the mouse onto the *xterm* top drag bar
4) move the mouse *slowly* down to ensure that the mouse is not moved
so fast such that it does not hit the main window's top drag bar (i.e.
move the mouse slowly enough to ensure that it hits the main window's
top drag bar)

at this point - after the mouse has been moved out into the xterm and
into the main window's top drag bar - the focus is correctly set to be
in the dialog box.

clearly, this is a complete pain. editing a schematic where an
operation should take 5 to 10 seconds maximum actually takes double to
triple that time (especially on a 1920x1200 screen, the mouse having
to be moved a considerable way with quite a lot of accuracy), this
procedure clearly and dramatically slowing down the speed at which
work can be carried out.

obviously, i'm not going to change the fvwm2 "focus" system which
requires clicking on the top bar in order to set mouse focus: that
would be a) too easy b) require working practices operational changes
regarding the use of every *other* program which would clearly be
massively inconvenient (i.e. i quite like mouse-move focus and am
happy with it).

this isn't restricted to ORCAD: it's other programs as well. it's
just that the use of ORCAD requires a significant number of popup
dialog boxes, so the bug in the interaction between wine and fvwm2
obviously shows up more frequently.

obviously the wine team claim that because this bug doesn't occur on
any other window manager that obviously it's not their problem, it
can't possibly be a bug in their code, therefore they're not going to
investigate. we'll deal with that flawed line of reasoning later.

thoughts as to how to proceed?

l.

[Dan Espen]

Post by luke.leighton
g'day all, i'm a long-time fvwm user (15 years so far), mostly because
it's lightning-quick to start up, doesn't get in my way and gives me
the ability to run 24 (6x4) virtual screens. hurrah.
i've started using ORCAD 16.3 under Wine (yes, amazingly it actually
works) and here's where the problems start: mouse focus when dialog
boxes are created. i've raised a bugreport on winehq and it was
instantly closed with the accusation "it's fvwm's fault!". well...
we'll leave that judgement aside - i've encountered issues where mfc42
c++ code was written incorrectly that quotes worked quotes on w95 but
the exact same program wouldn't work on nt 3.51
so the symptoms are: first dialog popup window has correct focus: the
bar at the top of the dialog box goes its lovely reddish colour. type
some data in, press ok, all is well. click another action (usually
but not always) right-mouse to edit properties, second (or sometimes
third or fourth) dialog box comes up: no focus.
move the mouse into the dialog box: no focus.
move the mouse around in the main window: no focus.
move the mouse onto the bar at the top of the main window: this is
where it gets strange. sometimes the dialog box will get focus,
sometimes the main window will get focus.
move the mouse outside of the main window and then back again: again
this doesn't work as expected - sometimes the dialog box will get
focus, sometimes the main window will.
the only way that i found which will *reliably* get focus into the
1) have an xterm hiding behind the main window whose drag bar is just
visible behind the main window
2) get the popup dialog created (by whatever action)
3) move the mouse onto the *xterm* top drag bar
4) move the mouse *slowly* down to ensure that the mouse is not moved
so fast such that it does not hit the main window's top drag bar (i.e.
move the mouse slowly enough to ensure that it hits the main window's
top drag bar)
at this point - after the mouse has been moved out into the xterm and
into the main window's top drag bar - the focus is correctly set to be
in the dialog box.
clearly, this is a complete pain. editing a schematic where an
operation should take 5 to 10 seconds maximum actually takes double to
triple that time (especially on a 1920x1200 screen, the mouse having
to be moved a considerable way with quite a lot of accuracy), this
procedure clearly and dramatically slowing down the speed at which
work can be carried out.
obviously, i'm not going to change the fvwm2 "focus" system which
requires clicking on the top bar in order to set mouse focus: that
would be a) too easy b) require working practices operational changes
regarding the use of every *other* program which would clearly be
massively inconvenient (i.e. i quite like mouse-move focus and am
happy with it).
this isn't restricted to ORCAD: it's other programs as well. it's
just that the use of ORCAD requires a significant number of popup
dialog boxes, so the bug in the interaction between wine and fvwm2
obviously shows up more frequently.
obviously the wine team claim that because this bug doesn't occur on
any other window manager that obviously it's not their problem, it
can't possibly be a bug in their code, therefore they're not going to
investigate. we'll deal with that flawed line of reasoning later.
thoughts as to how to proceed?

Anything more technical from the Wine folks than it's Fvwm's fault?

I vaguely recall some settings in Wine about how it interacts with
the WM. Are they still there, and have you tried different settings?

On the Fvwm side you might try:

Style * FPLenient

[luke.leighton]

Post by Dan Espen
Anything more technical from the Wine folks than it's Fvwm's fault?

nah. curt reply, bugreport closed.

Post by Dan Espen
I vaguely recall some settings in Wine about how it interacts with
the WM.

yes - i did some searches and there was something about wine not
respecting or providing the correct WM / style hints.

Post by Dan Espen
Are they still there, and have you tried different settings?
Style * FPLenient

.... and this was a recommended solution - i'll give it a shot and
report back, i'm travelling today.

l.

[luke.leighton]

Post by luke.leighton

Post by Dan Espen
Style * FPLenient

.... and this was a recommended solution - i'll give it a shot and
report back, i'm travelling today.

yep - works great. problem gone. so. bugreport for the wine team -
this time with information detailing precisely what they aren't doing
and need to do: any recommendations?

l.

[Dan Espen]

Post by luke.leighton

Post by luke.leighton

Post by Dan Espen
Style * FPLenient

.... and this was a recommended solution - i'll give it a shot and
report back, i'm travelling today.

yep - works great. problem gone. so. bugreport for the wine team -
this time with information detailing precisely what they aren't doing
and need to do: any recommendations?

If Lenience fixes the problem, the window is not indicating that
it accepts input.

Here's the section of the Fvwm man page:

The ICCCM states that windows possessing the property

WM_HINTS(WM_HINTS):
Client accepts input or input focus: False

should not be given the keyboard input focus by the window
manager. These windows can take the input focus by themselves,
however. A number of applications set this property, and yet expect the
window manager to give them the keyboard focus anyway, so fvwm provides
a window style, Lenience, which allows fvwm to overlook this ICCCM
rule. Even with this window style it is not guaranteed that the
application accepts focus.

[luke.leighton]

Post by Dan Espen
If Lenience fixes the problem, the window is not indicating that
it accepts input.
The ICCCM states that windows possessing the property
Client accepts input or input focus: False
should not be given the keyboard input focus by the window
manager.

all right, dan - thank you for this. i'm sorted (i can happily live
with editing .fvwm2rc) - i've reported the bug as it turns out that
there are a hell of a lot of other really weird long-standing bugs in
wine related to keyboard/mouse focus being lost, so they've clearly
been struggling to find this for a hell of a long time - lots of
people having difficulties with applications, so the advice you gave
is really helpful: let's hope the wine developers listen, eh?

l.

[luke.leighton]

it was too much to expect that they'd actually listen. so, perhaps
one for the FAQ? "known bug in wine, which the developers of wine
don't understand and do not wish to acknowledge, so you, the fvwm
user, are forced to put Style * Leniency in the .fvwm2rc config file".

l.

Post by luke.leighton

Post by Dan Espen
If Lenience fixes the problem, the window is not indicating that
it accepts input.
The ICCCM states that windows possessing the property
Client accepts input or input focus: False
should not be given the keyboard input focus by the window
manager.

all right, dan - thank you for this. i'm sorted (i can happily live
with editing .fvwm2rc) - i've reported the bug as it turns out that
there are a hell of a lot of other really weird long-standing bugs in
wine related to keyboard/mouse focus being lost, so they've clearly
been struggling to find this for a hell of a long time - lots of
people having difficulties with applications, so the advice you gave
is really helpful: let's hope the wine developers listen, eh?

Alexandre Julliard <***@winehq.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID

--- Comment #1 from Alexandre Julliard <***@winehq.org>
2013-01-02 05:54:18 CST ---
Setting the input hint to False is correct, along with WM_TAKE_FOCUS it
specifies that we use the Globally Active model. Whatever the bug may be,
that's not it.

[Dan Espen]

Post by luke.leighton
it was too much to expect that they'd actually listen. so, perhaps
one for the FAQ? "known bug in wine, which the developers of wine
don't understand and do not wish to acknowledge, so you, the fvwm
user, are forced to put Style * Leniency in the .fvwm2rc config file".

Updated FAQ, not sure when I'll look at the FAQ to PHP tool
(web page not updated yet).
Hopefully soon.

[Viktor Griph]

Post by luke.leighton
it was too much to expect that they'd actually listen. so, perhaps
one for the FAQ? "known bug in wine, which the developers of wine
don't understand and do not wish to acknowledge, so you, the fvwm
user, are forced to put Style * Leniency in the .fvwm2rc config file".
[...]
2013-01-02 05:54:18 CST ---
Setting the input hint to False is correct, along with WM_TAKE_FOCUS it
specifies that we use the Globally Active model. Whatever the bug may be,
that's not it.

Does fvwm send the WM_TAKE_FOCUS client message as described in
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7?

/Viktor