October 2013 - Wine-Devel - list.winehq.org

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Ken Thomases

On Oct 21, 2013, at 4:23 AM, Phil Krylov wrote: > On Mon, Oct 21, 2013 at 6:47 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > >> Does the attached patch help? > > Yes it does, thanks! Although the menu still blinks momentarily when I > release Command. I have submitted a tweaked version of that patch which should avoid that flicker. http://source.winehq.org/patches/data/99962 Cheers, Ken

Oct. 24, 2013

Re: [PATCH 2/6] user32: Implement OpenInputDesktop.

by Qian Hong

Hello, Thanks again for the advice. > Probably you could simply return the desktop of the current thread. Simply returning the desktop of current thread breaks one existent test, I adjust the idea to return the desktop of 'current process'. A new version is sent, I appreciate for the review!

Oct. 23, 2013

Re: [PATCH 2/2] user32: Implement OpenInputDesktop.

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://newtestbot.winehq.org/JobDetails.pl?Key=2978 Your paranoid android. === build (build) === Patch failed to apply

Oct. 23, 2013

Re: [PATCH 2/6] user32: Implement OpenInputDesktop.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > Hello, > > On Wed, Oct 23, 2013 at 11:11 PM, Alexandre Julliard > <julliard(a)winehq.org> wrote: >> >> I don't think that makes sense, under Wine every desktop is potentially >> an input desktop, there's no way to decide which one is the "real" one. > > Thanks a lot for reviewing! > I'm not sure I understand what you expect, I attach a draft version > similar to patch 99498 with some improvements, could you have a look? > If that's not what you expect, could you advice a bit more details > what's the preferred way to improve OpenInputDesktop rather than a > stub? Probably you could simply return the desktop of the current thread. -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2013

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Qian Hong

Hello, On Wed, Oct 23, 2013 at 1:51 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > It looks like that these new winstation tests now leave a reference to > a wineserver object which makes wineserver stay in memory after the tests > have finished. Please fix. Thanks for comment, I noticed this as well, it is an existing Wine bug discovered by my test, I have a comment regarding this bug in my [patch 4/6], I'll try to fix Wine rather than my test. -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 23, 2013

Re: [PATCH 2/6] user32: Implement OpenInputDesktop.

by Qian Hong

Hello, On Wed, Oct 23, 2013 at 11:11 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > I don't think that makes sense, under Wine every desktop is potentially > an input desktop, there's no way to decide which one is the "real" one. Thanks a lot for reviewing! I'm not sure I understand what you expect, I attach a draft version similar to patch 99498 with some improvements, could you have a look? If that's not what you expect, could you advice a bit more details what's the preferred way to improve OpenInputDesktop rather than a stub? Thanks again. -- Regards, Qian Hong - http://www.codeweavers.com

Oct. 23, 2013

Re: server: Add support for pending write flag to the serial device. Take 2.

by Wolfgang Walter

Am Mittwoch, 23. Oktober 2013, 20:44:28 schrieben Sie: > Wolfgang Walter <wine(a)stwm.de> wrote: > > I have no intention to discuss that all again. Please think about the > > problem. Hint: writing twice as many bytes with 150 baud needs more time, > > significantly more time then TIMEOUT. > > Not really. Francois sent an investigation with pretty exhaustive > explanation of the behvaiour of COM-port UARTs regarding timings and baud > rates. Have you read it? It says that with a standard UART windows may signals after 872ms that the tx queue is empty (though there are still 4 bytes to send) when you write 17 bytes. For 34 bytes he gets 1802ms > TIMEOUT. Here Francois' mesurements for windows: ================================== On my one Windows PC with a real UART (Intel(R) 82801DBM LPC Interface Controller - 24CC, i.e. ICH4 which emulates a 16550A UART) I get the following results which clearly illustrate the impact of the FIFO/trigger level. comm.c:1100: WaitCommEvent(1 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(2 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(3 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(4 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(5 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(6 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(7 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(8 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(9 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(10 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(11 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(12 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(13 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(14 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(15 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(16 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(17 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(18 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(19 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(20 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(21 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(22 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(23 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(24 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(25 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(26 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(27 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(28 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(29 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(30 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(31 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(32 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(33 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(34 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(35 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(36 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(37 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(38 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(39 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(40 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(41 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(42 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(43 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(44 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(45 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(46 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(47 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(48 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(49 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(50 bytes) for EV_TXEMPTY took 2734 ms ================================= And I really don't think that we can expect exactly that same behaviour when using the linux serial driver, anyway. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts

Oct. 23, 2013

Re: [PATCH 2/6] user32: Implement OpenInputDesktop.

by Alexandre Julliard

Qian Hong <qhong(a)codeweavers.com> writes: > Hello, > > This patch superseded patch 99498. > Thanks Vincent Povirk for the previous comment, now I try to implement > OpenInputDesktop in user32 and server. I don't think that makes sense, under Wine every desktop is potentially an input desktop, there's no way to decide which one is the "real" one. -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2013

Re: ole32: Support activation context in CLSIDFromProgID()

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > Support activation context in CLSIDFromProgID() It breaks the tests: ../../../tools/runtest -q -P wine -T ../../.. -M msi.dll -p msi_test.exe.so msi.c && touch msi.ok msi.c:1974: Test failed: expected 0xdeadbeef, got 14007 msi.c:1981: Test failed: expected 0xdeadbeef, got 14007 msi.c:1988: Test failed: expected 0xdeadbeef, got 14007 msi.c:2003: Test failed: expected 0xdeadbeef, got 14007 msi.c:2506: Test failed: expected 0xdeadbeef, got 14007 msi.c:2515: Test failed: expected 0xdeadbeef, got 14007 make: *** [msi.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2013

Re: [PATCH 3/3] ddraw/tests: Test DDSCAPS2_D3DTEXTUREMANAGE.

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://newtestbot.winehq.org/JobDetails.pl?Key=2973 Your paranoid android. === w864 (32 bit ddraw7) === No test summary line found Failure running script in VM: network read timed out === w864 (64 bit ddraw7) === ddraw7.c:3695: Test failed: Got unexpected, hr 0x80004002, case 4. ddraw7.c:3695: Test failed: Got unexpected, hr 0x80004002, case 5. ddraw7.c:3695: Test failed: Got unexpected, hr 0x80004002, case 6. ddraw7.c:3695: Test failed: Got unexpected, hr 0x80004002, case 7. === w864 (32 bit ddraw4) === The test timed out

Oct. 23, 2013