September 2015 - Wine-Devel

Re: rsaenh/tests: Adjust length value to pass on Win 10 (try 2) (resend)

by Marvin

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=16918 Your paranoid android. === w1064 (32 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020 === w1064 (64 bit rsaenh) === rsaenh.c:2804: Test failed: 80090020

Sept. 30, 2015

libosmesa bitness

by André Hentschel

Hi, Does someone can tell which version of libosmesa Wine needs? You can build libosmesa for 8, 16 or 32 channel bits puk suspects we need the 42 bits version ;) 8 is the default and it seems to me we want that, so can someone confirm that?

Sept. 30, 2015

Re: [PATCH] usp10/tests: fix some tests on Hebrew and Arabic locales

by Marvin

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=16916 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1244: Test failed: 0: uJustification incorrect (0) usp10.c:1244: Test failed: 1: uJustification incorrect (0) usp10.c:1244: Test failed: 2: uJustification incorrect (0) usp10.c:1244: Test failed: 3: uJustification incorrect (0) usp10.c:1244: Test failed: 4: uJustification incorrect (0) usp10.c:1244: Test failed: 5: uJustification incorrect (0) usp10.c:1244: Test failed: 6: uJustification incorrect (0) usp10.c:1244: Test failed: 7: uJustification incorrect (0) usp10.c:1244: Test failed: 8: uJustification incorrect (0) usp10.c:1244: Test failed: 9: uJustification incorrect (0) usp10.c:1260: Test failed: 3: uJustification incorrect (0) usp10.c:1260: Test failed: 5: fDiacritic incorrect (1) usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1260: Test failed: 15: fDiacritic incorrect (1) usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)

Sept. 30, 2015

Re: [PATCH] secur32/tests: handle skip cleanup in negotiate more cleanly

by Aric Stewart

On 9/30/15 11:07 AM, Nikolay Sivov wrote: > On 30.09.2015 19:04, Aric Stewart wrote: >> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> --- >> dlls/secur32/tests/negotiate.c | 31 +++++++++++++++++++++++-------- >> 1 file changed, 23 insertions(+), 8 deletions(-) >> > > >> - status_c = pDeleteSecurityContext( &client.ctxt ); >> - ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); >> + if (client.ctxt.dwLower || client.ctxt.dwUpper) >> + { >> + status_c = pDeleteSecurityContext( &client.ctxt ); >> + ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); >> + } > > Why is this a problem only on macos? > > No idea, Again I was trying to turn a crash into a cleaner failure. -aric

Sept. 30, 2015

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder

by Aric Stewart

On 9/30/15 11:08 AM, Vincent Povirk wrote: >> If this is about fixing macos failures, Vincent pointed out that there was a >> decision at some point to fix broken builds and not to workaround that in >> test code. > > AFAICT this patch won't actually prevent failures, just skip later > tests after the failure so they don't crash. > > Correct. I am leaving in the failures because I agree they are important. I just want to have it register as a failure and not as a crash. -aric

Sept. 30, 2015

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder

by Vincent Povirk

> If this is about fixing macos failures, Vincent pointed out that there was a > decision at some point to fix broken builds and not to workaround that in > test code. AFAICT this patch won't actually prevent failures, just skip later tests after the failure so they don't crash.

Sept. 30, 2015

Re: [PATCH] secur32/tests: handle skip cleanup in negotiate more cleanly

by Nikolay Sivov

On 30.09.2015 19:04, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/secur32/tests/negotiate.c | 31 +++++++++++++++++++++++-------- > 1 file changed, 23 insertions(+), 8 deletions(-) > > - status_c = pDeleteSecurityContext( &client.ctxt ); > - ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); > + if (client.ctxt.dwLower || client.ctxt.dwUpper) > + { > + status_c = pDeleteSecurityContext( &client.ctxt ); > + ok( status_c == SEC_E_OK, "DeleteSecurityContext returned %08x\n", status_c ); > + } Why is this a problem only on macos?

Sept. 30, 2015

Re: [PATCH] windowscodecs/tests: handle failure to create png decoder

by Nikolay Sivov

On 30.09.2015 18:54, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/windowscodecs/tests/pngformat.c | 4 ++++ > 1 file changed, 4 insertions(+) > If this is about fixing macos failures, Vincent pointed out that there was a decision at some point to fix broken builds and not to workaround that in test code.

Sept. 30, 2015

Re: [2/2 v3] winex11.drv: Implement FlashWindow with _NET_WM_STATE_DEMANDS_ATTENTION.

by Ken Thomases

Hi, On Sep 30, 2015, at 9:04 AM, Jactry Zeng <jactry92(a)gmail.com> wrote: > 2015-09-30 17:05 GMT+08:00 Ken Thomases <ken(a)codeweavers.com>: > >> Since FlashWindowEx() is the more general function — that is, FlashWindow() could be fully implemented in terms of FlashWindowEx(), but not the other way around — shouldn't the driver entry point be FlashWindowEx()? Otherwise, when FlashWindowEx() is eventually implemented more completely, the driver entry will have to be changed. >> >> For now, since user32 implements FlashWindow() but FlashWindowEx() is a stub (or semi-stub after your next patch), FlashWindow() would have to create a FLASHWINFO structure, fill it in, and pass that along. I think that dwFlags would be either FLASHW_ALL or FLASHW_STOP, depending on bInvert. uCount would be 1, I guess. > Thanks for your review! You're welcome! > Yes, function() will be implemented by functionEx() commonly in Wine. > But I didn't find a perfect way to implement FlashWindowEx() and then implement FlashWindow() with FlashWindowEx(). I wasn't suggesting that you necessarily implement FlashWindow() in terms of FlashWindowEx(). Just that you model the driver entry function after FlashWindowEx() instead of FlashWindow(). If the driver doesn't implement the full semantics of FlashWindowEx(), that's OK. It's no worse than the semi-stub that FlashWindowEx() will be. > Because in X11, how many times will the window be flashed is depend on design of window manager/desktop environment.(For example, in XFCE, taskbar will always flashes when _NET_WM_STATE_DEMANDS_ATTENTION is sent until the user active the window again; In Ubuntu Unity, it'll only be flashed one time and then highlight taskbar until the user active the window again.) And I don't think it's necessary (and any possible?) to follow Window's design. > In this way, implementing uCount and other parameters may be useless, because all we need to do is sending _NET_WM_STATE_DEMANDS_ATTENTION to WM/DE one time when FlashWindow()/FlashWindowEx() is called. > > Similarly, Windows's FlashWindowEx() can decide which part it want to flash - only flash taskbar or only flash > caption or flash both. But it'll depend on WM/DE's design in X11. It's OK for the driver to implement just that subset of the functionality it's able to. It's not OK for the interface of the driver to prevent the implementation of the full functionality. Don't forget, there are other drivers than X11. The Mac driver may have greater flexibility to more fully implement the functionality (or it may have less). But if the entry point doesn't provide the information, there's no chance for it to do as much as it can. > So I implemented FlashWindowEx() by calling FlashWindow() simply. Again, the way the two functions are implemented at the user32 level is a different question than what the driver interface is. >> Why does FlashWindow() only call the driver entry point if the window is minimized? Shouldn't the driver get the opportunity to act for a non-minimized window, too? > > Same as above, different WM/DE may have different UI effect, that makes it hard to follow Windows's design. > In Windows, different UI effects will be showed when window is minimized and non-minimized. > And in my opinion, it is a little noisy if USER_Driver->pFlashWindow( hWnd, bInvert ) is called all the time. > So I'll prefer to only let the user notice new message when the window is minimized (it may hard to be noticed when > it's minimized). I have the same objection as above. The driver interface should not be designed based on the capabilities of one specific driver (or things like WM/DE behavior, which are specific to that driver). It has to be general enough for any driver. The choices about what the driver actually does should be left to the driver, not user32. You're making choices which unnecessarily limit what the driver can choose. -Ken

Sept. 30, 2015

Re: Videos or Slides from WineConf

by Jactry Zeng

2015-09-30 21:59 GMT+08:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > > Here they are: > > Alexandre: https://www.youtube.com/watch?v=GTN5ksxzFnE > Jeremy: https://www.youtube.com/watch?v=EzR9RPlWi7c > Michael: https://www.youtube.com/watch?v=QdcFNqWTja4 Cool! Thanks for your work! :) -- Regards, Jactry Zeng

Sept. 30, 2015