Problems with focus losing on virtual desktops

[Christian Authmann]

Jesse Allen schrieb:

> I don't have much to comment on this one other than if you can prove
> that this is not a behavior in windows, then you should probably open
> a bug report.

I don't even know if it's a wine bug, it might as well be d2, the window
manager or a windows design issue.
It works fine when explorer.exe is present in wine (i.e. virtual desktop
mode) but fails when it's not. I never checked what happens to d2 in
windows when explorer.exe isn't there. And I don't feel like wasting a
day to get a working windows installation which allows me to kill explorer.
It's really not an issue, virtual desktop mode is superior to diablo's
window mode anyway: diablo defaults to slow and ugly direct2d rendering
when started with -w.

Hence no bug report.


>> b) Using d2 in fullscreen mode inside wine's virtual desktop: d2 will
>> sometimes think it lost focus, even if it didn't.
>> Moving the wine window around with hotkey+drag: d2 minimizes.
>> Moving the window by the title bar: nothing happens. (using kde/kwin btw)
>> Sometimes just clicking inside the window while playing will cause d2 to
>> minimize, although I haven't found a reproducible pattern (i.e. do I
>> have to press certain keys, do I have to double-click, etc).
>>
>> Activating a different window outside the virtual desktop? d2 stays
>> open. Or opening another application via hotkey, or pulling down yakuake
>> via hotkey. It stays open.
>> But, if I reactivate the virtual desktop window afterwards: d2
>> minimizes. Ouch.
> 
> This problem sounds like is caused by the design of the game. We can't fix this.

How is this the game's fault?
Of course, minimizing on losing focus is the game's fault/feature, but
thinking that the focus has been lost when it clearly hasn't (or the
other way round) is a bug. Something has to tell the game "you lost
focus". These problems didn't happen in older wine versions (even 0.9.2x
where focus losing was possible) and don't happen on windows.

I've just tested with a different application inside a virtual desktop,
watching the window title to see if it's active or not. In short: This
broken focus behaviour on virtual desktops isn't limited to d2.


Moving the virtual desktop window with Hotkey+drag: lost focus.
I've noticed that kwin seems to contribute to this. Hotkey-dragging a
xev-window leads to these entries (keypress-events removed):

-- snip --
FocusOut event, serial 31, synthetic NO, window 0x3000001,
    mode NotifyGrab, detail NotifyAncestor

ConfigureNotify event, serial 32, synthetic YES, window 0x3000001,
    event 0x3000001, window 0x3000001, (1605,56), width 178, height 178,
    border_width 0, above 0x0, override NO

[more of those while moving. Then, when letting go:]

FocusIn event, serial 32, synthetic NO, window 0x3000001,
    mode NotifyUngrab, detail NotifyAncestor
-- snap --

However, this should mean that the window inside the virtual desktop
regains focus after the drag is complete, right? It doesn't.


Opening (and activating) a different window: the windows program thinks
it's still focused. Reactivating the virtual desktop window: the windows
program loses focus.

here's an xev dump of what xev receives when opening another window via
hotkey while xev is active (the Super_L-Key is obviously part of my
hotkey-combination).

-- snip --
KeyPress event, serial 31, synthetic NO, window 0x3000001,
    root 0x1a5, subw 0x0, time 2684778, (738,830), root:(2343,873),
    state 0x10, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

FocusOut event, serial 31, synthetic NO, window 0x3000001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 31, synthetic NO, window 0x3000001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 31, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   64  0   0   0   0   0   0   0   8   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

FocusOut event, serial 31, synthetic NO, window 0x3000001,
    mode NotifyNormal, detail NotifyNonlinear
-- snap --

now the additional FocusOut/FocusIn seems weird and may well be a kwin
bug that leads to this issues. Again, wine handles this good on regular
windows, but bad inside a virtual desktop.

After closing the opened app so that the virtual desktop (or xev in this
case) receives focus again, it'll get a simple FocusIn event, which
activates the virtual desktop window, but deactivates the application
window inside.


> This ALT key problem seems like the window manager is still
> intercepting the ALT key somehow (even though certain keystrokes are
> disabled). I'll test for this and tell you whether that's my
> conclusion.

thank you.
I've tried testing with a couple of different window managers, but they
all had Alt+click bound to window moving, so I couldn't test.
Maybe it is KWin-specific (or specific to my configuration), but it'll
still only happen inside virtual desktops, never on native linux windows
or d2 outside a virtual desktop.

Is there something like xev for windows I could use for further testing?


greetings,
Tub