http://bugs.winehq.org/show_bug.cgi?id=9320
Summary: Wine Virtual Desktop lacks proper focus handling Product: Wine Version: CVS Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P4 Component: wine-user AssignedTo: wine-bugs@winehq.org ReportedBy: vitaliy@kievinfo.com
This is a general bug about deficiencies in Wine virtual desktop window manager that does not handle focus changes properly.
With Wine now properly reacting to focus looses away from Wine windows, some applications have some difficulties not previously seen.
This DOES NOT include any behavior that is identical to one on windows. For example most games will pause/freeze/minimize whenever they loose focus - user, using [alt]+[tab] to switch away to other application.
http://bugs.winehq.org/show_bug.cgi?id=9320
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9300
http://bugs.winehq.org/show_bug.cgi?id=9320
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9257
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #1 from Jan Zerebecki jan.wine@zerebecki.de 2007-08-15 23:00:12 --- It would be nice if the focus inside of the virtual desktop (at least optionally) would be preserved (i.e. moving the focus from the v. d. to another x window would not take focus from some full screen application that runs inside the v. d.). Is that inside the scope of this bug report?
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2007-08-16 22:45:35 --- I don't see why not. This is generic enough bug. And whoever implements this, might as well start from that.
http://bugs.winehq.org/show_bug.cgi?id=9320
tehblunderbuss@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tehblunderbuss@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=9320
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=9320
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.2.0
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #3 from Vincent Povirk madewokherd@gmail.com 2008-08-17 13:43:41 --- It seems to me that virtual desktop focus has gone back to its old behavior (applications inside a virtual desktop are not notified when the virtual desktop window loses focus).
Is this still an issue?
http://bugs.winehq.org/show_bug.cgi?id=9320
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
--- Comment #4 from Austin English austinenglish@gmail.com 2009-01-15 10:53:25 --- Removing deprecated CVS/GIT version tag. Please retest in current git. If still present, update version field to earliest known version of wine that had this bug. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=9320
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
http://bugs.winehq.org/show_bug.cgi?id=9320
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@araneidae.co.uk
--- Comment #5 from Vitaliy Margolen vitaliy@kievinfo.com 2009-10-19 08:24:18 --- *** Bug 19874 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #6 from Vitaliy Margolen vitaliy@kievinfo.com 2009-10-19 21:00:09 --- *** Bug 19874 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=9320
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org Target Milestone|1.2.0 |---
--- Comment #7 from Scott Ritchie scott@open-vote.org 2009-11-08 03:14:16 --- We discussed this a bit at wineconf, it would help if there were more specific bugs for this. Thank you!
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #8 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-08 11:33:24 --- (In reply to comment #7)
We discussed this a bit at wineconf, it would help if there were more specific bugs for this. Thank you!
How about making at least one application gain focus inside virtual desktop?
And what was the reason you removed nomination for 1.2.0?
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #9 from Vincent Povirk madewokherd@gmail.com 2009-11-08 15:41:48 --- (In reply to comment #8)
How about making at least one application gain focus inside virtual desktop?
That seems unrelated to any previous comment.
And what was the reason you removed nomination for 1.2.0?
We need one bug per problem or it gets very confusing. I can't figure out whether this bug is fixed or which problems remain.
Which applications have difficulties with focus? I cannot test whether they're still there or work on fixing them if I don't know what they are.
http://bugs.winehq.org/show_bug.cgi?id=9320
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine Virtual Desktop lacks |No applications inside |proper focus handling |virtual desktop get | |properly focused and | |activated Severity|enhancement |normal
--- Comment #10 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-08 15:57:08 --- (In reply to comment #9) Focus management means at least one application running inside virtual desktop can get focus and become active and foreground. No more no less. Test with wine's own notepad and look at debug channels. Wine never gives focus to notepad. It always stays with explorer.
And with resent take focus changes now explorer doesn't even want to take that focus at all.
Start with this.
http://bugs.winehq.org/show_bug.cgi?id=9320
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.2.0
--- Comment #11 from Vincent Povirk madewokherd@gmail.com 2009-11-08 16:30:27 --- Thanks, I know what you mean now. This actually bit me in sugared wine.
Re-adding 1.2 target since we only removed it because of how confused we were.
We explicitly test for virtual desktop mode in X11DRV_SetFocus and never set focus to any Wine window in that case. Keyboard input only ever worked by coincidence because of how X happens to work, and explorer should never really have been focused at all.
Now that we use locally active mode, it might be enough to simply disable that check.
If we do disable the check, we'll still have the following problems: * Only one window, inside or outside the virtual desktop, can be focused. Windows inside the virtual desktop will lose focus to those outside, and the other way around. (I've envisioned an alternative scheme where focus is tracked separately inside the desktop and copied to the X side when focus is inside the desktop, but I think I will have to abandon that because it causes too many complications.) * The virtual desktop still won't respond to WM_TAKE_FOCUS. You'll have to click on a window inside a virtual desktop to focus it. I don't know what a sensible response to WM_TAKE_FOCUS could be. * There's a possible race condition where the focus according to wineserver may not match the focus according to the X server. The problem is that we can set the focus and, if someone else (maybe in the same desktop) did the same thing earlier but with a later timestamp, or we used a timestamp that is later than the X server's clock (unfortunately, this is possible with the current code), we get no FocusIn event or FocusOut event from the X server. I worried about fixing this along with the virtual desktop focus previously, but now I think it's an independent issue and should be thought of separately.
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #12 from Vincent Povirk madewokherd@gmail.com 2009-11-08 16:47:44 --- It actually looks like we try to focus the foreground window when the virtual desktop gets WM_TAKE_FOCUS. That really should work, but in my testing it doesn't.
When I click the titlebar of a virtual desktop with notepad in it, notepad does not get the focus (I can't type into it while my mouse is on the virtual desktop titlebar), and I get this:
trace:event:handle_wm_protocols got take focus msg for 0x30032, enabled=1, visible=1 (style 96000000), focus=0x30032, active=0x30032, fg=0x20052, last=(nil) trace:event:set_focus setting foreground window to 0x20052 trace:event:set_focus setting focus to 0x30032 (480000b) time=3998603
It seems we do SetForegroundWindow(0x20052), then we really set input focus to GetAncestor(GetFocus(), GA_ROOT), which returns 0x30032. 20052 is notepad, and 30032 is the desktop.
Does setting Foreground and reading back Focus make sense? I'm not very clear on the concepts.
(The problem with X11DRV_SetFocus is different from set_focus and still exists too.)
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #13 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-08 17:12:38 --- Need to be careful here what we enable/implement.
Lots of windows games will suspend when they loose focus. And many Wine users indicated they don't want that to happen when using virtual desktop. This is requirement #1: 1. Foreground/active/focused application (should always be the same in win32 world) should not loose focus when virtual desktop looses focus to another app.
The opposite is also true: 2. When virtual desktop regains focus from another X-application it should not take focus away from currently focused application inside virtual desktop.
To avoid some complications from the above two requirements (making an application loose focus inside VD while explorer still focused). Consumption of X-events sent to explorer: 3. It should be possible to switch focus between different windows running inside same virtual desktop. This also includes virtual desktop (explorer) itself. This can be done by clicking anywhere inside the window, including non-client area. And/or using a hot key (useful for fullscreen apps).
The #3 is the really tricky one. Implementing this in full won't be easy nor necessary for most users. Basic focus change on click/hot key and focusing first window should be enough.
With the above requirements Wine should really differentiate X-focus and it's internal focus in case of using virtual desktop of course. Take focus should still be used (idea of mouse-over to focus is really alien to Windows and it's users).
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #14 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-08 17:19:50 --- I've been hacking on-and-off on this bug for a long while. And every single time it went into a dead-end.
Removing that check you were talking about: static inline BOOL can_activate_window( HWND hwnd ) { ... - if (hwnd == GetDesktopWindow()) return FALSE;
Is the major step forward. But something still doesn't want to set focus to the notepad, even when caption becomes active. Also none of the WM_SETFOCUS/WM_KILLFOCUS and associated notifications make it to the explorer's message loop even as you indicated it appears they should.
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #15 from Vincent Povirk madewokherd@gmail.com 2009-11-08 17:24:04 --- I was talking about the check in X11DRV_SetFocus:
if (root_window == DefaultRootWindow(display))
I still don't know if this is a sound thing to do, but we need that function to somehow lead to the X window being focused.
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #16 from Vincent Povirk madewokherd@gmail.com 2009-11-08 17:51:24 --- Removing that check has at least one interesting side-effect: We can now get FocusIn events (which we basically ignore) and FocusOut events on windows in a virtual desktop.
When we get a FocusOut event, we change the foreground window to the desktop window. That means that, when we activate the desktop window by clicking its titlebar, we have no foreground window and end up focusing the desktop instead of the app, which is what I clearly want.
I think we should remember the window that had the focus when the desktop lost focus, and return to that window when it gets the focus back. (We could also try to not change the foreground window when the desktop loses focus, but removing that line just brought things back to the status quo for some reason.. maybe we need that to re-focus the window properly.)
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #17 from Vincent Povirk madewokherd@gmail.com 2009-11-11 14:09:36 --- I think I get it. Explorer can SetForegroundWindow() another process's window, but GetFocus() will only return a window in the current thread. So it ends up focusing the desktop.
However, if we want the virtual desktop focus to have its own focus, independent from the rest of X, we don't want to change the foreground window when the virtual desktop is focused. We just want to find the right hwnd and give it the X focus.
But which hwnd should be focused? Is it GetForegroundWindow() ? Is that the same as the window that gets keyboard input?
Or do I want GetGUIThreadInfo(NULL)->focus ?
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #18 from Vincent Povirk madewokherd@gmail.com 2009-11-11 15:17:17 --- Doomed patches sent: http://source.winehq.org/patches/data/55187 http://source.winehq.org/patches/data/55188 http://source.winehq.org/patches/data/55189
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #19 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-11 23:48:54 --- (In reply to comment #17)
But which hwnd should be focused? Is it GetForegroundWindow() ? Is that the same as the window that gets keyboard input?
Theoretically that should be the window that had focus before VD lost it's X-focus. In practice - focus inside VD shouldn't change since the foreground window shouldn't change either. At least if it just regained focus without a pointer click somewhere inside. In that case whatever window was clicked should get focus.
(In reply to comment #18) These patches do make things better. Except active window inside VD being deactivated and loosing focus when VD looses X-focus.
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #20 from Vincent Povirk madewokherd@gmail.com 2009-11-12 10:32:30 --- The patches were committed.
In my testing, the active window stayed active when the virtual desktop lost focus, but I'll check again in git master.
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #21 from Vincent Povirk madewokherd@gmail.com 2009-11-12 11:23:17 --- Things seem to work fine here when the virtual desktop is unfocused. The active titlebar still looks active (if it did to begin with, but that's another bug), and keyboard input goes there when the virtual desktop is focused again.
http://bugs.winehq.org/show_bug.cgi?id=9320
--- Comment #22 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-12 22:28:48 --- Works good with only one problem - first app started isn't shown as foreground (title is inactive). Even thou it has the focus. Starting second app allows to switch focus to another application as well as make it active.
Tested with KDE3, Gnome & XFCE.
Almost there.
http://bugs.winehq.org/show_bug.cgi?id=9320
Carlton Hobbs carlton.hobbs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |carlton.hobbs@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=9320
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #23 from Alexandre Julliard julliard@winehq.org 2010-06-16 08:17:41 --- Good enough for now. Please file new bug for initial title bar not being shown active.
http://bugs.winehq.org/show_bug.cgi?id=9320
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2010-06-18 12:46:06 --- Closing bugs fixed in 1.2-rc4.
http://bugs.winehq.org/show_bug.cgi?id=9320
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other OS/Version|All |other
--- Comment #25 from Austin English austinenglish@gmail.com 2012-02-23 15:12:53 CST --- Removing deprecated 'All' Platform/OS.
-
wine-bugs＠winehq.org