On 2/14/19 6:01 PM, Zebediah Figura wrote:
On 2/14/19 4:25 AM, Gabriel Ivăncescu wrote:
On 2/14/19 6:17 AM, Zebediah Figura wrote:
On 2/13/19 2:16 PM, Alexandre Julliard wrote:
Zebediah Figura z.figura12@gmail.com writes:
On 2/10/19 1:39 PM, Marvin wrote:
Hi,
While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=47392
Your paranoid android.
=== wvistau64 (32 bit report) ===
user32: win.c:10796: Test failed: got minimized pos (0,713) win.c:10808: Test failed: got minimized pos (0,713) win.c:10820: Test failed: got minimized pos (0,713) win.c:10833: Test failed: got minimized pos (0,713) win.c:10846: Test failed: got minimized pos (0,713) win.c:10859: Test failed: got minimized pos (0,713) win.c:10872: Test failed: got minimized pos (0,713) win.c:10906: Test failed: got minimized pos (100,100) win.c:10928: Test failed: got minimized pos (100,100)
*snip*
This fails because test_shell_window(), which is pretty pathological, kills explorer.exe, and that doesn't restart itself until the test program terminates. What can be done about this, if anything?
The obvious fix is to run your test before the one that kills the shell window. Though if the behavior depends on having a shell window, it may be interesting to test both cases.
Thanks. I guess I wasn't sure if that was an acceptable solution.
I guess the behaviour here makes sense—if there's no shell window, there won't be a taskbar, and so windows would have no way of being restored if they're minimized offscreen. But I'm also not sure it's something that there's any point replicating in Wine (either windows are offscreen anyway due to WM integration, or explorer.exe is necessary to run the virtual desktop), so I'll leave off testing this, unless you think it'd be better to do so.
Hi Zeb,
Just wondering, could this (missing) behavior have something to do with https://bugs.winehq.org/show_bug.cgi?id=15346
It's not immediately evident to me why it would, I guess? Does the program call SetShellWindow()?
It calls SetWindowPos when it's being moved, however, the problem is that somehow it ends up snapped to negative coordinate (e.g. -width of window) when moved to the edge (it "snaps" to the edge on either side).
X11 driver code then unmaps this window because it's "out of screen", so it disappears. My workaround patch in that bug report queries the X11 server for the actual position because the WM will deny the negative placement, and it seems to work. However I'm not certain it's the proper solution because I think the negative placement shouldn't happen in the first place. No idea why it does.
But it probably has nothing to do with it as you said, I didn't look into it so I assumed it had something to do with WM integration, because you mentioned it. But nevermind, thanks for the answer. :-)