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

Re: richedit: Documented paragraph border widths are in points not pixels.

by Dylan Smith

On Sun, Feb 28, 2010 at 3:16 PM, Andrew Eikum <andrew(a)brightnightgames.com> wrote: > I'd be very surprised if git is modifying your patches without telling you. > It's probably Gmail trying to be clever. Telling git-imap-send to send as > an attachment (--attach) might fix the issue. Or, if you're already doing > that, maybe turning it off would fix it ;) I always use --attach because gmail will word wrap to ~80 characters for plain text email. I believe you are probably right about this being a gmail rather than git issue, since I get the same problem trying to send upload drafts through thunderbird, or send emails through alpine using gmail's imap and smtp servers. Conversely I am able to send emails without line ending conversion by manually attaching files through gmail's web interface. I didn't have this issue before when I was using libgmail, but I switched to git imap-send when libgmail was removed from ubuntu's repository. As a result I don't know if gmail's imap/smtp servers just started doing this.

Feb. 28, 2010

Re: [PATCH] winemp3.acm: always dynamically load libmpg123 stuff

by Chris Robinson

On Sunday 28 February 2010 1:13:44 pm Marcus Meissner wrote: > Hi, > > Copy in the mpg123.h header from the library so we do not need it for > building. (it is also LPGL) > > Dynamically link from libmpg123.so.0. > (Chances are very good that ABI stays stable.) > > This allows me providing a MP3 capable Wine build for openSUSE without > actually having libmpg123 in the openSUSE buildservice for building. > > > I was not able to test it though, anyone have a working winemp3.acm > using testcase :( This won't work, unfortunately. The mpg123.h header does some evil macro hacks to forward certain functions (eg. mpg123_seek, mpg123_feedseek) to 64-bit variants when _FILE_OFFSET_BITS is 64 due to using off_t. The functions the lib has depends on whether it was built with _FILE_OFFSET_BITS=64 or not, and the macros won't affect the strings passed to wine_dlsym. It also looks like the lib isn't unloaded with the acm.

Feb. 28, 2010

Re: [PATCH] msxml3/tests: Fix the domdoc IObjectSafety tests for msxml3 SP8+. [try 2]

by Reece Dunn

On 28 February 2010 19:11, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > On 02/26/2010 11:07 PM, Reece Dunn wrote: >> >> + todo_wine >> + ok(broken(supported == (INTERFACESAFE_FOR_UNTRUSTED_CALLER | >> INTERFACESAFE_FOR_UNTRUSTED_DATA)) || >> + supported == (INTERFACESAFE_FOR_UNTRUSTED_CALLER | >> INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER) /* >> msxml3 SP8+ */, >> + "Expected (INTERFACESAFE_FOR_UNTRUSTED_CALLER | >> INTERFACESAFE_FOR_UNTRUSTED_DATA) " >> + "or (INTERFACESAFE_FOR_UNTRUSTED_CALLER | >> INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER), " > > Hi Reece, > > We usually don't add the broken() possibility as one of the expected > outcomes in the ok-message. I have applied your comment to the tests I have been working on and submitting that as the fix for the failing tests, as I have reworked the tests to extend the coverage. Thanks, - Reece

Feb. 28, 2010

Re: richedit: Documented paragraph border widths are in points not pixels.

by Hin-Tak Leung

--- On Sun, 28/2/10, Andrew Eikum <andrew(a)brightnightgames.com> wrote: > I'd be very surprised if git is modifying your patches > without telling you. It's probably Gmail trying to be > clever. Telling git-imap-send to send as an attachment > (--attach) might fix the issue. Or, if you're already > doing that, maybe turning it off would fix it ;) I don't know how others use gmail - but I have had problems using patches coming out of 'Save as' from gmail's web front end with that sort of problem (and the same patch e-mail arriving at my other imap/pop3 account doing okay), until I found the 'show original' tab under gmail's menu selections. Also, there is an -l option for GNU patch to cope with extra white spaces.

Feb. 28, 2010

Re: richedit: Documented paragraph border widths are in points not pixels.

by Andrew Eikum

On 02/28/2010 02:01 PM, Dylan Smith wrote: > I have been using git imap-send to upload the patch from gmail's draft > folder so that I could send manually after looking over everything, > but all the text piped into git imap-send has unix line endings. I am > not sure if gmail is changing the line endings on me, or if git > imap-send is changing line endings when I upload the patch. Either way > Julliard must have managed to deal with this since the last patches > that I sent were sent in the same way. > I'd be very surprised if git is modifying your patches without telling you. It's probably Gmail trying to be clever. Telling git-imap-send to send as an attachment (--attach) might fix the issue. Or, if you're already doing that, maybe turning it off would fix it ;) git-apply can be configured to automatically fix whitespace errors, which is probably what Julliard is using. Andrew

Feb. 28, 2010

Re: richedit: Documented paragraph border widths are in points not pixels.

by Dylan Smith

On Sun, Feb 28, 2010 at 1:09 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > > git apply complains about whitespace errors: > 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:10: > trailing whitespace. > int ME_GetParaBorderWidth(ME_Context *c, int flags); > 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:35: > trailing whitespace. > /* The documented widths are in points (72 dpi), but converting them to > 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:36: > trailing whitespace. > * 96 dpi (standard display resolution) avoids dealing with fractions. */ > 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:37: > trailing whitespace. > static const struct {unsigned width : 8, pen_style : 4, dble : 1;} > border_details[] = { > 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:38: > trailing whitespace. > /* none */ {0, PS_SOLID, FALSE}, > error: patch failed: dlls/riched20/editor.h:229 > error: dlls/riched20/editor.h: patch does not apply > error: patch failed: dlls/riched20/paint.c:461 > error: dlls/riched20/paint.c: patch does not apply > error: patch failed: dlls/riched20/wrap.c:522 > error: dlls/riched20/wrap.c: patch does not apply > That is weird. It seems like there are dos line ending ("\r\n") in the patch when I download it from gmail, but when I save the patch through alpine it has unix file endings ("\n"). I have been using git imap-send to upload the patch from gmail's draft folder so that I could send manually after looking over everything, but all the text piped into git imap-send has unix line endings. I am not sure if gmail is changing the line endings on me, or if git imap-send is changing line endings when I upload the patch. Either way Julliard must have managed to deal with this since the last patches that I sent were sent in the same way. Has anyone else been having the same problems? $ git --version git version 1.6.3.3 I am using Ubuntu's git package that I recompiled with ssl support for git imap-send (see Ubuntu bug #432786 https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/432786)

Feb. 28, 2010

Re: [PATCH] msxml3/tests: Fix the domdoc IObjectSafety tests for msxml3 SP8+. [try 2]

by Paul Vriens

On 02/26/2010 11:07 PM, Reece Dunn wrote: > + todo_wine > + ok(broken(supported == (INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA)) || > + supported == (INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER) /* msxml3 SP8+ */, > + "Expected (INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA) " > + "or (INTERFACESAFE_FOR_UNTRUSTED_CALLER | INTERFACESAFE_FOR_UNTRUSTED_DATA | INTERFACE_USES_SECURITY_MANAGER), " Hi Reece, We usually don't add the broken() possibility as one of the expected outcomes in the ok-message. -- Cheers, Paul.

Feb. 28, 2010

Re: [PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.

by James McKenzie

Erich Hoover wrote: > On Thu, Feb 25, 2010 at 5:38 AM, <Joerg-Cyril.Hoehle(a)t-systems.com > <mailto:Joerg-Cyril.Hoehle(a)t-systems.com>> wrote: > > Charles Davis wrote: > > >I have noticed a change in configure behavior, though. > Me too. On MacOS. > Since 1.1.39, Makefiles are created at the rate of ~ 1 per sec. > It was much faster in 1.1.38 and before, I estimate ~6 files per > second. > > Anyone to confirm this? > > ... > > > Is this a reply to a different thread? > Should be. My mistake by replying to it. James McKenzie

Feb. 28, 2010

Re: richedit: Make zooming affect all pictures.

by James McKenzie

Dylan Smith wrote: > Before pictures that had an ole object size were not zoomed. Native > riched20 applies the zoom ratio to these images, so this patch adds this > consistency. > --- > dlls/riched20/richole.c | 65 ++++++++++++++++++++++------------------------ > 1 files changed, 31 insertions(+), 34 deletions(-) > > ------------------------------------------------------------------------ > > This patch does not apply either. 0002-richedit-Make-zooming-affect-all-pictures.patch:9: trailing whitespace. if (c->editor->nZoomNumerator != 0) 0002-richedit-Make-zooming-affect-all-pictures.patch:10: trailing whitespace. { 0002-richedit-Make-zooming-affect-all-pictures.patch:11: trailing whitespace. pSize->cx = MulDiv(pSize->cx, c->editor->nZoomNumerator, c->editor->nZoomDenominator); 0002-richedit-Make-zooming-affect-all-pictures.patch:12: trailing whitespace. pSize->cy = MulDiv(pSize->cy, c->editor->nZoomNumerator, c->editor->nZoomDenominator); 0002-richedit-Make-zooming-affect-all-pictures.patch:13: trailing whitespace. } error: patch failed: dlls/riched20/richole.c:1729 error: dlls/riched20/richole.c: patch does not apply James McKenzie

Feb. 28, 2010

Re: richedit: Documented paragraph border widths are in points not pixels.

by James McKenzie

Dylan Smith wrote: > The border widths documented by msdn are in points which are 72 dpi, which > is not equivalent to pixels (normally 96 dpi). I pre-converted all the > border widths to 96 dpi resolution since this avoids needed to store > fractions, and often avoids the need for convertion to the displays > resolution. > --- > dlls/riched20/editor.h | 2 +- > dlls/riched20/paint.c | 57 ++++++++++++++++++++++------------------------- > dlls/riched20/wrap.c | 2 +- > 3 files changed, 29 insertions(+), 32 deletions(-) > > ------------------------------------------------------------------------ > > Dylan: git apply complains about whitespace errors: 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:10: trailing whitespace. int ME_GetParaBorderWidth(ME_Context *c, int flags); 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:35: trailing whitespace. /* The documented widths are in points (72 dpi), but converting them to 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:36: trailing whitespace. * 96 dpi (standard display resolution) avoids dealing with fractions. */ 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:37: trailing whitespace. static const struct {unsigned width : 8, pen_style : 4, dble : 1;} border_details[] = { 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:38: trailing whitespace. /* none */ {0, PS_SOLID, FALSE}, error: patch failed: dlls/riched20/editor.h:229 error: dlls/riched20/editor.h: patch does not apply error: patch failed: dlls/riched20/paint.c:461 error: dlls/riched20/paint.c: patch does not apply error: patch failed: dlls/riched20/wrap.c:522 error: dlls/riched20/wrap.c: patch does not apply Current git as of this morning. James McKenzie

Feb. 28, 2010