http://bugs.winehq.org/show_bug.cgi?id=23180
Summary: TREPCAD St3: no 'close' window control (regression) Product: Wine Version: 1.2-rc3 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: andreas@braml.org CC: dmitry@codeweavers.com
TREPCAD3 St3 doesn't have a 'close' window control (the small x) any more. Alt-F4 works. The control used to be there until recently.
The app can be used in two ways: as a plugin to MegaCAD and as a standalone app. When used standalone, it doesn't have a menu bar (so, no 'File->Quit'). But it always has the 'x' to close (on real Windows and on Wine before the regression).
I ran a regression test and the bad commit is:
commit e35e75b4bf5db54cd6cda0c95dc8c9e14c1fccfb (winex11.drv: Do not allow WM actions for windows with WS_DISABLED style set)
Ping me which logs you need to investigate. Plain console log isn't that useful, I suppose.
http://bugs.winehq.org/show_bug.cgi?id=23180
Andreas Hermann Braml andreas@braml.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=23180
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|TREPCAD St3: no 'close' |TREPCAD St3: no 'close' |window control (regression) |window control
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-14 22:30:50 --- Windows with WS_DISABLED style set can't be closed with a Close button, so a missing Close button shouldn't be a problem.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-15 04:17:08 --- Is there a real problem with the application except the visually missing close button?
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #3 from Andreas Hermann Braml andreas@braml.org 2010-06-15 04:38:46 --- Is there a problem? Depends.
If you know about Alt-F4: no, there isn't. But if the X is all you know about closing windows (like my test user for the app; yes, I have "lab rats" for testing!) then there is. The app doesn't have a menu bar nor a button somewehre else to shut it down. And on Windows native the X is there and does what it should.
So if bug-for-bug compatibility is still a goal, this is a bug.
Else it's indeed 'minor', with an educative twist: the more people that know about Alt-F4, the better. I think that's why there's that T-shirt around ;)
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-15 04:57:04 --- (In reply to comment #3)
If you know about Alt-F4: no, there isn't. But if the X is all you know about closing windows (like my test user for the app; yes, I have "lab rats" for testing!) then there is. The app doesn't have a menu bar nor a button somewehre else to shut it down. And on Windows native the X is there and does what it should.
Are you sure that pressing the 'x' button really works under Windows for this application? I'd expect 'x' be there but be inaccessible (disabled/grayed).
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #5 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-21 03:14:30 --- Please answer the question.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #6 from Andreas Hermann Braml andreas@braml.org 2010-06-21 10:20:07 --- Sorry that it takes so long, but I'm investigating this.
Right now, installed on a vanilla Win 2000 SP4, TREPCAD doesn't work, i.e. the app doesn't get far enough to verify the 'x' .The window loads with an x, and it is not greyed out. But I can't test if it does what an x should do.
I contacted their support to get it to run, which is quite absurd since the app normally is used only on a known-good Wine version (what do I care if it doesn't work on Windows?). As soon as they give me a hint, I'll add to this bug report.
If everything else fails, I will just ask _them_ if the x shows and does what it should on their native Windows install :)
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-21 11:12:09 --- (In reply to comment #6)
Sorry that it takes so long, but I'm investigating this.
Right now, installed on a vanilla Win 2000 SP4, TREPCAD doesn't work, i.e. the app doesn't get far enough to verify the 'x' .The window loads with an x, and it is not greyed out. But I can't test if it does what an x should do.
I contacted their support to get it to run, which is quite absurd since the app normally is used only on a known-good Wine version (what do I care if it doesn't work on Windows?). As soon as they give me a hint, I'll add to this bug report.
No problem, thanks for your efforts.
If everything else fails, I will just ask _them_ if the x shows and does what it should on their native Windows install :)
'x' of course should appear on Windows, it just should be grayed out. Wine removes 'x' from the caption because there is no other way to tell a WM that 'x' should be disabled, and not react on mouse button presses.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #8 from Andreas Hermann Braml andreas@braml.org 2010-06-22 12:02:00 --- The problem on native Windows was a missing printer driver, doh!
Now that it works, I can confirm: the X is there and active. Clicking it closes the application (tested on Windows 2000 SP4).
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #9 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-23 00:05:46 --- What WM are you using? Can you check with 'wine notepad' that after pressing Ctrl+O main Notepad window loses its 'x' close button, and after pressing Esc 'x' is back?
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #10 from Andreas Hermann Braml andreas@braml.org 2010-06-23 17:31:56 --- I'm using KWin. And this seems to be the problem.
I tried your steps with notepad on KWin (and Fluxbox's WM), and the behavior is as follows (on both of them).
1) After Ctrl+O, the 'x' of the main window is greyed out (and inactive, clicking it does nothing). 2) Esc reactivates the window controls (including the 'x') of the main window.
Just for fun, I tried TREPCAD on both Metacity and Fluxbox.
On Metacity: The main window initially doesn't have any window controls, the child window (where you select the desired type of stair) is displayed without window controls as well. When you're done with the child window, the main window should get focus (which it doesn't). As soon as I click the main window, it gets the focus, the window controls appear, including the X, which is now working as it should.
On Fluxbox: Behavior somehwere between that of Metacity and KWin. The 'X' of the main window is inactive as long as there's a child. When the main window is the last remaining window of TREPCAD, it gets the focus and the 'X' is then active. No other window controls (maximize/minimize) are ever displayed.
Does this mean that the bugs are in the WMs, not in Wine?
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #11 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-23 23:04:00 --- What is the behaviour with window controls under Windows?
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #12 from Andreas Hermann Braml andreas@braml.org 2010-06-24 08:30:48 --- On Windows, TREPCAD behaves as follows:
Upon startup, the stair selection child window is displayed without any controls and has the focus. The main window is in the background, all window controls are displayed and not greyed out; the main window itself is (as it does not have focus). Clicking the main window's controls doesn't do anything.
As soon as I select a stair, the child window disappears and the main window gets the focus. The window controls get active then.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #13 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-24 23:19:05 --- (In reply to comment #12)
On Windows, TREPCAD behaves as follows:
Upon startup, the stair selection child window is displayed without any controls and has the focus. The main window is in the background, all window controls are displayed and not greyed out; the main window itself is (as it does not have focus). Clicking the main window's controls doesn't do anything.
As soon as I select a stair, the child window disappears and the main window gets the focus. The window controls get active then.
This sounds similar to the description in the comment #10.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #14 from Andreas Hermann Braml andreas@braml.org 2010-06-25 07:00:07 --- (In reply to comment #13)
(In reply to comment #12)
[...]
This sounds similar to the description in the comment #10.
As far as Metacity and Fluxbox are concerned: yes. But the problem is with KWin, where the X is missing after the child window closes. So is it their bug, not Wine's?
(Mind that comment #12 describes the beaviour of TREPCAD on Windows (not Notepad) Just to make sure...)
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #15 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-25 07:01:48 --- (In reply to comment #14)
As far as Metacity and Fluxbox are concerned: yes. But the problem is with KWin, where the X is missing after the child window closes. So is it their bug, not Wine's?
Yes, that sounds like a KWin bug.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #16 from Andreas Hermann Braml andreas@braml.org 2010-06-25 10:45:27 --- A workaround is to uncheck that the window manager should control the windows in the graphics settings with winecfg.
I would report the bug to KWin next. Although I can give a description of the sympthoms of the bug and insert a link to here, I don't have any insight into what part of their window management stuff doesn't work as expected.
Should I post the link to the report on bugs.kde.org so that you could give them more specific information, as time permits? Or would you prefer to file the bug yourself, giving them the more general description of the problem at hand right from the start?
One way or another, it would be great if you could lend a hand in further triaging this beast ;)
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #17 from Dmitry Timoshkov dmitry@codeweavers.com 2010-06-25 23:14:12 --- Well, the very first thing that should help a lot in investigating the problem is to find a freely downloadable application that has this problem. That's why I asked if you could reproduce the problem with Wine's notepad.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #18 from Andreas Hermann Braml andreas@braml.org 2010-06-26 06:25:39 --- OK, but what exactly are we looking for? 'An application with a main window that starts up as WM_DISABLED that changes its WM_* state later'? Would any of the WINEDEBUG logs for TREPCAD help? Unfortunately, from the top of my head I don't know any other app that behaves like TREPCAD :( But I will check everything I have in my 'Dogfood' directory for a start.
http://bugs.winehq.org/show_bug.cgi?id=23180
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |RandomAccountName@mail.com
--- Comment #19 from A Wine user RandomAccountName@mail.com 2010-07-09 10:22:19 --- Slam! also has this problem. It's available for download here: http://www.classicdosgames.com/game/Slam!.html
On startup, this game pops up two windows, the main game window and another window requesting registration. On Windows XP, the main window displays a close button at all times, but it only becomes functional after dismissing the registration window. Using Wine, the behavior is inconsistent between WMs.
KWin: the close button is always missing. Metacity: all window controls are missing at first, but they appear after dismissing the registration window. Openbox: behavior is consistent with Windows.
Reverting e35e75b4bf5db54cd6cda0c95dc8c9e14c1fccfb makes all three WMs behave like Windows.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #20 from Dmitry Timoshkov dmitry@codeweavers.com 2010-07-09 11:08:56 --- Created an attachment (id=29465) --> (http://bugs.winehq.org/attachment.cgi?id=29465) Don't use dialog type windows
Does the attached patch help?
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #21 from Andreas Hermann Braml andreas@braml.org 2010-07-09 19:51:49 --- Re the game mentioned in comment #19 I can't confirm that it behaves the same as TREPCAD (at least not on 1.2-rc6). In KWin, the close button "x" is always there when I run WSLAM.EXE. So, at least for me, the game doesn't have this bug.
Re Dmitry's patch from comment #20: Unfortunately, it doesn't change the bahviour with KWin and thus doesn't fix the bug. The "x" is still missing in TREPCAD with your patch applied. Everything else apparently is the same, too.
I can check with the other WMs on my main computer after the weekend (to see if the patch changes anything for them).
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #22 from A Wine user RandomAccountName@mail.com 2010-07-10 07:46:20 --- (In reply to comment #20)
Does the attached patch help?
Unfortunately, no. At first, I thought it did, but it looks like something weird is going on with this game and KWin. The first time I ran it with the patch, everything looked fine. But the second time, the close button disappeared again. Some further testing shows that the close button is visible sometimes, and missing sometimes, regardless of whether I have that patch applied...
This discovery did cast some doubt on reverting the aforementioned commit being a solution (I could have just gotten lucky that time), but I tried running it ~30 times with that patch reverted and couldn't reproduce the problem that way.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #23 from Dmitry Timoshkov dmitry@codeweavers.com 2010-07-10 10:49:40 --- (In reply to comment #22)
Unfortunately, no. At first, I thought it did, but it looks like something weird is going on with this game and KWin. The first time I ran it with the patch, everything looked fine. But the second time, the close button disappeared again. Some further testing shows that the close button is visible sometimes, and missing sometimes, regardless of whether I have that patch applied...
These all very much sounds like a KWin bug. Close button works as expected for me under Gnome.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #24 from Andreas Hermann Braml andreas@braml.org 2010-08-01 11:34:37 --- Finally I got around to filing a bug for this against KWin. For the record, it's here: https://bugs.kde.org/show_bug.cgi?id=246442
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #25 from Andreas Hermann Braml andreas@braml.org 2011-02-08 02:32:31 CST --- Update from https://bugs.kde.org/show_bug.cgi?id=246442 :
""" Git commit 9a8e4305d574e562c12e9f749322546bc325f014 by Thomas L��bking. Committed on 06/02/11 at 16:42. Pushed by luebking into branch 'master'.
Update deco buttons when allowed actions change
BUG: 246442
M +2 -1 kwin/client.cpp
http://commits.kde.org/kde-workspace/9a8e4305d574e562c12e9f749322546bc325f01... """
This might fix the behaviour in Wine, but I can't compile KDE trunk right now. Unless the patch gets backported to KDE SC 4.6.x, I'll have to wait for the first 4.7 Alpha to test.
http://bugs.winehq.org/show_bug.cgi?id=23180
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #26 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-08 03:06:19 CST --- Thanks for the update. Let's wait for the real testing before closing this bug as invalid.
http://bugs.winehq.org/show_bug.cgi?id=23180
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |e35e75b4bf5db54cd6cda0c95dc | |8c9e14c1fccfb
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #27 from Dmitry Timoshkov dmitry@baikal.ru 2012-01-03 00:05:42 CST --- Does the updated KDE/KWIN have this bug fixed?
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #28 from Andreas Hermann Braml andreas@braml.org 2012-01-22 07:26:29 CST --- No, not fixed. KDE 4.8 RC2 still has this bug.
http://bugs.winehq.org/show_bug.cgi?id=23180
--- Comment #29 from Andreas Hermann Braml andreas@braml.org 2012-01-23 10:52:04 CST --- Strange. I tried again today, and the bug seems to be fixed after all! You can mark it as such.
Should I ever see it again, I will report back. But for now, all's well.
http://bugs.winehq.org/show_bug.cgi?id=23180
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|TREPCAD St3: no 'close' |TREPCAD St3: no 'close' |window control |window control (not a Wine | |bug)
--- Comment #30 from Dmitry Timoshkov dmitry@baikal.ru 2012-01-23 11:04:14 CST --- Thanks for testing, let's mark this bug as invalid.
http://bugs.winehq.org/show_bug.cgi?id=23180
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |UPSTREAM
--- Comment #31 from Dmitry Timoshkov dmitry@baikal.ru 2012-03-14 02:46:33 CDT --- Window Manager bug.
http://bugs.winehq.org/show_bug.cgi?id=23180
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED See Also| |https://bugs.kde.org/show_b | |ug.cgi?id=246442
--- Comment #32 from Dmitry Timoshkov dmitry@baikal.ru 2012-03-14 02:47:18 CDT --- Closing.
-
wine-bugs＠winehq.org