[Bug 9301] New: regression: windows almost never focussed or loose focus
http://bugs.winehq.org/show_bug.cgi?id=9301 Summary: regression: windows almost never focussed or loose focus Product: Wine Version: 0.9.43. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-x11driver AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net Hi, since upgrading to 0.9.42 and 0.9.43, I cannot use wine anymore because most windows don't get focus or immediately loose it when clicking, even winecfg and regedit. Some apps iconify as soon as I click something. I upgraded from 0.9.38 (so I don't know whether the regression was introduced with 0.39, .40, 41 or 42). Although I'm using metacity in Ubuntu Dapper, I believe this bug is different from bug #5120 as I had been using Ubuntu with wine successfully with 20070725, 0.9.9, 0.9.15 .16, .19 21 ... and many other versions. Symptoms: winecfg & regedit start without getting focus. When I move the cursor from one window to the other, the "window resize" cursor that was set while moving over the window's border remains set even after I click to activate the second window. There are also several refresh problems when moving windows (mostly grey border lines) in winecfg and regedit. Every time I activate the wine 800x600 desktop window, all ms-windows apps become deactivated (some iconify then). Normally, I have apps\metycity\focus_mode "sloppy" set via the preferences (the Gnome prefs set "sloppy", not "mouse"). With that, the situation is now so bad that wine is unusable. E.g. I can activate winecfg only by moving its window. Then, approx every other click causes the window to loose focus (which causes other apps to iconify). Every other click does not toggle the boolean checkboxes in winecfg (because its window is not active). When I'm not using a wine desktop window, the sudden iconification also prevents the apps from being usable, as there's no "restore" menu available (and "maximize" is disabled) in Gnome/metacity. I have no other window managers installed on this machines to try. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9301 --- Comment #1 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2007-08-13 13:48:57 --- I've compared effects with 0.9.15. What's the same: o When a second window is present (e.g. winecfg + regedit), switching focus from one to the other works (dark blue window border). o Refresh problems (remains from borders) when moving these windows around were present then as well. o The resize cursor also remains active after changing the focus window. What's different? o In .15, winecfg starts without focus (in a 800x600 desktop window), yet clicks are handled: boolean toggles work (despite no focus!). o When only a single app remains in .43 (e.g. winecfg, exiting regedit), it does not automatically get focus. o When the wine window is focussed, the unique winecfg app therein sometimes gets focussed, sometimes not. In 0.9.15, winecfg always got focussed. o Clicking above the winecfg:graphic boolean toggles shows flicker in the window title area including the right close button (as if erased (unfocused?), then redrawn) in .43, while the display in .15 remains stable all time. In summary, .43 obtains best work-around results while two apps are running. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9301 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Summary|regression: windows almost |windows almost never |never focussed or loose |focussed or loose focus |focus | --- Comment #2 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2007-08-13 13:58:49 --- Are all your tests with virtual desktop or without? This is really important, because Wine does not and probably won't have full window manager that is required for the virtual desktop. Also please do not use such and ancient version as 0.9.15 for comparison testing. The change you talking about happened in wine-0.9.42. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9301 --- Comment #3 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2007-08-14 03:32:10 --- An 800x600 wine virtual desktop window inside a larger X screen is what I constantly use, as that has given me best results over the years, with various apps. Otherwise, some (old) apps may cause the X display to flicker, change resolution (IIRC) or other weirdness; iconification in X produces very strange results, often enough the app terminates instead of recovering (lacking a "restore window" functionality). Using a desktop prevents all these graphical effects: the apps just sit there and know nothing about other resolutions and X windows. Also, I can iconify the desktop, while some apps (e.g. winecfg) do not provide an icon button. All in all, the virtual desktop gives me the best environment, except when full-screen makes sense (for some games or regedit's large window). <feature-request ;>Alas, I cannot set per app full-screen preferences. Otherwise, I'd let regedit and selected games open full-screen, keeping the virtual desktop default for most other apps. I was using .9.15 for comparison because I happen to have it in a separate directory. Whereas .38, .36, .31 .28 get overwritten each time I upgrade via bzcat diffs.bz2 | patch -p1. BTW, I've never had the winecfg toggle "allow window manager to control windows" have any observable effect. I typically have it set. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9301 --- Comment #4 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2007-08-14 07:28:21 --- To me it looks a bit like a race condition somewhere. I've observed different cases, solely running winecfg and clicking next to the "ok" box. - winecfg unselected, click, becomes selected - winecfg selected, click, remains selected (but short flashing of title screen) - idem, no visible flashing - winecfg selected, click, becomes unselected. The last case is rare after moving the winecfg window inside the virtual desktop for the first time, but almost 100% when just started. Here's some WINEDEBUG=trace+event winecfg. The ony difference is fg=20/24. window selected & remains selected trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events trace:event:process_events ClientMessage for hwnd/window 0x10020/3a00007 trace:event:handle_wm_protocols got take focus msg for 0x10020, enabled=1, visible=1 (style 96000000), focus=0x10020, active=0x10020, fg=0x10024, last=(nil) trace:event:set_focus setting foreground window to 0x10020 trace:event:process_events processed 1 events trace:event:process_events EnterNotify for hwnd/window 0x10024/3600001 trace:event:process_events KeymapNotify for hwnd/window (nil)/0 trace:event:process_events ButtonPress for hwnd/window 0x10024/3600001 trace:event:process_events processed 3 events trace:event:process_events ButtonRelease for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events window unselected, becomes selected via click trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events trace:event:process_events ClientMessage for hwnd/window 0x10020/3a00007 trace:event:handle_wm_protocols got take focus msg for 0x10020, enabled=1, visible=1 (style 96000000), focus=0x10020, active=0x10020, fg=0x10020, last=(nil) trace:event:set_focus setting foreground window to 0x10020 trace:event:process_events processed 1 events trace:event:process_events EnterNotify for hwnd/window 0x10024/3600001 trace:event:process_events KeymapNotify for hwnd/window (nil)/0 trace:event:process_events ButtonPress for hwnd/window 0x10024/3600001 trace:event:process_events processed 3 events trace:event:process_events ButtonRelease for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events unselected, click, remains unselected (right after starting the app) (Click would then not toggle boolean button). trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events trace:event:process_events EnterNotify for hwnd/window 0x10024/3600001 trace:event:process_events KeymapNotify for hwnd/window (nil)/0 trace:event:process_events ButtonPress for hwnd/window 0x10024/3600001 trace:event:process_events processed 3 events trace:event:process_events ClientMessage for hwnd/window 0x10020/3a00007 trace:event:handle_wm_protocols got take focus msg for 0x10020, enabled=1, visible=1 (style 96000000), focus=0x10020, active=0x10020, fg=0x10024, last=(nil) trace:event:set_focus setting foreground window to 0x10020 trace:event:process_events processed 1 events trace:event:process_events ButtonRelease for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events trace:event:process_events MotionNotify for hwnd/window 0x10024/3600001 trace:event:process_events processed 1 events Note the different order of events in the last case. All traces where taken with focus_mouse "sloppy". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9301 Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX --- Comment #5 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2007-08-14 08:16:12 --- Jörg Höhle, DO NOT PASTE LOGS! If you can't read, here it is again: Please do not PASTE logs and back traces, (attach them instead). And I told you, that what you describing is the functionality of the window manager. Wine does not implement all of it for the virtual desktop. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9301 --- Comment #6 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2007-08-14 11:46:38 --- Sorry for posting log snippets. I found out that the order of EnterNotify vs ClientMessage/takefocus depends on whether the window will be selected at the end: - EnterNotify then take focus: unselected at end - take focus, then EnterNotify: selected
The change you talking about happened in wine-0.9.42. Confirmed. I changed server/window.c:is_top_level_window() to what it was before and the iconify & input problems went away (mentioned refresh problems and winecfg accepting clicks despite not being shown active and remaining inactive are still there), even with focus_mouse "sloppy".
Regards, Jörg Höhle -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9301 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #7 from Austin English <austinenglish(a)gmail.com> 2008-09-17 08:51:20 --- Closing WONTFIX. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org