On 8/14/07, Christian Authmann spam@authmann.de wrote:
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.
Oh that's right. That's another reason why the window option from the game is pretty much a "hack"; it only allows ddraw mode.
b) Using d2 in fullscreen mode inside wine's virtual desktop: d2 will
...
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.
Windows doesn't have virtual desktop.
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.
Which application is this?
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 --
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 seems correct behavior to me, if the wine windows are confined to the virtual desktop. But someone else can comment.
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?
Like I said, windows doesn't have "virtual desktop"
Jesse