February 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] oleaut32/tests: Test for VariantClear() on VT_RECORD variant

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=5035 Your paranoid android. === wvistau64 (64 bit vartest) === No test summary line found === w2008s64 (64 bit vartest) === No test summary line found === w7pro64 (64 bit vartest) === No test summary line found

Feb. 20, 2014

Re: msi: Dont crash on installation of services without component KeyPath

by Francois Gouget

On Thu, 20 Feb 2014, Aric Stewart wrote: [...] > Unfortunately it only tries to install the service on windows 2000 or > older. (this is an old applications that I was installing in a windows > 2000 prefix) I do not have a windows 2000 machine to test the install > on. You're in luck then. The new testbot now has a Windows 2000 VM... -- Francois Gouget <fgouget(a)codeweavers.com>

Feb. 20, 2014

Re: [1/2] shell32: Correct create flags when SEE_MASK_NO_CONSOLE isn't specified (resend)

by Alistair Leslie-Hughes

Hi Alexandre, On 20/02/2014 3:31 AM, Alexandre Julliard wrote: > There's more to it than that, now it's popping up consoles all over the > place during make test. > When I ran the test on windows consoles popup all over the place so how is it different to WINE? Are the consoles not closing? Best Regards Alistair Leslie-Hughes

Feb. 20, 2014

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries

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=5034 Your paranoid android. === build (build) === Patch failed to apply

Feb. 20, 2014

Re: (try 3)winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 20, 2014, at 12:28 AM, Aric Stewart wrote: > --- > dlls/winemac.drv/ime.c | 15 +++++---------- > 1 file changed, 5 insertions(+), 10 deletions(-) Looks good to me. -Ken

Feb. 20, 2014

Re: (resend)winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 14:22, Ken Thomases wrote: > On Feb 19, 2014, at 11:19 PM, Aric Stewart wrote: > >> On 2014/02/20 14:14, Ken Thomases wrote: >>> On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: >>> >>>> + gti.rcCaret.right = gti.rcCaret.left + 1; >>> >>> Out of curiosity, was there a problem with leaving the rectangle with its original width? I wonder if, for an input method operating in right-to-left mode, it would be good to have the right edge of the caret rect so the candidate window can be aligned underneath it. (Presumably, the input method would take care of that automatically, as it just thinks of this rect as the character rect and, for right-to-left input, the right edge would be the beginning.) >>> >>> Otherwise, this looks good to me. >>> >> No strong reason other than to have a known width, as the mac at least appears to center the candidate window above/below the point. >> >> I can leave the returned width if you feel that to be better. > > Do you have the ability to test an input method with right-to-left input with an app that's known to use this code path? Also, have you inspected the caret width to know if it's supplying a sensible width? I have failed to find a right-to-left input method that makes use of the candidate window stuff. So I have not been able to investigate that. The caret window size does appear to be pretty logical. (always about 1 pixel but still logical) I was just not relying on it, mostly because of the comment in the MSDN page that made me worry that it could potentially be an invalid rect (right side less than left) in some cases. But rereading it I do not thing that is what is being implied. I also never saw that to be the case. -aric

Feb. 20, 2014

Re: (resend)winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 11:19 PM, Aric Stewart wrote: > On 2014/02/20 14:14, Ken Thomases wrote: >> On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: >> >>> + gti.rcCaret.right = gti.rcCaret.left + 1; >> >> Out of curiosity, was there a problem with leaving the rectangle with its original width? I wonder if, for an input method operating in right-to-left mode, it would be good to have the right edge of the caret rect so the candidate window can be aligned underneath it. (Presumably, the input method would take care of that automatically, as it just thinks of this rect as the character rect and, for right-to-left input, the right edge would be the beginning.) >> >> Otherwise, this looks good to me. >> > No strong reason other than to have a known width, as the mac at least appears to center the candidate window above/below the point. > > I can leave the returned width if you feel that to be better. Do you have the ability to test an input method with right-to-left input with an app that's known to use this code path? Also, have you inspected the caret width to know if it's supplying a sensible width? -Ken

Feb. 20, 2014

Re: (resend)winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 14:14, Ken Thomases wrote: > On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: > >> + gti.rcCaret.right = gti.rcCaret.left + 1; > > Out of curiosity, was there a problem with leaving the rectangle with its original width? I wonder if, for an input method operating in right-to-left mode, it would be good to have the right edge of the caret rect so the candidate window can be aligned underneath it. (Presumably, the input method would take care of that automatically, as it just thinks of this rect as the character rect and, for right-to-left input, the right edge would be the beginning.) > > Otherwise, this looks good to me. > No strong reason other than to have a known width, as the mac at least appears to center the candidate window above/below the point. I can leave the returned width if you feel that to be better. -aric

Feb. 20, 2014

Re: (resend)winemac.drv: Improve positioning of IME client window based on caret

by Ken Thomases

On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: > + gti.rcCaret.right = gti.rcCaret.left + 1; Out of curiosity, was there a problem with leaving the rectangle with its original width? I wonder if, for an input method operating in right-to-left mode, it would be good to have the right edge of the caret rect so the candidate window can be aligned underneath it. (Presumably, the input method would take care of that automatically, as it just thinks of this rect as the character rect and, for right-to-left input, the right edge would be the beginning.) Otherwise, this looks good to me. -Ken

Feb. 20, 2014

Re: winemac.drv: Improve positioning of IME client window based on caret

by Aric Stewart

On 2014/02/20 12:12, Ken Thomases wrote: > On Feb 19, 2014, at 9:00 PM, Aric Stewart wrote: > >> GetGUIThreadInfo is totally the correct way to go. It is giving me correct caret rects for both notepad and the Japanese applications I am trying to fix. I can worry less about the not about caret insertion points because i do not care about the width, just the height and position. so a width of 1 is fine. > > Well the note wasn't about the caret width, it was about the proper computation of the left edge. According to MSDN, rcCaret.left is not correct as given. As I said, though, I'm not sure Wine is doing the right thing with that, anyway. The problem may only show up with right-to-left or Thai input. *shrug* > True, but I am not really worried about the insertion point to that degree of accuracy. Just the location of the cursor itself and the height. Both of which appear to be correct. Thanks for the tip on this. -aric

Feb. 20, 2014