[Bug 59976] New: Maximized windows cover the taskbar when using virtual desktop (explorer /desktop=shell)
http://bugs.winehq.org/show_bug.cgi?id=59976 Bug ID: 59976 Summary: Maximized windows cover the taskbar when using virtual desktop (explorer /desktop=shell) Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs Assignee: wine-bugs@list.winehq.org Reporter: ajf@ajf.me Target Milestone: --- Distribution: --- Created attachment 81374 --> http://bugs.winehq.org/attachment.cgi?id=81374 explorer /desktop=shell,640x480 with maximized Notepad window (taskbar can't be seen because it is covered by the maximized window) With an invocation like `wine explorer /desktop=shell,640x480`, WINE will open a virtual desktop with a taskbar provided by explorer.exe. If I launch a program in this environment, for example notepad.exe, it covers the entire desktop *including* the taskbar, meaning that the taskbar becomes hidden and therefore inaccessible. This is not what you would expect. This happens with WINE 10.0 stable, WINE 11.0 stable, and the latest WINE master. I haven't tested any other versions. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #1 from Andrea Faulds <ajf@ajf.me> --- Created attachment 81375 --> http://bugs.winehq.org/attachment.cgi?id=81375 Reference for what a non-maximized window looks like in the same environment -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #2 from Andrea Faulds <ajf@ajf.me> --- I intend to investigate this and try to patch it myself. I assume SHAppBarMessage() or something related to it will be involved. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Severity|normal |trivial Status|UNCONFIRMED |NEW Keywords| |download, source --- Comment #3 from Ken Sharp <imwellcushtymelike@gmail.com> --- Confirming with Wine 11.12. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #4 from Andrea Faulds <ajf@ajf.me> --- I wrote a test application that uses SHAppBarMessage() and tested it on Windows 2000. On that OS: - An appbar registered with SHAppBarMessage() does indeed get an area of the screen reserved to it, such that maximized windows won't cover it, and you can't move the window cursor over it when dragging or resizing a window. The registration also makes existing windows, maximized or otherwise, move out of the way, including by resizing if necessary. - If explorer.exe is not running, registering an appbar doesn't do anything, and so the area of the screen isn't reserved and you can maximize over it. - When explorer.exe is killed, the appbar and taskbar areas of the screen stay reserved (maximizing won't cover them), even if there is no longer be anything in them. - When explorer.exe is killed, the existing appbar registrations are apparently forgotten, because when explorer.exe is restarted, currently maximized windows get resized over the appbar (but not the taskbar of course). Based on these findings, I hypothesize that Windows's explorer.exe: 1) operates some kind of server to register appbars and respond to queries 2) in response to appbar registration, updates some kind of global state that lives outside the process which specifies what part of the screen applications can use (the SPI_GETWORKAREA rect?) 3) in response to appbar registration, triggers resizing and movement to ensure open windows remain within that part of the screen I see that WINE's explorer.exe already does (1) in appbar.c, but I see no sign that it tries to do (2) or (3). So I guess those are the missing pieces here. I suspect there is no public Win32 API for doing (2) in particular. But it seems doable. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #5 from Andrea Faulds <ajf@ajf.me> --- Ah, the WINE taskbar is implemented in systray.c, and appbar.c doesn't interact with it at all; ABM_GETTASKBARPOS is a stub that pretends the taskbar is one pixel high! As for how to set SPI_GETWORKAREA, I somehow missed there is simply SPI_SETWORKAREA. But hacking in an appropriate call to that doesn't seem to do anything. So there's two directions for work. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #6 from Andrea Faulds <ajf@ajf.me> --- Created attachment 81515 --> http://bugs.winehq.org/attachment.cgi?id=81515 Test program for SPI_GETWORKAREA/SPI_SETWORKAREA -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #7 from Andrea Faulds <ajf@ajf.me> --- I wrote a little test program to see how SPI_GETWORKAREA and SPI_SETWORKAREA behave. As I was hoping, on Windows 2000, changing the work area does indeed change what part of the screen the application can cover. I could also see that, on Windows 2000, this is a global parameter that automatically affects all other applications (the last parameter to SystemParametersInfo doesn't seem to be relevant). In WINE, I was able to trivially modify get_maximized_rect() to return the work area retrieved by SPI_GETWORKAREA. With that, my test app could affect how far it could be maximized. However, there doesn't seem to be anything to propagate that changed work area to other WINE processes. So I think the minimal set of pieces now is this: - Make explorer.exe do SPI_SETWORKAREA (and make it aware of its own taskbar) - Make get_maximized_rect() use SPI_GETWORKAREA or equivalent - Make SPI_SETWORKAREA and SPI_SETWORKAREA communicate with wineserver so that all processes are aware of work area changes -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #8 from Andrea Faulds <ajf@ajf.me> --- The behaviour when resizing/moving windows with the cursor might be something ClipCursor() could be used for. But that'd be a sidequest. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59976 --- Comment #9 from Andrea Faulds <ajf@ajf.me> --- https://gitlab.winehq.org/wine/wine/-/merge_requests/11699 is my attempt to fix this. -- 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)
-
WineHQ Bugzilla