[Bug 40828] New: Switching resolution in desktop mode makes task bar redraw on top of full screen game
https://bugs.winehq.org/show_bug.cgi?id=40828
Bug ID: 40828 Summary: Switching resolution in desktop mode makes task bar redraw on top of full screen game Product: Wine Version: 1.9.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: o.dierick@piezo-forte.be Distribution: ---
I got this issue with Aliens versus Predator Classic 2000 on Steam.
Preamble :
The game uses 800x600 screen size to render cinematic and the main menu. The gameplay uses whatever screen resolution is set in the game video options menu. It switches between those two resolutions when starting or abandoning a level or when showing an in-game cinematic.
The Wine virtual desktop mode is set to the native screen resolution that is the same resolution used for gameplay. When the game does not run, the Steam window and the task bar are visible and working properly. Steam puts an icon in the notification tray of the task bar.
Issue :
When the game is launched it switches the desktop to 800x600 to show the intro cinematic. The task bar is visible and covers the bottom of the full-screen game. The cinematics are letter-boxed and the menu has nothing of importance on those few bottom pixels so it's not that much a problem. When starting a level, the game switches to the native screen resolution, but the task bar still covers the bottom of the screen. The game can be played as the task bar does not hide much but it contrasts with the game and should be hidden by the full-screen app anyway.
Workaround :
The game grabs the mouse, so it is by default not possible to click on the window button on the task bar to refresh the game window, but activating the Steam game overlay frees the mouse cursor, and allow to click on the window button on the task bar. Clicking on that button twice makes the game window redraw over the task bar. The Steam overlay can then be closed and the game can be played with the task bar hidden.
However, starting/abandoning a level or viewing a cinematic makes the game switch resolution and the task bar come back.
https://bugs.winehq.org/show_bug.cgi?id=40828
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com Status|UNCONFIRMED |NEW URL| |http://store.steampowered.c | |om/app/3730/ Ever confirmed|0 |1
--- Comment #1 from Béla Gyebrószki gyebro69@gmail.com --- I can confirm the reported problem when playing AvP Classic 2000 on Steam.
Wine 1.9.13 Fedora 24 XFCE 4.12
https://bugs.winehq.org/show_bug.cgi?id=40828
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #2 from Robert Walker bob.mt.wya@gmail.com --- Created attachment 55016 --> https://bugs.winehq.org/attachment.cgi?id=55016 Disable Wine Desktop tray_window creation (hack)
Yup, the Wine Virtual Desktop panel is really dumb... It appears if you are running more than one application and has no configuration options what-so-ever. It would nice to have at least the option to disable completely it with a Wine registry setting.
I've attached a patch, tested with Wine-Staging 1.9.13 git, that disables the taskbar/panel (aka "tray_window") from ever being created. Certainly reverts the issue that op is experiencing (fixing AvP Classic for example).
https://bugs.winehq.org/show_bug.cgi?id=40828
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #55016|0 |1 is obsolete| |
--- Comment #3 from Robert Walker bob.mt.wya@gmail.com --- Created attachment 55024 --> https://bugs.winehq.org/attachment.cgi?id=55024 Add Wine Registry support for disabling taskbar
It adds support to selectively disable the taskbar (tray window) in Virtual Desktop mode. Toggling the setting is done via a Wine Registry key.
This patch might have a (small) chance to get into Wine. Anyway I'll submit it when I get a chance...
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #4 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- The patch does work.
https://bugs.winehq.org/show_bug.cgi?id=40828
Jarrard Lo overlord.jarrard@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |overlord.jarrard@gmail.com
--- Comment #5 from Jarrard Lo overlord.jarrard@gmail.com --- (In reply to Robert Walker from comment #3)
Created attachment 55024 [details] Add Wine Registry support for disabling taskbar
It adds support to selectively disable the taskbar (tray window) in Virtual Desktop mode. Toggling the setting is done via a Wine Registry key.
This patch might have a (small) chance to get into Wine. Anyway I'll submit it when I get a chance...
Does not persist, gets removed/reset after a couple uses of Wine windowed mode. I constantly apply the reg edit.
https://bugs.winehq.org/show_bug.cgi?id=40828
Alexandr Oleynikov sashok.olen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sashok.olen@gmail.com
--- Comment #6 from Alexandr Oleynikov sashok.olen@gmail.com --- Created attachment 61676 --> https://bugs.winehq.org/attachment.cgi?id=61676 sims3
Same with Sims 3. wine 3.10.
https://bugs.winehq.org/show_bug.cgi?id=40828
Linards linards.liepins@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linards.liepins@gmail.com
--- Comment #7 from Linards linards.liepins@gmail.com --- Not seen on wine-3.13-staging
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #8 from Linards linards.liepins@gmail.com --- (In reply to Linards from comment #7)
Not seen on wine-3.13-staging
Not experienced, to be more accurate.
https://bugs.winehq.org/show_bug.cgi?id=40828
Hamish Claxton hamishclaxton@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hamishclaxton@gmail.com
--- Comment #9 from Hamish Claxton hamishclaxton@gmail.com --- Created attachment 63131 --> https://bugs.winehq.org/attachment.cgi?id=63131 Fixes Bug 40828 - Switching resolution in desktop mode makes task bar redraw on top of full screen game
Experienced this bug with every game I tried on the latest Wine and Wine Staging releases (4.0 rc4).
Resolved with a simple patch which analyses the current foreground window resolution against the current virtual desktop resolution. If they match, the systray redraw is ignored.
After applying, issue is resolved with all previously tested games.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #10 from Hamish Claxton hamishclaxton@gmail.com --- (In reply to Hamish Claxton from comment #9)
Will try to submit to upstream if others report the issue has been resolved.
https://bugs.winehq.org/show_bug.cgi?id=40828
Hamish Claxton hamishclaxton@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=40828
Hamish Claxton hamishclaxton@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #63131|0 |1 is obsolete| |
--- Comment #11 from Hamish Claxton hamishclaxton@gmail.com --- Created attachment 63140 --> https://bugs.winehq.org/attachment.cgi?id=63140 Fixes Bug 40828
Previous patch while working, was incorrectly checking the current resolutions, new patch properly does this.
https://bugs.winehq.org/show_bug.cgi?id=40828
Hamish Claxton hamishclaxton@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #63140|0 |1 is obsolete| |
--- Comment #12 from Hamish Claxton hamishclaxton@gmail.com --- Created attachment 63178 --> https://bugs.winehq.org/attachment.cgi?id=63178 systray: Hide systray for fullscreen games
Completely rewritten, compares foreground window against desktop window. Handles borderless fullscreen modes.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #13 from Robert Walker bob.mt.wya@gmail.com --- (In reply to Hamish Claxton from comment #12)
Created attachment 63178 [details] systray: Hide systray for fullscreen games
Completely rewritten, compares foreground window against desktop window. Handles borderless fullscreen modes.
This latest patch (v4) certainly works with Aliens versus Predator Classic 2000. The game this issue was first reported against.
The latest patch also appears to be pretty robust. I can't think of any corner cases that would break it.
It would be nice to see the patch land in Wine 4.0 - since it affects a lot of games. The issue is technically a regression. Since it was introduced when the Virtual Desktop panel window was forced as topmost:
SetWindowPos( tray_window, HWND_TOPMOST, 0, GetSystemMetrics( SM_CYSCREEN ) - tray_height, tray_width, tray_height, SWP_NOACTIVATE | SWP_SHOWWINDOW );
with Wine 1.9.11.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #14 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 63192 --> https://bugs.winehq.org/attachment.cgi?id=63192 other way to fix issue
Hold on.
Hamish Claxton's efforts at fixing the issue awakened my interest into it. I reviewed his patches and thought that there was room for improvements. So I dug into the code base and ended with another approach:
The visibility of the taskbar is handled by do_hide_systray() and do_show_systray(). Those functions are called at certain events. do_show_systray() calls SetWindowPos() with HWND_TOPMOST and without SWP_NOZORDER. That causes the taskbar to be pushed on top of the window stack when do_show_systray() is called. Since WM_DISPLAYCHANGE calls do_show_systray() the taskbar comes to the foreground when the resolution changes.
Now for the fix: At first I thought about putting a condition when there is a fullscreen window in the foreground, as Hamish Claxton wanted to do, but I remembered that wine already hides the taskbar when a fullscreen window is open (the issue happens only when resolution changes). So I looked at how this was achieved. It actually amounts to a simple matter of Z order: When the taskbar is created do_show_systray() is called and the taskbar is pushed to the top of the window stack. This happens at the start of the virutal desktop, so there is no other window at that time. When the app creates its window, it's put to the top of the windows stack, so above the taskbar. When it is a fullscreen window, the taskbar is hidden (in fact, any window will cover the taskbar, just move or maximize a window over the taskbar and you'll see). So far so well. Then, when the resolution changes, WM_DISPLAYCHANGE calls do_show_systray() and the taskbar is pushed on top again. Since the window app is already open, it is no more above the taskbar and the issue happens.
So, the fix is to NOT push the taskbar to the top of the z order in any case. There is no drawback because the taskbar has never stuck 'above all windows' anyway.
And it also fix another potential issue: When an icon is added to the systray, show_icon() calls do_show_systray(). If it happens while a fullscreen window is open, it will push the taskbar on top of it too and cause the issue.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #15 from Robert Walker bob.mt.wya@gmail.com --- (In reply to Olivier F. R. Dierick from comment #14)
So, the fix is to NOT push the taskbar to the top of the z order in any case. There is no drawback because the taskbar has never stuck 'above all windows' anyway.
I've also taken a look at this issue. Even when the taskbar is drawn below a fullscreen game window, it is able to erroneously capture keypresses. This is a known issue with Doom 2016. Hamish's patch will provide a complete fix for this problem as well. Since the taskbar will not be drawn at all, if a window is fullscreen.
If the taskbar is not drawn on top of the Z-order stack then maximising a window will draw on top of the taskbar (which does not mimic native MS Windows behaviour). I've tested out a few scenarios, with a small C++ test program (compiled with winegcc) which simply draws a window. One the tests being to maximise the window.
https://bugs.winehq.org/show_bug.cgi?id=40828
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #16 from Zebediah Figura z.figura12@gmail.com --- (In reply to Robert Walker from comment #15)
If the taskbar is not drawn on top of the Z-order stack then maximising a window will draw on top of the taskbar (which does not mimic native MS Windows behaviour). I've tested out a few scenarios, with a small C++ test program (compiled with winegcc) which simply draws a window. One the tests being to maximise the window.
That shouldn't happen at all. Maximized windows should fill the workspace, which specifically excludes the taskbar.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #17 from Robert Walker bob.mt.wya@gmail.com --- (In reply to Zebediah Figura from comment #16)
(In reply to Robert Walker from comment #15)
If the taskbar is not drawn on top of the Z-order stack then maximising a window will draw on top of the taskbar (which does not mimic native MS Windows behaviour). I've tested out a few scenarios, with a small C++ test program (compiled with winegcc) which simply draws a window. One the tests being to maximise the window.
That shouldn't happen at all. Maximized windows should fill the workspace, which specifically excludes the taskbar.
Unfortunately it does though. I remember discussing this issue, probably on the WineHQ forums, with an other user having similar problems. So I'm not the only end user to experience this issue with DOOM 2016. The taskbar appears to capture focus when a player is moving around in game e.g. looking up and down with the mouse. Possibly when the virtual mouse hits the bottom pixel of the screen?? The end result is that you can't move in game at all and basically have to exit the game completely (e.g. switch virtual desktops or switch to a virtual TTY console).
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #18 from Zebediah Figura z.figura12@gmail.com --- (In reply to Robert Walker from comment #17)
(In reply to Zebediah Figura from comment #16)
(In reply to Robert Walker from comment #15)
If the taskbar is not drawn on top of the Z-order stack then maximising a window will draw on top of the taskbar (which does not mimic native MS Windows behaviour). I've tested out a few scenarios, with a small C++ test program (compiled with winegcc) which simply draws a window. One the tests being to maximise the window.
That shouldn't happen at all. Maximized windows should fill the workspace, which specifically excludes the taskbar.
Unfortunately it does though. I remember discussing this issue, probably on the WineHQ forums, with an other user having similar problems. So I'm not the only end user to experience this issue with DOOM 2016. The taskbar appears to capture focus when a player is moving around in game e.g. looking up and down with the mouse. Possibly when the virtual mouse hits the bottom pixel of the screen?? The end result is that you can't move in game at all and basically have to exit the game completely (e.g. switch virtual desktops or switch to a virtual TTY console).
Right, I just mean it's a bug in its own right.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #19 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- I have a feeling of deja-vu. I'll not fight over which patch is better.
I tested my patch with different mixes of Aliens versus Predator Classic 2000 (for the resolution switching), Steam (for maximizing window/its systray icon), notepad (to cover the taskbar) and taskmgr(for its systray icon), and I can confirm that my patch keeps the taskbar from covering anything.
I think it is an undesired side effect of do_show_systray() to push the taskbar to the top of the z order. The few events that trigger a call to do_show_systray() don't require it to be pushed on top of the z order. They are: - show_icon() → when an icon is added to the systray; - tray_wndproc() case WM_DISPLAYCHANGE → when resolution changes; - initialize_systray() → At the virtual desktop creation; There is no reason to put the taskbar on top of other window in any of these events.
Adding an option to put the taskbar 'always on top' would need other design changes outside the scope of this bug (window create/move/maximize would have to take the taskbar area into account, this is not implemented AFAICT).
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #20 from Zebediah Figura z.figura12@gmail.com --- Created attachment 63197 --> https://bugs.winehq.org/attachment.cgi?id=63197 adjusted version of Olivier's patch
When an application makes itself fullscreen, does that involve anything more than just setting its window to the size of the whole screen? Does it make the window topmost as well? Is there some other magic involved?
IIRC, a normal window always goes behind the taskbar on Windows, and a topmost window always goes over it. That's certainly consistent with the taskbar being topmost itself (and, I guess, unfocusable?)
Why is do_show_systray() called in show_icon()? The conditions under which the taskbar is shown are, I suppose, not immediately clear.
I think the approach of using SWP_NOZORDER makes sense in principle; when the display changes we need to resize the taskbar, but we don't want to reorder it. However, unless I'm mistaken SWP_NOZORDER implies that the ordering parameter to SetWindowPos() is ignored entirely, so I'd do something like the attached instead. Does this make more sense?
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #21 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- I found those observations by chromium developers:
--- quote --- (...) In XP and Vista, the taskbar has a user-configurable "Keep taskbar on top of other windows" option. When this is disabled, the taskbar is not a topmost window (...) When a fullscreen window exists (whether topmost or not), the Win OS will manipulate the taskbar's topmost property and z-order as necessary when switching between windows. --- quote --- https://bugs.chromium.org/p/chromium/issues/detail?id=320107
(In reply to Zebediah Figura from comment #20)
Created attachment 63197 [details] adjusted version of Olivier's patch
When an application makes itself fullscreen, does that involve anything more than just setting its window to the size of the whole screen? Does it make the window topmost as well? Is there some other magic involved?
The conditions for fullscreen are: - Same size as the desktop. - No caption or border window styles. The taskbar somehow checks those conditions on the active window and removes itself when they are met.
Topmost status of the fullscreen window is left to the app developer and doesn't matter for the taskbar. For example, you may have a non-topmost fullscreen window that makes the taskbar disappear, and topmost non-fullscreen windows that appear above the fullscreen window.
IIRC, a normal window always goes behind the taskbar on Windows, and a topmost window always goes over it. That's certainly consistent with the taskbar being topmost itself (and, I guess, unfocusable?)
It depends on the Windows version, but from the quote above I gather that the taskbar is topmost until it detects a fullscreen window and it removes itself. Note that the z order is undefined when there is more than one topmost window.
I don't know if the taskbar should be drawn under or over the other topmost windows. I guess that for security reasons we may enforce that the taskbar is on top of everything when there is no fullscreen window ?
Why is do_show_systray() called in show_icon()? The conditions under which the taskbar is shown are, I suppose, not immediately clear.
The taskbar is designed to auto-hide when the last icon is removed from the systray and auto-show when the first icon is added. In the current state, if the taskbar is hidden and an app adds an icon while there is a fullscreen window, the taskbar will appear over the fullscreen window. It should be disabled when a fullscreen window is detected.
I think the approach of using SWP_NOZORDER makes sense in principle; when the display changes we need to resize the taskbar, but we don't want to reorder it. However, unless I'm mistaken SWP_NOZORDER implies that the ordering parameter to SetWindowPos() is ignored entirely, so I'd do something like the attached instead. Does this make more sense?
SWP_NOZORDER tells the function to ignore the HwndInsertAfter parameter, but it sure looks better and more consistent to not set HWND_TOPMOST either.
Mmm. Setting WS_EX_TOPMOST on tray creation will require that the tray detects when a fullscreen window is active and removes itself, just like Hamish Claxton's patch does. - If the fullscreen window is topmost, the taskbar must be removed to avoid undefined behaviour. - If the fullscreen window is not topmost, the taskbar must be remove to avoid being drawn over the non-topmost fullscreen window.
I guess we need to mix both approach. So I suggest that Hamish Claxton merge your adjusted version of my patch with his own.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #22 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Hamish Claxton from comment #12)
Created attachment 63178 [details] systray: Hide systray for fullscreen games
Completely rewritten, compares foreground window against desktop window. Handles borderless fullscreen modes.
You may replace lines 920-926 with a simple assignment:
fullscreen = is_window_fullscreen( G... );
One of the ifs in the 'if true&!call else if false&call' construct will call the function anyway, so you may just as well call the function and catch the result in the variable.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #23 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Hamish Claxton from comment #12)
Created attachment 63178 [details] systray: Hide systray for fullscreen games
Completely rewritten, compares foreground window against desktop window. Handles borderless fullscreen modes.
Lines 788-790 are redundant with lines 939-941 in handle_systray(). That function will be called when the desktop receives the WM_PARENTNOTIFY, so sending the message is enough.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #24 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- I inadvertently hit tab while typing and pressed space on the 'Save Changes' button and now I see that the last two paragraphs of comment 21 don't make sense.
I meant to say that setting WS_EX_TOPMOST on the tray window defeats my patch because the topmost taskbar needs to hide when there is a fullscreen window, topmost or not, and this implies checking the foreground window.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #25 from Zebediah Figura z.figura12@gmail.com --- Right, okay. The important detail, I guess, is that a fullscreen window doesn't have to be topmost itself, so I guess we have two options:
1. Don't make the taskbar topmost, and just never adjust its z-order. The taskbar isn't focusable (or shouldn't be), so it can't be raised. Any fullscreen windows will then cover it. Any non-fullscreen windows also will cover it instead of going behind it. The latter is contradictory to current behaviour and to default Windows behaviour, but not too bad in the long run. This would mean essentially the patch from comment 14, and nothing else (though I'd still remove the redundant HWND_TOPMOST from that call.)
2. Make the taskbar topmost, and hide it when a fullscreen window is drawn. Necessary because a topmost window is always drawn over a non-topmost window, and the fullscreen window may be non-topmost. (Aside: I was under the impression that two topmost windows had normal stacking rules relative to each other, but maybe that's not the case. Anyway it doesn't matter much here.) In this case the patch to make the taskbar topmost on creation and not change its z-order becomes redundant, but should maybe still be applied anyway; it seems more existentially sensible (there's no reason why the taskbar should change its z-order in any of the given cases).
I don't know if I have a particular opinion which is better. (1) is simpler, but (2) is more consistent with Windows. Best to leave it up to those who more commonly use such UI, I guess.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #26 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- I may argue that (1) is consistent with older XP and Vista behavior.
We may implement the simplest (1) first, and then extend it latter with a "Keep taskbar on top of other windows" option implemented with (2). That option would then be enabled by default for recent windows compatibility, and users that want the old behavior may disable it.
Seeing things this way (1) would be the fix and (2) an UI enhancement.
https://bugs.winehq.org/show_bug.cgi?id=40828
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #63192|0 |1 is obsolete| |
--- Comment #27 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Created attachment 63203 --> https://bugs.winehq.org/attachment.cgi?id=63203 explorer: Don't change z order of the taskbar when displaying
- HWND_TOPMOST removed for consistency. - Submitted upstream.
Is anybody willing to test DOOM 2016 with this patch and report if the keypress issue still happens?
My theory is that clicking on the window button on the taskbar wrongly activates it. The app is brought to the foreground but inactive and the keypresses are sent to the taskbar instead.
Unfortunately, I can't test this theory myself.
My patch is not intended to fix that but it may do as a side effect, by preventing the taskbar to go over the fullscreen window in the first place.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #28 from Hamish Claxton hamishclaxton@gmail.com --- (In reply to Olivier F. R. Dierick from comment #23)
(In reply to Hamish Claxton from comment #12)
Created attachment 63178 [details] systray: Hide systray for fullscreen games
Completely rewritten, compares foreground window against desktop window. Handles borderless fullscreen modes.
Lines 788-790 are redundant with lines 939-941 in handle_systray(). That function will be called when the desktop receives the WM_PARENTNOTIFY, so sending the message is enough.
Actually these lines are there to serve as a double check, something I should have mentioned. Some games such as Dragon Age Inquisition and Project Eden exit fullscreen mode during a resolution change and therefore need a double check. There are also cases where without the double check, upon exiting, due to a double switch of resolutions, the systray gets drawn offscreen. As such I won't remove the double check from the code, but I will add a comment to justify.
Anyhow, with your recent patch, it seems my code is rather unnecessary, as yours seems to solve the issue in all the games I use for testing. The only difference is that when fullscreen mode exits on my patch, say going from fullscreen/borderless to windowed mode. The systray is drawn above the window - something of which I prefer personally.
I do agree though that your much simpler fix should be submitted upstream, though I am a bit confused as to what to do with mine as you say it should be used as an enhancement.
https://bugs.winehq.org/show_bug.cgi?id=40828
Alexandr Oleynikov sashok.olen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|sashok.olen@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #29 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Hamish Claxton from comment #28)
I do agree though that your much simpler fix should be submitted upstream, though I am a bit confused as to what to do with mine as you say it should be used as an enhancement.
I replied in bug 46437.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #30 from Hamish Claxton hamishclaxton@gmail.com --- (In reply to Olivier F. R. Dierick from comment #29)
(In reply to Hamish Claxton from comment #28)
I do agree though that your much simpler fix should be submitted upstream, though I am a bit confused as to what to do with mine as you say it should be used as an enhancement.
I replied in bug 46437.
Okay cool, I'll have a look at it when I get some time. About to attach a v5 just in case anyone else needs it. Should I also attach it to the new bug report?
https://bugs.winehq.org/show_bug.cgi?id=40828
Hamish Claxton hamishclaxton@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #63178|0 |1 is obsolete| |
--- Comment #31 from Hamish Claxton hamishclaxton@gmail.com --- Created attachment 63218 --> https://bugs.winehq.org/attachment.cgi?id=63218 systray: Hide systray for fullscreen games
v5: Simplified & removed some repetition Renamed handle_systray to handle_systray_visibility Added additional comments
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #32 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Hamish Claxton from comment #30)
Okay cool, I'll have a look at it when I get some time. About to attach a v5 just in case anyone else needs it. Should I also attach it to the new bug report?
It is enough to attach it here.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #33 from Hamish Claxton hamishclaxton@gmail.com --- How does one go about signing off on a patch in upstream? New to this and can't figure it out.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #34 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Hamish Claxton from comment #33)
How does one go about signing off on a patch in upstream? New to this and can't figure it out.
There is a small paragraph about it in this Wiki topic:
https://wiki.winehq.org/Submitting_Patches#Coauthored_patches
--- From the Wiki --- Both reviewers and coauthors indicate approval of a patch by sending a Signed-off-by line to the wine-devel mailing list. For example:
From: Nikolay Sivov nsivov@example.net To: wine-devel@winehq.org Subject: Re: gdiplus: Avoid calling GdipFillPath() with an empty path.
Signed-off-by: Nikolay Sivov nsivov@example.net --- From the Wiki ---
The easiest way is to open the mail you received from the wine-devel mailing list for the patch you want to sign, and reply with a body consisting of a single Signed-off-by line with your name/email.
If you lost the original wine-devel mail you may retrieve the subject line from the archives : https://www.winehq.org/pipermail/wine-devel/ Then you just have to send a new email with subject 'Re: ' followed by the original subject, and the Signed-off-by line in the body.
The mailing list should automatically recognize the subject line and join the Signed-off-by line to the proper patch.
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #35 from Hamish Claxton hamishclaxton@gmail.com --- (In reply to Olivier F. R. Dierick from comment #34)
Thanks, I just signed off on your patch in upstream, hopefully I did it right this time. Not sure why the second tick doesn't come up though.
https://bugs.winehq.org/show_bug.cgi?id=40828
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=40828
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |5afd80307ed2487998c0ccd552f | |883560ac24cfd
--- Comment #36 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Should be fixed by commit 5afd80307ed2487998c0ccd552f883560ac24cfd
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #37 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Hamish Claxton from comment #35)
(In reply to Olivier F. R. Dierick from comment #34)
Thanks, I just signed off on your patch in upstream, hopefully I did it right this time. Not sure why the second tick doesn't come up though.
You did right. I guess the second tick comes only when signed-off-by privileged reviewers.
https://source.winehq.org/git/wine.git/commit/5afd80307ed2487998c0ccd552f883...
https://bugs.winehq.org/show_bug.cgi?id=40828
--- Comment #38 from Alexandre Julliard julliard@winehq.org --- (In reply to Olivier F. R. Dierick from comment #37)
(In reply to Hamish Claxton from comment #35)
(In reply to Olivier F. R. Dierick from comment #34)
Thanks, I just signed off on your patch in upstream, hopefully I did it right this time. Not sure why the second tick doesn't come up though.
You did right. I guess the second tick comes only when signed-off-by privileged reviewers.
No, but it needs to be sent as a proper reply to the initial patch, not as a new mail. Otherwise the tracker doesn't know which patch it refers to.
https://bugs.winehq.org/show_bug.cgi?id=40828
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #39 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.0-rc6.
https://bugs.winehq.org/show_bug.cgi?id=40828
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |3.0.x
https://bugs.winehq.org/show_bug.cgi?id=40828
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|3.0.x |---
--- Comment #40 from Michael Stefaniuc mstefani@winehq.org --- Removing the 3.0.x milestone from bug fixes included in 3.0.5.
-
wine-bugs＠winehq.org