- wine-devel - winehq.org

Re: Major mmdevapi and winmm audio bugs
by Joerg-Cyril.Hoehle＠t-systems.com 01 Mar '12

01 Mar '12

Maarten Lankhorst wrote: >I think the key is to use accurate periods and report GetStreamLatency correctly. You mentioned GSL in the past already, and I think it makes sense to return real values instead of native's 10.6667 that I don't trust, however I expect nothing from setting it: http://bugs.winehq.org/show_bug.cgi?id=28723#c23 "It looks like XA2 doesn't calls it at all." >Or never use anything but dmix/real hardware with winealsa Well, there's bug #28781 and #29294 from the Jack users :-) I've ran some numeric simulations tonight and am beginning to see some light with an ALSA design that meets all my design goals but one: + arbitrarily large ALSA buffer that would avoid underruns if Linux has other stuff to do for 100ms if the feeder supplies enough data (e.g. winmm would typically be safe, XAudio2 will lose out). + variable latency (conceivably user settable via registry) aka. "hidden frames" + accommodates crazy irregular wake-ups + exhibits very regular period-size decrease of padding + self-correcting timer and adaption to clock skew - alas, needs a wake-up even without EVENTCALLBACK Regards, Jörg

1 0

Re: gdiplus: Create GDI brush only when needed. Take 2.
by Vincent Povirk 01 Mar '12

01 Mar '12

I don't think this is a good idea during code freeze.

1 0

bugzilla: show the component, not "comp" and not the assignee
by Joerg-Cyril.Hoehle＠t-systems.com 01 Mar '12

01 Mar '12

Hi, Somehow I discovered that bugzilla can display the component in a search result list. Now I'm using that instead of the useless "assignee" field. Here's part of the URL I'm using: &columnlist=bug_severity%2Cop_sys%2Ccomponent%2Cbug_status%2Cshort_desc& Unfortunately, the column named "Comp" only holds 8 characters, causing ugly names like: directx- : you don't know which one out of ten directx-YZ winmm&mc : one missing letter looks rather stupid It would be nice if some bugzilla admin would enlarge that column BTW, I recently suggested replacing the mostly useless "assignee" column in the default search result list by the component. No answer. What do you think? Thank you, Jörg Höhle

2 1

Debugging WINE 1.3.24 with GDB
by louis＠museresearch.com 29 Feb '12

29 Feb '12

Hi All, I've been attempting to debug a WINElib application on Fedora 15 (WINE 1.3.24) and not having much success. Winedbg works, but using gdb I'm not able to see symbols or multiple threads. In Fedora 8, running GDB on wine-pthreads (and not wine!) used to work under 1.1.7. However, under 1.3.24 there's no wine-pthreads. I've also tried attaching to various threads after the program was running with little success. I'm also not having any success using "winedbg --gdb"-- the same thing happens there as if I'd run it using just gdb (strange). The big picture is that I'd like to get an IDE such as QtCreator or KDevelop to work debugging a WINE application. Any way that is possible would be a good solution for me; it doesn't necessarily have to be through GDB if there's another way. Thanks for your help in advance! -Louis

1 0

Re: po: Spanish translation update for cmd.rc (almost complete)
by Eduardo García 29 Feb '12

29 Feb '12

Sorry, attached the wrong patch, this one is the correct one. With regards. Eduardo. El 02/29/12 21:00, Eduardo García escribió: > This one was fun to do as I fouund a couple of "my hovercraft is full > of eels" phrases. > > With regards. > > Eduardo. > > > > >

1 0

Re: po: Spanish translation update for cmd.rc (almost complete)
by Eduardo García 29 Feb '12

29 Feb '12

Sorry, attached the wrong patch, this one is the correct. With regards. Eduardo. El 02/29/12 21:00, Eduardo García escribió: > This one was fun to do as I fouund a couple of "my hovercraft is full > of eels" phrases. > > > > > > >

1 0

Re: Fix references to the LGPL
by Alexandre Julliard 29 Feb '12

29 Feb '12

Francois Gouget <fgouget(a)free.fr> writes: > So the problem is that start.rc (it's always about start) > contains slightly incorrect references to the LGPL in its license > message (no less): I would say we should get rid of that license message. No other Wine command-line app does this, and we have the license in the about box already for graphical apps. This would also avoid the need for a different usage message in cmd. -- Alexandre Julliard julliard(a)winehq.org

1 0

Major mmdevapi and winmm audio bugs
by Joerg-Cyril.Hoehle＠t-systems.com 29 Feb '12

29 Feb '12

Hi, instead of Wine Weekly News (WWN, any taker?) you get monthly audio news. The surprising thing is: it looks like most audio bugs remaining in bugzilla are from the pre-mmdevapi era and have not been updated since mid-2011. - Using devices other than "default" (dmix or pulse): #29294 no sound with ALSA loopback -- are they duplicates of each other #28781 loopback to Jack -- or is one about DSound only? We have are several issues about crackling sound: - One definitely is caused by CreateTimerQueue which is not regular enough or does not deliver 10ms, but 12ms callbacks. This is in #28723 which includes a work-around in comment #130 That may affect the Solaris machine on test.winehq.org too. - One is caused by a mmdevapi design error: the audio buffer we use is simply too small, and Linux can't bear a regular 10ms rate. Things got worse since the introduction of the Completely Fair Scheduler. It can't even guarantee a regular 50ms one. There's a need for a much larger buffer. That's why wine < 1.3.25 is giving steadier sound. #29531 may be caused by this. - Mac OS X 10.5.8 crackles constantly with dlls/mmdevapi/tests/render I'd like somebody with 10.6 or .7 to perform the interactive test. rm -f render.ok; WINETEST_INTERACTIVE=1 make render.ok - Lastly, there's PulseAudio #28856 among others I don't understand why I couldn't find bugs in PA's bugzilla, so I wrote some: - https://bugs.freedesktop.org/show_bug.cgi?id=46296 About the need to restart the PA server from time to time - https://bugs.freedesktop.org/show_bug.cgi?id=46297 PA's huge buffering causes issues with winmm - https://bugs.freedesktop.org/show_bug.cgi?id=46412 How to obtain PA's typical 44100 rate? Feel free to contribute if you know apps outside Wine with similar issues. Surprisingly, users have reported improvements in the latest wine-1.4rcX even when nothing changed, but also mentioned updates on the PA and alsa_plugins side. Perhaps that improved the situation. I was pleased to see Wine's testsuite help find bugs in Pulse: http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-February/0128… There are issues not always associated with a bug entry: - #29472 comment #12 DSound GetDevicePosition is not how it should be - Check OSS4 with and without vmix #28056 #28790 - winmm handling huge latency (such as PA's) & when to send notifications - Issues with microphone capture? - DSound mixing and buffer sizes & padding vs. GetPosition - Deal with intermittent errors from ALSA etc. in mmdevapi, winmm and dsound - Device enumeration and PA preventing access to the underlying device Is this known to cause no sound in an app (or only in our wave tests?) - various missing trailing sound with DSound #21209 - #29369 strange issue involving PA and perhaps messaging - misc. losing sound: #28319 #25164 #28770 - lead-out needed with dmix - Use lock-less design to reduce contention, cf. #29531, comment #7 - multi-channel, 5:1 etc. in mmdevapi and DSound - Bugs in the quartz or winegstreamer area that I don't have on my radar Of course there are more bugs than this. Regards, Jörg Höhle

6 11

Re: gdiplus: Create a GDI brush only when needed.
by Vincent Povirk 29 Feb '12

29 Feb '12

This won't work. We create gdi32 brushes for hatch brushes based on temporary bitmaps that won't exist at the time brush_fill_path is called. On Wed, Feb 15, 2012 at 2:44 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > This patch fixes the problem reported in the bug 29894. > --- > dlls/gdiplus/brush.c | 19 ------------------- > dlls/gdiplus/gdiplus_private.h | 1 - > dlls/gdiplus/graphics.c | 13 ++++++++++++- > 3 files changed, 12 insertions(+), 21 deletions(-) > > diff --git a/dlls/gdiplus/brush.c b/dlls/gdiplus/brush.c > index d1af903..e0c400e 100644 > --- a/dlls/gdiplus/brush.c > +++ b/dlls/gdiplus/brush.c > @@ -55,7 +55,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > > memcpy(*clone, brush, sizeof(GpSolidFill)); > > - (*clone)->gdibrush = CreateBrushIndirect(&(*clone)->lb); > fill->bmp = ARGB2BMP(fill->color); > break; > } > @@ -123,8 +122,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > > memcpy(dest, src, sizeof(GpLineGradient)); > > - dest->brush.gdibrush = CreateSolidBrush(dest->brush.lb.lbColor); > - > count = dest->blendcount; > dest->blendfac = GdipAlloc(count * sizeof(REAL)); > dest->blendpos = GdipAlloc(count * sizeof(REAL)); > @@ -142,7 +139,6 @@ GpStatus WINGDIPAPI GdipCloneBrush(GpBrush *brush, GpBrush **clone) > GdipFree(dest->blendpos); > GdipFree(dest->pblendcolor); > GdipFree(dest->pblendpos); > - DeleteObject(dest->brush.gdibrush); > GdipFree(dest); > return OutOfMemory; > } > @@ -295,7 +291,6 @@ GpStatus WINGDIPAPI GdipCreateHatchBrush(HatchStyle hatchstyle, ARGB forecol, AR > (*brush)->brush.lb.lbStyle = BS_PATTERN; > (*brush)->brush.lb.lbColor = 0; > (*brush)->brush.lb.lbHatch = (ULONG_PTR)hbmp; > - (*brush)->brush.gdibrush = CreateBrushIndirect(&(*brush)->brush.lb); > > DeleteObject(hbmp); > } > @@ -307,7 +302,6 @@ GpStatus WINGDIPAPI GdipCreateHatchBrush(HatchStyle hatchstyle, ARGB forecol, AR > (*brush)->brush.lb.lbStyle = BS_SOLID; > (*brush)->brush.lb.lbColor = fgcol; > (*brush)->brush.lb.lbHatch = 0; > - (*brush)->brush.gdibrush = CreateBrushIndirect(&(*brush)->brush.lb); > } > > if (stat == Ok) > @@ -351,7 +345,6 @@ GpStatus WINGDIPAPI GdipCreateLineBrush(GDIPCONST GpPointF* startpoint, > (*line)->brush.lb.lbStyle = BS_SOLID; > (*line)->brush.lb.lbColor = col; > (*line)->brush.lb.lbHatch = 0; > - (*line)->brush.gdibrush = CreateSolidBrush(col); > (*line)->brush.bt = BrushTypeLinearGradient; > > (*line)->startpoint.X = startpoint->X; > @@ -387,7 +380,6 @@ GpStatus WINGDIPAPI GdipCreateLineBrush(GDIPCONST GpPointF* startpoint, > { > GdipFree((*line)->blendfac); > GdipFree((*line)->blendpos); > - DeleteObject((*line)->brush.gdibrush); > GdipFree(*line); > *line = NULL; > return OutOfMemory; > @@ -624,7 +616,6 @@ GpStatus WINGDIPAPI GdipCreatePathGradient(GDIPCONST GpPointF* points, > (*grad)->brush.lb.lbColor = col; > (*grad)->brush.lb.lbHatch = 0; > > - (*grad)->brush.gdibrush = CreateSolidBrush(col); > (*grad)->brush.bt = BrushTypePathGradient; > (*grad)->centercolor = 0xffffffff; > (*grad)->wrap = wrap; > @@ -719,7 +710,6 @@ GpStatus WINGDIPAPI GdipCreatePathGradientFromPath(GDIPCONST GpPath* path, > (*grad)->brush.lb.lbColor = col; > (*grad)->brush.lb.lbHatch = 0; > > - (*grad)->brush.gdibrush = CreateSolidBrush(col); > (*grad)->brush.bt = BrushTypePathGradient; > (*grad)->centercolor = 0xffffffff; > (*grad)->wrap = WrapModeClamp; > @@ -753,7 +743,6 @@ GpStatus WINGDIPAPI GdipCreateSolidFill(ARGB color, GpSolidFill **sf) > (*sf)->brush.lb.lbColor = col; > (*sf)->brush.lb.lbHatch = 0; > > - (*sf)->brush.gdibrush = CreateSolidBrush(col); > (*sf)->brush.bt = BrushTypeSolidColor; > (*sf)->color = color; > (*sf)->bmp = ARGB2BMP(color); > @@ -898,7 +887,6 @@ GpStatus WINGDIPAPI GdipCreateTextureIA(GpImage *image, > (*texture)->brush.lb.lbColor = 0; > (*texture)->brush.lb.lbHatch = (ULONG_PTR)hbm; > > - (*texture)->brush.gdibrush = CreateBrushIndirect(&(*texture)->brush.lb); > (*texture)->brush.bt = BrushTypeTextureFill; > (*texture)->image = new_image; > > @@ -1036,7 +1024,6 @@ GpStatus WINGDIPAPI GdipDeleteBrush(GpBrush *brush) > break; > } > > - DeleteObject(brush->gdibrush); > GdipFree(brush); > > return Ok; > @@ -1578,9 +1565,6 @@ GpStatus WINGDIPAPI GdipSetPathGradientCenterColor(GpPathGradient *grad, > grad->centercolor = argb; > grad->brush.lb.lbColor = ARGB2COLORREF(argb); > > - DeleteObject(grad->brush.gdibrush); > - grad->brush.gdibrush = CreateSolidBrush(grad->brush.lb.lbColor); > - > return Ok; > } > > @@ -1775,9 +1759,6 @@ GpStatus WINGDIPAPI GdipSetSolidFillColor(GpSolidFill *sf, ARGB argb) > sf->color = argb; > sf->brush.lb.lbColor = ARGB2COLORREF(argb); > > - DeleteObject(sf->brush.gdibrush); > - sf->brush.gdibrush = CreateSolidBrush(sf->brush.lb.lbColor); > - > return Ok; > } > > diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h > index 9afe15b..b597511 100644 > --- a/dlls/gdiplus/gdiplus_private.h > +++ b/dlls/gdiplus/gdiplus_private.h > @@ -170,7 +170,6 @@ struct GpGraphics{ > }; > > struct GpBrush{ > - HBRUSH gdibrush; > GpBrushType bt; > LOGBRUSH lb; > }; > diff --git a/dlls/gdiplus/graphics.c b/dlls/gdiplus/graphics.c > index 65a3815..35aa504 100644 > --- a/dlls/gdiplus/graphics.c > +++ b/dlls/gdiplus/graphics.c > @@ -723,10 +723,21 @@ static void brush_fill_path(GpGraphics *graphics, GpBrush* brush) > /* else fall through */ > } > default: > - SelectObject(graphics->hdc, brush->gdibrush); > + { > + HBRUSH gdibrush, old_brush; > + > + if (brush->lb.lbStyle == BS_SOLID) > + gdibrush = CreateSolidBrush(brush->lb.lbColor); > + else > + gdibrush = CreateBrushIndirect(&brush->lb); > + > + old_brush = SelectObject(graphics->hdc, gdibrush); > FillPath(graphics->hdc); > + SelectObject(graphics->hdc, old_brush); > + DeleteObject(gdibrush); > break; > } > + } > } > > static INT brush_can_fill_pixels(GpBrush *brush) > -- > 1.7.8.4 > > >

2 3

Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)
by Henri Verbeet 29 Feb '12

29 Feb '12

On 29 February 2012 11:12, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > try 2: Invalidate the index buffer state as well, as the buffer might be > an index buffer. > > Otherwise unmodified reesend after the discussion from yesterday. This > is for bugs 29079, 29897(suspected) and 30019. > I guess I didn't explicitly say it yesterday, but I think this should be deferred and fixed properly after 1.4. While in principle dropping VBOs might be ok as a temporary fix for the release, the vertex / index buffer code is pretty fragile in general, and I can't guarantee that this won't introduce more regressions than it fixes.

2 2

Re: [PATCH] winepulse: Add pulse driver, v8
by Chris Robinson 29 Feb '12

29 Feb '12

On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote: > + * This is basically the same as the pa_threaded_mainloop implementation, > + * but that cannot be used because it uses pthread_create directly > + * > + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock > + * pa_threaded_mainloop_signal -> pthread_cond_signal > + * pa_threaded_mainloop_wait -> pthread_cond_wait I'm curious why you're using pthreads. Doesn't WinAPI have anything comparable to pthread_cond_wait? > +static void pulse_probe_settings(void) { ... > + ret = pa_stream_connect_playback(stream, NULL, &attr, > + PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_FORMAT|PA_S > TREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS, NULL, NULL); Is it necessary to fix the format? MSDN says that the audio service always works with floating-point, and GetMixFormat always specified floating-point in my dealings with it. I don't think it should blindly return whatever PulseAudio does, unless it can be shown that Windows doesn't always give floating-point. > +static WAVEFORMATEX *clone_format(const WAVEFORMATEX *fmt) > +{ > + WAVEFORMATEX *ret; > + size_t size; > + > + if (fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > + size = sizeof(WAVEFORMATEXTENSIBLE); > + else > + size = sizeof(WAVEFORMATEX); > + > + ret = HeapAlloc(GetProcessHeap(), 0, size); This should probably use CoTaskMemAlloc, as it's used for IsFormatSupported. I'm also curious if IsFormatSupported should always return a WAVE_FORMAT_EXTENSIBLE object. > +static enum pa_channel_position pulse_map[] = { This should probably be const. > + if (fmt->wFormatTag == WAVE_FORMAT_IEEE_FLOAT) > + This->ss.format = PA_SAMPLE_FLOAT32LE; ... > + if (IsEqualGUID(&wfe->SubFormat, &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)) > + This->ss.format = PA_SAMPLE_FLOAT32LE; You likely should check that the format specifies 32 bits, and not 64 or something different like that. This isn't an all-inclusive lookover, just some things that caught my eye. Also, does this driver fail to load if it can't connect to a pulse server?

3 2

RFT: Use Greek semicolons for comdlg32's printer status enumeration?
by Francois Gouget 29 Feb '12

29 Feb '12

Request For Translators<g> So what I've gathered from Wikipedia is that the Greek language does not use semicolons as a separator for enumerations: http://en.wikipedia.org/wiki/Semicolon#Greek_and_Church_Slavonic | In Greek and Church Slavonic, a semicolon indicates a question, | similar to a Latin question mark.[2] To indicate a long pause or | separate sections, each with commas (the semicolon's purpose in | English), Greek uses an ano teleia ( · ). Wine uses semicolons as a separator in one place, for comdlg32's printer status enumeration. It's a list of status indicators separated by semicolons and looks like this: Error; Paper jam; or Initialising; Default Printer; I/O Active; So I would expect the Greek translation to use ano teleia characters as the separator but instead it uses plain semicolons: msgid "Paused; " msgstr "Σταματημένος; " msgid "Error; " msgstr "Σφάλμα; " msgid "Busy; " msgstr "Απασχολημένος; " So I'm hoping some Greek-speaking Wine hacker or user can enlighten me on the following points: * Did I understand Wikipedia wrong? Do both English semicolons and question marks translate to a semicolon in Greek? * Is this a special case that justifies not following the standard rule? If so why? * Does the attached patch replacing semicolons with ano teleia characters make sense? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

2 3

Remove an obsolete string chunk fom the Swedish translation?
by Francois Gouget 29 Feb '12

29 Feb '12

This translation seems to have an extra example which is not present in the English string. Would it be ok to remove it? msgid "" "MOVE relocates a file or directory to a new point within the file system.\n" "\n" "If the item being moved is a directory then all the files and " "subdirectories\n" "below the item are moved as well.\n" "\n" "MOVE fails if the old and new locations are on different DOS drive letters.\n" msgstr "" "MOVE flyttar en fil eller mapp till ett nytt ställe inom filsystemet.\n" "\n" "Om du flyttar på en mapp, så flyttas allting under mappen med.\n" "\n" "MOVE misslyckas om den gamla och det den nya stället är på olika\n" "DOS-enhetsbokstäver. Till exempel från C: till D:.\n" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

1 0

Re: doc: Update Italian README
by Frédéric Delanoy 29 Feb '12

29 Feb '12

2012/2/28 Luca Bennati <lucak3(a)gmail.com>: > I tried converting README.it to UTF8, instead of the current Extended ASCII, > which works really bad on my system. > However, it does not seems like Git caught this change: could this be done > manually? I applied the patch manually and it seems the conversion went fine. Maybe there were some accentuated letters already. (hint: 'iconv' can be useful for those kind of conversions, or a save with your favorite editor) BTW, -6. ESEGUIRE I PROGRAMMI +6. RUNNING PROGRAMS seems wrong... Frédéric

2 1

Re: [PATCH] winepulse: Add pulse driver, v8
by Dmitry Timoshkov 28 Feb '12

28 Feb '12

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > Date: Thu, 28 Apr 2011 09:45:18 +0200 > Subject: [PATCH 10/10] winepulse: Add pulse driver, v8 You forgot to fix the date, 1 Apr would be more appropriate I'd guess. -- Dmitry.

2 1

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic
by Henri Verbeet 28 Feb '12

28 Feb '12

On 28 February 2012 12:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is for bug 30019. > > Out ddraw.dll forwards DDLOCK_DISCARDCONTENTS and DDLOCK_NOOVERWRITE to > wined3d, but wined3d ignores those flags because we never set > WINED3DUSAGE_DYNAMIC. D3d7 docs refer to D3DVBCAPS_WRITEONLY as the flag > to set when creating a buffer, so translate it to DYNAMIC | WRITEONLY. > > An argument could be made that we should set the DYNAMIC flag on all > d3d7 buffers, but until I see a game that needs it I prefer to keep > non-D3DVBCAPS_WRITEONLY buffers regular buffers. I don't see why WRITEONLY should imply DYNAMIC. Setting it for all ddraw buffers may make sense, but even then I'd like to hear a somewhat more convincing argument that now is the right time to change this.

2 3

Re: [PATCH 2/4] wined3d: Do not use double-buffered dynamic buffers
by Henri Verbeet 28 Feb '12

28 Feb '12

On 28 February 2012 12:19, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This is for bug 30019. > > They are a lot slower than using no VBO at all in at least some, if not all > games. The reason for the slowdown is the memcpy call, not the buffer > map. I don't find this all that convincing either. My impression is that the reason we have these kinds of problems is mostly that the buffer conversion code is broken. I don't think there are legitimate cases where not creating a VBO should improve performance.

2 3

Re: A small cs.po file update
by Francois Gouget 28 Feb '12

28 Feb '12

On Mon, 27 Feb 2012, David wrote: > Hello. > > There is attached a small cs.po update. Gzipped. Generated using > winepo. More is coming. I am planning to update it all. Last will be > translation of certificates/encryption strings. Thanks for the translation update. Unfortunately the tool you used to edit the PO file converted all the line ends from LF to CR+LF. The resulting diff was not so small as it contained the whole file twice. I have cleaned it up and rediffed it for this time (and I'll try to modify winepo to detect this). Some notes about the patch: -#, fuzzy msgid "&Modify..." msgstr "Z&měnit" msgid "&Install" -msgstr "&Instalovat" +msgstr "Na&instalovat..." The ellipses don't match here. Ellipses are very important because, for instance, they make all the difference between a 'Print' button that will send the page to the default printer right away, and a 'Print...' button that will first display a dialog that will let you choose the destination printer or cancel before anything happens. These look like th eonly two issues so things are looking pretty good. msgid "" "Is '%1' a filename or directory\n" "on the target?\n" "(F - File, D - Directory)\n" msgstr "" "Je '%1' název souboru nebo adresáře\n" "v cíli?\n" "(F - Soubor, D - Adresář)\n" It would probably be more intuitive for users if you change the 'shortcut keys': "(S - Soubor, A - Adresář)\n" And then modify the two other corresponding translations: msgctxt "File key" msgid "F" msgstr "S" msgctxt "Directory key" msgid "D" msgstr "A" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A black hole is just God dividing by zero.

1 0

Re: po: zh_TW translation updates
by Francois Gouget 28 Feb '12

28 Feb '12

On Mon, 27 Feb 2012, Hin-Tak Leung wrote: [...] > - some of the changes are over-eager: i.e. it "improves" on windows > and tried to be more user-friendly, but not exactly how windows does > it. > > I think there should be a notes on the translation FAQ: one is not > looking to be "better than" windows, but bug-for-bug-compatible. > Therefore translation is preferably what regional/localized windows > (whatever version) does. > > 20% of the world's population is Chinese, I am sure it is easy enough > to do a few screenshots of localized windows (be in traditional or > simplied) and show how those behave. > > There is a definitive answer (or "definition answers") to most of > these translation strings: what localized windows (some version) does. > It is not up to individual or group opinions, really. I mean, public > libraries, etc have windows in the far east, there is no excuse to be > wrong, or on the opposite extreme, "try to improve on windows", even > if one does not want to get one's hand dirty and own a windows box. The dialog labels and error messages are an area where we don't need to and don't want to be word for word identical to Windows. We should definitely follow the Windows User Experience Interaction Guidelines: http://msdn.microsoft.com/en-us/library/aa511258.aspx The Windows GUI is certainly be a valuable resource to determine which terms the users are going to be familiar with (e.g. will they more readily understand 'directory' or 'folder'). That said Wine runs on Linux and Mac OS X so Wine's users will likely be somewhat accustomed to the terms used by these platforms too. But in any case blindly copying all the strings from the Windows GUI would be a very bad idea. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ $live{free} || die "";

2 2

Translators wanted!
by Francois Gouget 28 Feb '12

28 Feb '12

I feel that we should put out a call for translators to the wider community. In preparation for that I updated the Wiki's Translating page and added a winepo script to help translators who don't want to check out the whole Wine source: http://wiki.winehq.org/Translating Here's the proposed news message for the website: > Translators wanted! > > Wine is looking for translators for the 1.4 release! > > Wine's translation <a href="http://fgouget.free.fr/wine-po/">status > page</a> shows only 12 complete translations. We'd like to do better > for 1.4. > > Luckily, starting with 1.4 Wine uses PO files, thus making > translations easier than ever before. So check out how to <a > href="http://wiki.winehq.org/Translating">get started</a> and help us > make Wine usable in your country. And here is the proposed wine-users message: > Wine 1.4 is making good progress. Unfortunately we still have a lot of > translations that are quite incomplete and have no active translators, > thus making Wine unusable in many countries. You track progress on > this page: > > http://fgouget.free.fr/wine-po/ > > As you can see we currently have 12 pretty complete translations and 5 > others that are advanced too. But that still leaves 25 languages > without much, not counting those that are not in the list. This page > also lists some suspected issues that would make easy targets for a > translator short on time. > > The good news is that Wine now uses standard PO files for localization > which makes translation easier than ever before. You even get to > choose between working straight on Wine's source or just editing the > one PO file for your language. So check out the instructions below and > make Wine usable for users in your country! > > http://wiki.winehq.org/Translating Of course if you can help translating Wine, you can also consider this your call to action<g>. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

12 29

Re: po: zh_TW translation updates
by Franklin Weng 28 Feb '12

28 Feb '12

Hi, I rechecked the translation with old zh_TW.po file. I used Kompare and picked the better one for each entry. I hope that the new patch file is okay and acceptable. I'll post the new patch again later. BTW, the Chinese name (used in Taiwan) of Free Software Foundation is "自由軟體基金會", that's correct. Thanks, Franklin 2012/2/27 Hin-Tak Leung <hintak_leung(a)yahoo.co.uk>: > --- On Mon, 27/2/12, Francois Gouget <fgouget(a)free.fr> wrote: > >> Patches are posted to wine-patches(a)winehq.org: >> http://www.winehq.org/pipermail/wine-patches/2012-February/111804.html > > A quick look at it (it is a few hundred k) - says a few of the problems I saw and suspected: > > - some of the changes are not improvements/corrections but just opinionated changes > > - some changes are wrong (i.e. the older version is more correct/natural and the change makes it worse, not better). > > - some of the changes are over-eager: i.e. it "improves" on windows and tried to be more user-friendly, but not exactly how windows does it. > > I think there should be a notes on the translation FAQ: one is not looking to be "better than" windows, but bug-for-bug-compatible. Therefore translation is preferably what regional/localized windows (whatever version) does. > > 20% of the world's population is Chinese, I am sure it is easy enough to do a few screenshots of localized windows (be in traditional or simplied) and show how those behave. > > There is a definitive answer (or "definition answers") to most of these translation strings: what localized windows (some version) does. It is not up to individual or group opinions, really. I mean, public libraries, etc have windows in the far east, there is no excuse to be wrong, or on the opposite extreme, "try to improve on windows", even if one does not want to get one's hand dirty and own a windows box. > > > >

1 0

Re: msvcrt/file.c: file mode T (temporary file) (try 3)
by Frédéric Delanoy 28 Feb '12

28 Feb '12

On Mon, Feb 27, 2012 at 11:23, Robert van Herk <mijnspamboxje(a)hotmail.com> wrote: >> So what actually prevents you from properly implementing this? Especially >> that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY >> >> Vitaliy. > > I wrote a new version that maps > 'D' -> MSVCRT__O_TEMPORARY, and > 'T' -> MSVCRT__O_SHORT_LIVED | MSVCRT__O_TEMPORARY > > I deliberately included MSVCRT__O_TEMPORARY in 'T': on Windows, when a file > is opened in 'T' mode, a subsequent call to GetFileAttributes(tempfile) show > that the FILE_ATTRIBUTE_TEMPORARY flag is set, so this seemed like to most > sensible thing to do. > > I updated the conformance test such that it checks that the file is actually > deleted after fclose. > > Kind regards, > Robert van Herk You may already be aware of this, but you can request a testbot account to check your patches before submission to wine-patches. See http://testbot.winehq.org/ Frédéric

1 0

Re: Testbot and changes to multiple tests
by Joerg-Cyril.Hoehle＠t-systems.com 27 Feb '12

27 Feb '12

Stefan Dösinger wrote: >When I manually submit a patch to the Wine testbot, it refuses to test it if >the patch changes multiple tests. I know that and live with it as follows: - I usually keep changes to separate tests as distinct commits in my git, so I can send them separately to testbot. I merge them just prior to submission to wine-patches. - Alternatively, I edit the patch file in an editor and change it so that only one test file is modified, then edit again, saving the second test. >Why are they refused when I submit them via the testbot web interface? Perhaps to keep the web interface clean? (e.g. page 3 where it's asking you for the command line arguments) Regards, Jörg Höhle

1 0

Re: po: zh_TW translation updates
by Francois Gouget 27 Feb '12

27 Feb '12

It's great seeing lots of progress being made on the Taiwanese translation. There are a few changes that look a bit strange to me though: msgid "Theme files (*.msstyles; *.theme)" -msgstr "�Ѿ��}�n�� (*.msstyles��*.theme)" +msgstr "�Ѿ��}�n�� (*.msstyles; *.theme)" msgid "TypeLib files (*.tlb; *.olb; *.dll; *.ocx; *.exe)" -msgstr "TypeLib �n�� (*.tlb��*.olb��*.dll��*.ocx��*.exe)" +msgstr "TypeLib �n�� (*.tlb;*.olb;*.dll;*.ocx;*.exe)" So half width semicolons seem to be preferred to full width ones which is fine to me. But in the first patch it's followed by a space, like in English, and not in the second one which seems inconsistent. msgid "Wine Programs (*.exe; *.exe.so)" -msgstr "Wine ��ʽ (*.exe��*.exe.so)" +msgstr "Wine ��ʽ (*.exe,*.exe.so)" Here the semicolon was replaced by a comma (and no space), which is probably wrong. msgid "Programs (*.exe)" -msgstr "��ʽ (*.exe)" +msgstr "��ʽ(*.exe) " The previous changes all preserved the space before the opening parenthesis. If I add the fact that this introduces a space after the closing parenthesis I'd guess this was unintentional. msgid "Printer files (*.prn)" -msgstr "��ӡ�n�� (*.prn)" +msgstr "��ӡ�n�� (*.PRN)" All other strings of this type use lower case for the extension so I'm not sure about this change. +#, fuzzy msgid "The device door is open.\n" -msgstr "" +msgstr "ӡ��C�w�Ǵ��_��; ��\n" +#, fuzzy msgid "Connection unavailable.\n" -msgstr "" +msgstr "��; ��\n" The combination of the semicolon and full width full stop seems wrong. I suspect the fuzzy translations were from the printer common dialog English strings that ended in a semicolon which escaped removal. msgid "" "This program is free software; you can redistribute it and/or modify it " "under the terms of the GNU Lesser General Public License as published by the " "Free Software Foundation; either version 2.1 of the License, or (at your " "option) any later version." msgstr "" "�@��ʽ��ܛ�w�o��\n" "��ܛ�w�� GNU LGPL 2.1\n" "��°��S�ɗl��޸ĺ��\n" "ɢ��@��ʽ��" This string is not supposed to be explicitly wrapped. Is the wrapping made necessary for Taiwanese because of a Wine bug? msgid "Finished searching the document." -msgstr "�n��ь��Y��" +msgstr "�n��ҽY��." msgid "Failed to load the RichEdit library." -msgstr "RichEdit �d��ʧ��" +msgstr "RichEdit �b�dʧ��." Everywhere else full width full stops are used so this change looks strange to me. msgid "Overwrite %1? (Yes|No|All)\n" -msgstr "" +msgstr "�Ƿ��w %1�� ǣ��ȫ��ǣ�\n" Note that in English the 'Yes' implies one should use the 'Y' key, etc. So this set of strings is tied to the following translations: msgctxt "Yes key" msgid "Y" msgstr "" msgctxt "No key" msgid "N" msgstr "" msgctxt "All key" msgid "A" msgstr "" So depending on the keyboard layout it may be necessary to do something like '��(Y)��(N)��ȫ��(A)��' There's another translation which works the same way, look for "(F - File, D - Directory)" -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

4 5

Re: msvcrt/file.c: file mode T (temporary file) (try 3)
by Marvin 27 Feb '12

27 Feb '12

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 http://testbot.winehq.org/JobDetails.pl?Key=17117 Your paranoid android. === WNT4WSSP6 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2KPROSP4 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === WXPPROSP3 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2K3R2SESP2 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === WVISTAADM (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W2K8SE (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PRO (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PROX64 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === TEST64_W7SP1 (32 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === W7PROX64 (64 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed. === TEST64_W7SP1 (64 bit file) === file.c:464: Test failed: File was opened in 'T' mode, but wasn't deleted when closed.

1 0

Re: ntdll: Fix the file mapping view leak in the case of module loading failure. Take 2.
by Alexandre Julliard 27 Feb '12

27 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -1548,6 +1549,11 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, LPCWSTR name, HANDLE file, > *pwm = wm; > status = STATUS_SUCCESS; > done: > + if (status) > + { > + if (wm) free_modref( wm ); > + else if (module) NtUnmapViewOfSection( NtCurrentProcess(), module ); > + } I don't see any evidence that you are addressing the issues that caused us to not do that in the first place. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: dsound: Small fixes to IDirectSoundCaptureBuffer
by Andrew Eikum 27 Feb '12

27 Feb '12

This patch looks sane and fixes the tests on my machine, but causes no changes to dsound capture behavior in Audacity. I don't have much of an opinion on if it should go in for 1.4. On Tue, Feb 21, 2012 at 05:33:35PM +0100, Maarten Lankhorst wrote: > --- > I suspect a lot more AUDCLNT_E_* calls will have to be mapped > correctly, but at least this is enough to pass the dsound:capture > tests again on wine. > > dlls/dsound/capture.c | 8 +++++--- > dlls/dsound/tests/capture.c | 24 +++++++++++++++--------- > 2 files changed, 20 insertions(+), 12 deletions(-) > > diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c > index 90cddb7..7ceddfc 100644 > --- a/dlls/dsound/capture.c > +++ b/dlls/dsound/capture.c > @@ -456,13 +456,14 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_Start(IDirectSoundCaptureBuf > > EnterCriticalSection(&(This->device->lock)); > > - This->flags = dwFlags; > - TRACE("old This->device->state=%s\n",captureStateString[This->device->state]); > if (This->device->state == STATE_STOPPED) > This->device->state = STATE_STARTING; > else if (This->device->state == STATE_STOPPING) > This->device->state = STATE_CAPTURING; > + else > + goto out; > TRACE("new This->device->state=%s\n",captureStateString[This->device->state]); > + This->flags = dwFlags; > > if (This->device->buffer) > FillMemory(This->device->buffer, This->device->buflen, (This->device->pwfx->wBitsPerSample == 8) ? 128 : 0); > @@ -474,6 +475,7 @@ static HRESULT WINAPI IDirectSoundCaptureBufferImpl_Start(IDirectSoundCaptureBuf > return hres; > } > > +out: > LeaveCriticalSection(&This->device->lock); > > TRACE("returning DS_OK\n"); > @@ -705,7 +707,7 @@ static HRESULT IDirectSoundCaptureBufferImpl_Create( > HeapFree(GetProcessHeap(), 0, This->pdscbd); > This->device->capture_buffer = 0; > HeapFree( GetProcessHeap(), 0, This ); > - return err; > + return err == AUDCLNT_E_UNSUPPORTED_FORMAT ? DSERR_BADFORMAT : err; > } > > err = IAudioClient_GetService(device->client, &IID_IAudioCaptureClient, > diff --git a/dlls/dsound/tests/capture.c b/dlls/dsound/tests/capture.c > index 96fb417..2040f3f 100644 > --- a/dlls/dsound/tests/capture.c > +++ b/dlls/dsound/tests/capture.c > @@ -393,15 +393,18 @@ static void test_capture_buffer(LPDIRECTSOUNDCAPTURE dsco, > ok(ref==0,"IDirectSoundNotify_Release(): has %d references, should have " > "0\n",ref); > > - if (record) { > - rc=IDirectSoundCaptureBuffer_Start(dscbo,DSCBSTART_LOOPING); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > + rc=IDirectSoundCaptureBuffer_Start(dscbo,DSCBSTART_LOOPING); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > + > + rc=IDirectSoundCaptureBuffer_Start(dscbo,0); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Start() failed: %08x\n", rc); > > - rc=IDirectSoundCaptureBuffer_GetStatus(dscbo,&status); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_GetStatus() failed: %08x\n", rc); > - ok(status==(DSCBSTATUS_CAPTURING|DSCBSTATUS_LOOPING), > - "GetStatus: bad status: %x\n",status); > + rc=IDirectSoundCaptureBuffer_GetStatus(dscbo,&status); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_GetStatus() failed: %08x\n", rc); > + ok(status==(DSCBSTATUS_CAPTURING|DSCBSTATUS_LOOPING), > + "GetStatus: bad status: %x\n",status); > > + if (record) { > /* wait for the notifications */ > for (i = 0; i < (NOTIFICATIONS * 2); i++) { > rc=WaitForMultipleObjects(NOTIFICATIONS,state.event,FALSE,3000); > @@ -416,9 +419,12 @@ static void test_capture_buffer(LPDIRECTSOUNDCAPTURE dsco, > break; > } > > - rc=IDirectSoundCaptureBuffer_Stop(dscbo); > - ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > } > + rc=IDirectSoundCaptureBuffer_Stop(dscbo); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > + > + rc=IDirectSoundCaptureBuffer_Stop(dscbo); > + ok(rc==DS_OK,"IDirectSoundCaptureBuffer_Stop() failed: %08x\n", rc); > } > > static BOOL WINAPI dscenum_callback(LPGUID lpGuid, LPCSTR lpcstrDescription, > -- > 1.7.7.6 > > > > >

1 0

Re: ntdll: Fix the file mapping view leak in the case of module loading failure.
by Alexandre Julliard 27 Feb '12

27 Feb '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -1548,6 +1548,8 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, LPCWSTR name, HANDLE file, > *pwm = wm; > status = STATUS_SUCCESS; > done: > + if (status && module) > + NtUnmapViewOfSection( NtCurrentProcess(), module ); It doesn't make sense to free the module as long as we don't free the associated modref. -- Alexandre Julliard julliard(a)winehq.org

1 0

Testbot and changes to multiple tests
by Stefan Dösinger 27 Feb '12

27 Feb '12

Hi, When I manually submit a patch to the Wine testbot, it refuses to test it if the patch changes multiple tests. As a workaround I usually test a precompiled .exe and submit it once for each modified test[1]. In the case of the ddraw patch I sent today this missed test failures in 64 bit ddraw[2]. Apparently patches changing multiple tests work just fine when submitted via wine-patches. Why are they refused when I submit them via the testbot web interface? Cheers, Stefan 1: https://testbot.winehq.org/JobDetails.pl?Key=17113 2: https://testbot.winehq.org/JobDetails.pl?Key=17115

1 0

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests (try 2)
by Stefan Dösinger 27 Feb '12

27 Feb '12

Please ignore this patch for now, it looks like 64 bit ddraw.dll behaves differently. It probably doesn't matter for real games, since they're all 32 bit, but I'll have to investigate this closer. Am Montag, 27. Februar 2012, 12:11:16 schrieb Stefan Dösinger: > This patch is a side product of my attempts to debug bug 21238. It > confirms that the 8 byte aligned pitches are correct for all pools. > > try 2: Don't fail and crash if video memory surfaces are not available > --- > dlls/ddraw/tests/ddraw1.c | 77 ++++++++++++++++++++++++++++++++++++++++++ > dlls/ddraw/tests/ddraw2.c | 81 > ++++++++++++++++++++++++++++++++++++++++++++ dlls/ddraw/tests/ddraw4.c | > 82 +++++++++++++++++++++++++++++++++++++++++++++ dlls/ddraw/tests/ddraw7.c > | 82 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 322 > insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/ddraw1.c b/dlls/ddraw/tests/ddraw1.c > index 5d0d6da..8fa813b 100644 > --- a/dlls/ddraw/tests/ddraw1.c > +++ b/dlls/ddraw/tests/ddraw1.c > @@ -1121,6 +1121,82 @@ static void test_zenable(void) > DestroyWindow(window); > } > > +static void test_pitch_alignment(void) > +{ > + IDirectDraw *ddraw; > + IDirectDrawSurface *surface; > + HRESULT hr; > + static const struct > + { > + DWORD caps; > + UINT align; > + LONG pitch; > + const char *name; > + } > + pools[] = > + { > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, > + 8, 0, "D3DPOOL_DEFAULT" > + }, > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, > + 8, 16, "D3DPOOL_SYSTEMMEM" > + }, > + }; > + unsigned int i; > + DDSURFACEDESC ddsd; > + > + if (!(ddraw = create_ddraw())) > + { > + skip("Failed to create a ddraw object, skipping test.\n"); > + return; > + } > + > + hr = IDirectDraw_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + for (i = 0; i < (sizeof(pools) / sizeof(*pools)); i++) > + { > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > DDSD_PIXELFORMAT; + ddsd.dwWidth = 5; > + ddsd.dwHeight = 5; > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 16; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0xF800; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x07E0; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x001F; > + ddsd.ddsCaps.dwCaps = pools[i].caps; > + > + hr = IDirectDraw_CreateSurface(ddraw, &ddsd, &surface, NULL); > + ok(SUCCEEDED(hr) || hr == DDERR_UNSUPPORTEDFORMAT || hr == > DDERR_NODIRECTDRAWHW, + "%s: Failed to create surface, hr > %#x.\n", pools[i].name, hr); + if (!surface) > + { > + skip("%s: Failed to create surface, skipping pitch alignment > test\n", pools[i].name); + continue; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + hr = IDirectDrawSurface_GetSurfaceDesc(surface, &ddsd); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + > + ok(!(ddsd.lPitch & (pools[i].align - 1)), "%s: Pitch %d is not %u > byte aligned.\n", + pools[i].name, ddsd.lPitch, > pools[i].align); > + if (pools[i].pitch) > + ok(ddsd.lPitch == pools[i].pitch, "%s: Expected pitch %d, got > %d.\n", + pools[i].name, pools[i].pitch, ddsd.lPitch); > + > + IDirectDrawSurface_Release(surface); > + } > + > + IDirectDraw_Release(ddraw); > +} > + > START_TEST(ddraw1) > { > test_coop_level_create_device_window(); > @@ -1130,4 +1206,5 @@ START_TEST(ddraw1) > test_coop_level_threaded(); > test_viewport_interfaces(); > test_zenable(); > + test_pitch_alignment(); > } > diff --git a/dlls/ddraw/tests/ddraw2.c b/dlls/ddraw/tests/ddraw2.c > index ba8d3b6..348cbfc 100644 > --- a/dlls/ddraw/tests/ddraw2.c > +++ b/dlls/ddraw/tests/ddraw2.c > @@ -1383,6 +1383,86 @@ static void test_zenable(void) > DestroyWindow(window); > } > > +static void test_pitch_alignment(void) > +{ > + IDirectDraw2 *ddraw; > + IDirectDrawSurface *surface1; > + IDirectDrawSurface2 *surface; > + HRESULT hr; > + static const struct > + { > + DWORD caps; > + UINT align; > + LONG pitch; > + const char *name; > + } > + pools[] = > + { > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, > + 8, 0, "D3DPOOL_DEFAULT" > + }, > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, > + 8, 16, "D3DPOOL_SYSTEMMEM" > + }, > + }; > + unsigned int i; > + DDSURFACEDESC ddsd; > + > + if (!(ddraw = create_ddraw())) > + { > + skip("Failed to create a ddraw object, skipping test.\n"); > + return; > + } > + > + hr = IDirectDraw2_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + for (i = 0; i < (sizeof(pools) / sizeof(*pools)); i++) > + { > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > DDSD_PIXELFORMAT; + ddsd.dwWidth = 5; > + ddsd.dwHeight = 5; > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 16; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0xF800; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x07E0; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x001F; > + ddsd.ddsCaps.dwCaps = pools[i].caps; > + > + hr = IDirectDraw2_CreateSurface(ddraw, &ddsd, &surface1, NULL); > + ok(SUCCEEDED(hr) || hr == DDERR_UNSUPPORTEDFORMAT || hr == > DDERR_NODIRECTDRAWHW, + "%s: Failed to create surface, hr > %#x.\n", pools[i].name, hr); + if (!surface1) > + { > + skip("%s: Failed to create surface, skipping pitch alignment > test\n", pools[i].name); + continue; > + } > + hr = IDirectDrawSurface_QueryInterface(surface1, > &IID_IDirectDrawSurface2, (void **) &surface); + ok(SUCCEEDED(hr), > "%s: Failed to get DirectDrawSurace2 interface, hr %#x.\n", pools[i].name, > hr); + IDirectDrawSurface_Release(surface1); > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + hr = IDirectDrawSurface2_GetSurfaceDesc(surface, &ddsd); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + > + ok(!(ddsd.lPitch & (pools[i].align - 1)), "%s: Pitch %d is not %u > byte aligned.\n", + pools[i].name, ddsd.lPitch, > pools[i].align); > + if (pools[i].pitch) > + ok(ddsd.lPitch == pools[i].pitch, "%s: Expected pitch %d, got > %d.\n", + pools[i].name, pools[i].pitch, ddsd.lPitch); > + > + IDirectDrawSurface2_Release(surface); > + } > + > + IDirectDraw2_Release(ddraw); > +} > + > START_TEST(ddraw2) > { > test_coop_level_create_device_window(); > @@ -1394,4 +1474,5 @@ START_TEST(ddraw2) > test_texture_load_ckey(); > test_viewport_interfaces(); > test_zenable(); > + test_pitch_alignment(); > } > diff --git a/dlls/ddraw/tests/ddraw4.c b/dlls/ddraw/tests/ddraw4.c > index d9ed90d..c19ba3a 100644 > --- a/dlls/ddraw/tests/ddraw4.c > +++ b/dlls/ddraw/tests/ddraw4.c > @@ -1490,6 +1490,87 @@ static void test_zenable(void) > DestroyWindow(window); > } > > +static void test_pitch_alignment(void) > +{ > + IDirectDraw4 *ddraw; > + IDirectDrawSurface4 *surface; > + HRESULT hr; > + static const struct > + { > + DWORD caps, caps2; > + UINT align; > + LONG pitch; > + const char *name; > + } > + pools[] = > + { > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, 0, > + 8, 0, "D3DPOOL_DEFAULT" > + }, > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, 0, > + 8, 16, "D3DPOOL_SYSTEMMEM" > + }, > + { > + DDSCAPS_TEXTURE, DDSCAPS2_TEXTUREMANAGE, > + 8, 16, "D3DPOOL_MANAGED" > + } > + }; > + unsigned int i; > + DDSURFACEDESC2 ddsd; > + > + if (!(ddraw = create_ddraw())) > + { > + skip("Failed to create a ddraw object, skipping test.\n"); > + return; > + } > + > + hr = IDirectDraw4_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + for (i = 0; i < (sizeof(pools) / sizeof(*pools)); i++) > + { > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > DDSD_PIXELFORMAT; + ddsd.dwWidth = 5; > + ddsd.dwHeight = 5; > + U4(ddsd).ddpfPixelFormat.dwSize = sizeof(U4(ddsd).ddpfPixelFormat); > + U4(ddsd).ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(U4(ddsd).ddpfPixelFormat).dwRGBBitCount = 16; > + U2(U4(ddsd).ddpfPixelFormat).dwRBitMask = 0xF800; > + U3(U4(ddsd).ddpfPixelFormat).dwGBitMask = 0x07E0; > + U4(U4(ddsd).ddpfPixelFormat).dwBBitMask = 0x001F; > + ddsd.ddsCaps.dwCaps = pools[i].caps; > + ddsd.ddsCaps.dwCaps2 = pools[i].caps2; > + > + hr = IDirectDraw4_CreateSurface(ddraw, &ddsd, &surface, NULL); > + ok(SUCCEEDED(hr) || hr == DDERR_UNSUPPORTEDFORMAT || hr == > DDERR_NODIRECTDRAWHW, + "%s: Failed to create surface, hr > %#x.\n", pools[i].name, hr); + if (!surface) > + { > + skip("%s: Failed to create surface, skipping pitch alignment > test\n", pools[i].name); + continue; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + hr = IDirectDrawSurface4_GetSurfaceDesc(surface, &ddsd); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + > + ok(!(ddsd.lPitch & (pools[i].align - 1)), "%s: Pitch %d is not %u > byte aligned.\n", + pools[i].name, ddsd.lPitch, > pools[i].align); > + if (pools[i].pitch) > + ok(ddsd.lPitch == pools[i].pitch, "%s: Expected pitch %d, got > %d.\n", + pools[i].name, pools[i].pitch, ddsd.lPitch); > + > + IDirectDrawSurface4_Release(surface); > + } > + > + IDirectDraw4_Release(ddraw); > +} > + > START_TEST(ddraw4) > { > test_process_vertices(); > @@ -1502,4 +1583,5 @@ START_TEST(ddraw4) > test_texture_load_ckey(); > test_viewport_interfaces(); > test_zenable(); > + test_pitch_alignment(); > } > diff --git a/dlls/ddraw/tests/ddraw7.c b/dlls/ddraw/tests/ddraw7.c > index 2ea77fe..4425ad4 100644 > --- a/dlls/ddraw/tests/ddraw7.c > +++ b/dlls/ddraw/tests/ddraw7.c > @@ -1277,6 +1277,87 @@ static void test_zenable(void) > DestroyWindow(window); > } > > +static void test_pitch_alignment(void) > +{ > + IDirectDraw7 *ddraw; > + IDirectDrawSurface7 *surface; > + HRESULT hr; > + static const struct > + { > + DWORD caps, caps2; > + UINT align; > + LONG pitch; > + const char *name; > + } > + pools[] = > + { > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY, 0, > + 8, 0, "D3DPOOL_DEFAULT" > + }, > + { > + DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY, 0, > + 8, 16, "D3DPOOL_SYSTEMMEM" > + }, > + { > + DDSCAPS_TEXTURE, DDSCAPS2_TEXTUREMANAGE, > + 8, 16, "D3DPOOL_MANAGED" > + } > + }; > + unsigned int i; > + DDSURFACEDESC2 ddsd; > + > + if (!(ddraw = create_ddraw())) > + { > + skip("Failed to create a ddraw object, skipping test.\n"); > + return; > + } > + > + hr = IDirectDraw7_SetCooperativeLevel(ddraw, NULL, DDSCL_NORMAL); > + ok(SUCCEEDED(hr), "Failed to set cooperative level, hr %#x.\n", hr); > + > + for (i = 0; i < (sizeof(pools) / sizeof(*pools)); i++) > + { > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | > DDSD_PIXELFORMAT; + ddsd.dwWidth = 5; > + ddsd.dwHeight = 5; > + U4(ddsd).ddpfPixelFormat.dwSize = sizeof(U4(ddsd).ddpfPixelFormat); > + U4(ddsd).ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(U4(ddsd).ddpfPixelFormat).dwRGBBitCount = 16; > + U2(U4(ddsd).ddpfPixelFormat).dwRBitMask = 0xF800; > + U3(U4(ddsd).ddpfPixelFormat).dwGBitMask = 0x07E0; > + U4(U4(ddsd).ddpfPixelFormat).dwBBitMask = 0x001F; > + ddsd.ddsCaps.dwCaps = pools[i].caps; > + ddsd.ddsCaps.dwCaps2 = pools[i].caps2; > + > + hr = IDirectDraw7_CreateSurface(ddraw, &ddsd, &surface, NULL); > + ok(SUCCEEDED(hr) || hr == DDERR_UNSUPPORTEDFORMAT || hr == > DDERR_NODIRECTDRAWHW, + "%s: Failed to create surface, hr > %#x.\n", pools[i].name, hr); + if (!surface) > + { > + skip("%s: Failed to create surface, skipping pitch alignment > test\n", pools[i].name); + continue; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + hr = IDirectDrawSurface7_GetSurfaceDesc(surface, &ddsd); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + > + ok(!(ddsd.lPitch & (pools[i].align - 1)), "%s: Pitch %d is not %u > byte aligned.\n", + pools[i].name, ddsd.lPitch, > pools[i].align); > + if (pools[i].pitch) > + ok(ddsd.lPitch == pools[i].pitch, "%s: Expected pitch %d, got > %d.\n", + pools[i].name, pools[i].pitch, ddsd.lPitch); > + > + IDirectDrawSurface7_Release(surface); > + } > + > + IDirectDraw7_Release(ddraw); > +} > + > START_TEST(ddraw7) > { > HMODULE module = GetModuleHandleA("ddraw.dll"); > @@ -1296,4 +1377,5 @@ START_TEST(ddraw7) > test_depth_blit(); > test_texture_load_ckey(); > test_zenable(); > + test_pitch_alignment(); > }

1 0

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests (try 2)
by Marvin 27 Feb '12

27 Feb '12

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 http://testbot.winehq.org/JobDetails.pl?Key=17115 Your paranoid android. === W7PROX64 (64 bit ddraw2) === ddraw2.c:1454: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw2.c:1457: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. === TEST64_W7SP1 (64 bit ddraw2) === ddraw2.c:1454: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw2.c:1457: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. === W7PROX64 (64 bit ddraw1) === ddraw1.c:1188: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw1.c:1191: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. === TEST64_W7SP1 (64 bit ddraw1) === ddraw1.c:1188: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw1.c:1191: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. === W7PROX64 (64 bit ddraw7) === ddraw7.c:1349: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw7.c:1352: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. ddraw7.c:1336: Test failed: D3DPOOL_MANAGED: Failed to create surface, hr 0x80004002. ddraw7.c:1349: Test failed: D3DPOOL_MANAGED: Pitch 12 is not 8 byte aligned. ddraw7.c:1352: Test failed: D3DPOOL_MANAGED: Expected pitch 16, got 12. === TEST64_W7SP1 (64 bit ddraw7) === ddraw7.c:1349: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw7.c:1352: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. ddraw7.c:1336: Test failed: D3DPOOL_MANAGED: Failed to create surface, hr 0x80004002. ddraw7.c:1349: Test failed: D3DPOOL_MANAGED: Pitch 12 is not 8 byte aligned. ddraw7.c:1352: Test failed: D3DPOOL_MANAGED: Expected pitch 16, got 12. === W7PROX64 (64 bit ddraw4) === ddraw4.c:1562: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw4.c:1565: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. ddraw4.c:1562: Test failed: D3DPOOL_MANAGED: Pitch 12 is not 8 byte aligned. ddraw4.c:1565: Test failed: D3DPOOL_MANAGED: Expected pitch 16, got 12. === TEST64_W7SP1 (64 bit ddraw4) === ddraw4.c:1562: Test failed: D3DPOOL_SYSTEMMEM: Pitch 12 is not 8 byte aligned. ddraw4.c:1565: Test failed: D3DPOOL_SYSTEMMEM: Expected pitch 16, got 12. ddraw4.c:1562: Test failed: D3DPOOL_MANAGED: Pitch 12 is not 8 byte aligned. ddraw4.c:1565: Test failed: D3DPOOL_MANAGED: Expected pitch 16, got 12.

1 0

Re: [PATCH] po: Update Swedish translation. (try 2)
by Lauri Kenttä 27 Feb '12

27 Feb '12

Please ignore this one, I missed a few bugs. -- Lauri Kenttä

1 0

Fw: Re: po: zh_TW translation updates
by Hin-Tak Leung 27 Feb '12

27 Feb '12

Strange bounces... --- On Mon, 27/2/12, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: > --- On Mon, 27/2/12, Francois Gouget > <fgouget(a)free.fr> > wrote: > > > Patches are posted to wine-patches(a)winehq.org: > > http://www.winehq.org/pipermail/wine-patches/2012-February/111804.html > > A quick look at it (it is a few hundred k) - says a few of > the problems I saw and suspected: > > - some of the changes are not improvements/corrections but > just opinionated changes > > - some changes are wrong (i.e. the older version is more > correct/natural and the change makes it worse, not better). > > - some of the changes are over-eager: i.e. it "improves" on > windows and tried to be more user-friendly, but not exactly > how windows does it. > > I think there should be a notes on the translation FAQ: one > is not looking to be "better than" windows, but > bug-for-bug-compatible. Therefore translation is preferably > what regional/localized windows (whatever version) does. > > 20% of the world's population is Chinese, I am sure it is > easy enough to do a few screenshots of localized windows (be > in traditional or simplied) and show how those behave. > > There is a definitive answer (or "definition answers") to > most of these translation strings: what localized windows > (some version) does. It is not up to individual or group > opinions, really. I mean, public libraries, etc have windows > in the far east, there is no excuse to be wrong, or on the > opposite extreme, "try to improve on windows", even if one > does not want to get one's hand dirty and own a windows > box. > > > > >

1 0

Re: po: fixed remaining Slovenian true positives in the winepo error report
by Jaka Kranjc 27 Feb '12

27 Feb '12

On Wednesday 22 of February 2012 18:16:20 Francois Gouget wrote: > On Wed, 22 Feb 2012, Jaka Kranjc wrote: > [...] > > > > You mean that all the 'not translated' strings are actually translated > > > and just happen to be the same as in English, right? I can add them. > > > > Exactly. > > Done. Great. I also swapped wine-patches with wine-devel to keep the noise down. > So in English you'd end up with something like this: > > Error; Paper jam; > or > Initialising; Default Printer; I/O Active; > > > So what you're saying is that: > * There is no systematic conversion of semicolons to commas in > Slovenian. > * In Slovenian the strings above should definitely use a comma > because it's used as a list separator. > * The English string should maybe use a comma too? This may require > some supporting arguments... So if I understand correctly, parts of this composite get choped and concatenated and then printed as a sequence. Lacking full sentences, semicolons *are* a good choice for Slovenian in this case too. Commas would be fitting for proper "etc" lists. This brings up another can of worms though; capitalisation. We don't use title case at all, so these translation have the wrong case. Well, except for the first one being printed, but that is runtime knowledge, so we can't really fix it well. Gettext has no provisions for this (or gender or ...), so all that comes to mind is autocapitalisation depending on the locale, but that is probably ugly and I doubt it would work with more exotic scripts (but not sure if any would need it). > > So no, in general we do not substitute semicolons, but it depends on the > > original msgid context. Most translators are serious grammar nazis, so > > they/we tend to ignore mistakes in the original string. > > Don't! > > At least for Wine any issue in the English string should be fixed or > reported so it can be fixed as early as possible (preferably before it > has been translated into 20 other languages). Of course I'm saying that > but being in string freeze we would not be able to fix strings right > now. But if I saw such reports on wine-devel I'd make sure they are > acted upon after the release. Oh, I know, didn't mean to suggest inaction. But in a lot of cases, it comes down to preference, style or language perception. Plus the fact that inspecting the original's validity almost always requires the ability to read code, which most translators lack and which is hard to access if they work via online translation tools. Re usage strings: is there no 80 column limit imposed? I saw even some original strings were longer. LP -- To err is humor

2 3

Re: [PATCH] po: Update Swedish translation.
by Jan-Peter Nilsson 27 Feb '12

27 Feb '12

Hi I have a few questions/comments/suggestions on/for the change in the Swedish translation. On -28163-01--10 20:59, Lauri Kenttä wrote: > #: comdlg32.rc:292 > -#, fuzzy > msgctxt "Luminance" > msgid "&Lum:" > -msgstr "&Lum:" > +msgstr "&Val:" Can you explain 'Val' here? I don't understand it. I would assume 'Luminance' to be translated to 'Luminans', so Lum as abbreviation makes sense to me. > #: ieframe.rc:78 > -#, fuzzy > msgid "Searching for %s" > -msgstr "Egenskaper för %s" > +msgstr "Söker för %s" "Söker efter" would probably be better. > #: shell32.rc:215 > -#, fuzzy > msgid "Common Files" > -msgstr "Kopierar filer..." > +msgstr "" Perhaps 'Delade Filer'? > #: cmd.rc:331 > -#, fuzzy > msgid "Verify is %1\n" > -msgstr "Verifiera blev %s\n" > +msgstr "Verifiera blev %1\n" I would use 'är', 'blev' is more 'became' than 'is'. > #: cmd.rc:335 > -#, fuzzy > msgid "Volume label (11 characters, <Enter> for none)?" > -msgstr "Diskvolymens namn (11 karaktärer, tryck enter för inget)?" > +msgstr "Diskvolymens namn (11 karaktärer, tryck <Enter> för inget)?" 'Karaktärer' is the other kind of characters, the word here is 'tecken'. > #: explorer.rc:29 > #, fuzzy > @@ -10042,9 +9949,8 @@ msgid "Usage: hostname\n" > msgstr "" > > #: hostname.rc:28 > -#, fuzzy > msgid "Error: Invalid option '%c'.\n" > -msgstr "Fel: ogiltigt nyckelnamn\n" > +msgstr "Fel: Ogiltigt val '%c'.\n" I'm not sure about 'val' here. To me 'val' reads more like 'selection' than 'option'. > #: net.rc:41 > msgid "There are no entries in the list.\n" > @@ -10215,14 +10110,12 @@ msgstr "" > "---------------------------------------------------------------\n" > > #: net.rc:43 > -#, fuzzy > msgid "%1 %2 %3 Open resources: %4!u!\n" > -msgstr "%s %s %s Öppna resurser: %lu\n" > +msgstr "%1 %1 %1 Öppna resurser: %4!u!\n" I suppose that should be %1 %2 %3. > #: regedit.rc:88 > -#, fuzzy > msgid "Modify Binary Data..." > -msgstr "Ändra binärt data" > +msgstr "Ändra binärt data..." 'binärdata' is one word. > #: taskkill.rc:31 > -#, fuzzy > msgid "Error: Option %1 expects a command line parameter.\n" > -msgstr "Fel: Valet %s kräver en kommandoradsparameter.\n" > +msgstr "Fel: Valet %1 kräver en kommandoradsparameter.\n" > > #: taskkill.rc:32 > msgid "Error: Options /im and /pid are mutually exclusive.\n" > msgstr "Fel: Valen /im och /pid kan inte användas tillsammans.\n" > Val again. I don't really have any better suggestion, but it sounds strange to me. > #: winecfg.rc:146 > -#, fuzzy > msgid "" > "Wine can mimic different Windows versions for each application. This tab is " > "linked to the Libraries and Graphics tabs to allow you to change systemwide " > "or per-application settings in those tabs as well." > msgstr "" > -"Wine kan imitera olika Windows-versioner för varje program. Den här fliken " > +"Wine kan imitera olika Windows-versioner för varje program. Den här fliken " > "är länkad till flikarna Bibliotek och Grafik för att låta dig ändra " > "inställningar i de flikarna också, antingen systembreda eller per program." > I believe 'systemövergripande' would be better than 'systembreda'. > > #: winecfg.rc:83 > -#, fuzzy > msgid "Audio test failed!" > -msgstr "Återställning av hårddisk misslyckades\n" > +msgstr "" Maybe "Ljudtest misslyckades!" ? > > #: winecfg.rc:85 > -#, fuzzy > msgid "(System default)" > -msgstr "Systemsökväg" > +msgstr "" Maybe "(Systemstandard)" ? > #: winefile.rc:197 > msgctxt "accelerator Fullscreen" > @@ -13528,9 +13355,8 @@ msgid "Error while selecting new font." > msgstr "Ett fel uppstod när ett nytt teckensnitt valdes." > > #: winefile.rc:95 > -#, fuzzy > msgid "Wine File Manager" > -msgstr "Winefile" > +msgstr "Wine Filhanteraren" "Wine Filhanterare", unless we want definite form "The Wine File Manager". > #: wordpad.rc:188 > -#, fuzzy > msgid "OLE storage documents are not supported." > -msgstr "Utökade attribut ej stödda\n" > +msgstr "" Maybe "OLE lagringsdokument stöds ej." ? //Jan-Peter

4 4

Wrong charcter encoding in winmm-tests
by Julian Rüger 27 Feb '12

27 Feb '12

Hello everyone, I ran the winmm-tests in wine today, with a german locale, and noticed that the umlauts are displayed incorrectly. My terminal is in UTF-8 and wine outputs ISO 8859-1. I looked into the code and found out that ie. in wave.c, wave_out_error() declares the strings as static char, and thus uses waveOutGetErrorTextA() if I am not mistaken. Should this be fixed or doesn't it matter in the tests? Best regards, Julian

2 5

Re: [PATCH 2/2] ddraw/tests: Add pitch alignment tests
by Marvin 26 Feb '12

26 Feb '12

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 http://testbot.winehq.org/JobDetails.pl?Key=17108 Your paranoid android. === WNT4WSSP6 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00420FAD === W2KPROSP4 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === WXPPROSP3 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === W2K3R2SESP2 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === WVISTAADM (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === W2K8SE (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw2: unhandled exception c0000005 at 00420FAD === W7PRO (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00420FAD === W7PROX64 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00420FAD === TEST64_W7SP1 (32 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw2: unhandled exception c0000005 at 00420FAD === W7PROX64 (64 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === TEST64_W7SP1 (64 bit ddraw2) === ddraw2.c:1438: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === WNT4WSSP6 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0041A3A5 === W2KPROSP4 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === WXPPROSP3 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === W2K3R2SESP2 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === WVISTAADM (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === W2K8SE (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw1: unhandled exception c0000005 at 0041A3A5 === W7PRO (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0041A3A5 === W7PROX64 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0041A3A5 === TEST64_W7SP1 (32 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw1: unhandled exception c0000005 at 0041A3A5 === W7PROX64 (64 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === TEST64_W7SP1 (64 bit ddraw1) === ddraw1.c:1175: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === W2KPROSP4 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === WXPPROSP3 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === W2K3R2SESP2 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === WVISTAADM (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === W2K8SE (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw7: unhandled exception c0000005 at 0042E3E1 === W7PRO (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 0042E3E1 === W7PROX64 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 0042E3E1 === TEST64_W7SP1 (32 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw7: unhandled exception c0000005 at 0042E3E1 === W7PROX64 (64 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === TEST64_W7SP1 (64 bit ddraw7) === ddraw7.c:1336: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === W2KPROSP4 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === WXPPROSP3 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === W2K3R2SESP2 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === WVISTAADM (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === W2K8SE (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x887601fe. ddraw4: unhandled exception c0000005 at 00427CC1 === W7PRO (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00427CC1 === W7PROX64 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00427CC1 === TEST64_W7SP1 (32 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. ddraw4: unhandled exception c0000005 at 00427CC1 === W7PROX64 (64 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout === TEST64_W7SP1 (64 bit ddraw4) === ddraw4.c:1549: Test failed: D3DPOOL_DEFAULT: Failed to create surface, hr 0x88760233. Timeout

1 0

Re: shlwapi: Implemented StrToInt64ExA/W
by Jacek Caban 26 Feb '12

26 Feb '12

Hi Carlo, On 2/26/12 12:56 PM, carlo.bramix(a)libero.it wrote: > I improved the patch according to the suggestions that I received: > 1) Removed the C++ style comment > 2) Removed the WARN message > 3) Added the tests for the new functions. The test has been run successfully > on Ubuntu 11.10. > > Sincerely Thanks for fixing those. This version looks better, but still could use some improvements (mostly for failing tests on win2k). BOOL WINAPI StrToIntExA(LPCSTR lpszStr, DWORD dwFlags, LPINT lpiRet) { + LARGE_INTEGER li; + BOOL bRes; + + TRACE("(%s,%08X,%p)\n", debugstr_a(lpszStr), dwFlags, lpiRet); + + if (!lpiRet) + return FALSE; In previous patch you mentioned that Windows crashes in this situation. Thus there is no point in having this check on Wine. int str_to_int; int str_to_int_ex; int str_to_int_hex; + LONGLONG str_to_int64_ex; + LONGLONG str_to_int64_hex; AFAICS int str_to_int* always matches str_to_int64* values except for overflows. It means that you could simply change str_to_int_* to be LONGLONG and simply cast it to int before using it in existing tests. + { "0x44ff", 0, 0, 0x44ff, 0, 0x44ff }, + { "0x2bdc546291f4b1", 0, 0, 0x6291f4b1, 0, 0x2bdc546291f4b1 }, 64-bit literals are not portable. Something like ((ULONGLONG)0x2bdc54<<32) | (ULONGLONG)0x6291f4b1 would do the trick. + while (result->string) + { + return_val = -1; + bRet = StrToInt64ExA(result->string,0,&return_val); This function is not available on win2k (http://testbot.winehq.org/JobDetails.pl?Key=17105&scrshot_202=1#k202), so it needs to be loaded dynamically via GetProcAddress. See how other functions are handled. Cheers, Jacek

1 0

Re: msvcrt/file.c: file mode T (temporary file) (try 2)
by Vitaliy Margolen 26 Feb '12

26 Feb '12

On 02/25/2012 05:30 AM, Robert van Herk wrote: > Try 2 fixes some blatant memory bug in the conformance test > --------------------------------------------------------------------------- > > Windows fopen has some fancy file modes 'T' and 'D'. > Currently, wine wrongly interprets 'T' as 't'. They should be interpreted > differently though: 't' is text file, and 'T' is temporary file. > > I've fixed this, and added a conformance test. > + case 'T': > + FIXME("Implement T flag (temporary file, i.e. delete on close, don't flush to disk if possible)"); > + break; So what actually prevents you from properly implementing this? Especially that Wine already supports temporary files. Search for MSVCRT__O_TEMPORARY Vitaliy.

2 1

Spaces in the Korean translation.
by Francois Gouget 26 Feb '12

26 Feb '12

I noticed some leading and trailing space issues in the Korean translation. I think these are probably safe to change. However I then noticed that there was a lot of sentences mixed single and double spaces. So I wonder if that's normal, maybe tied to a Korean typography rule related to half vs. full width characters; or if only single or double spaces should be present. Here are a few examples: "주의: 이 파일 형식은 아마도 하나 이상의 인증서,인증서 파기 목록,인증서 신뢰 " ^^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ "목록을 가지고 있을 수 있음:" ^ ^ ^ ^ msgstr "'여기로부터'엔트리는 여기까지'엔트리에 도달 할 수 없습니다." ^^ ^ ^ ^ ^ msgstr "대기열에는 %d의 문서가 존재합니다" ^^ ^ ^ -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

1 0

Re: sk.po
by Francois Gouget 26 Feb '12

26 Feb '12

Thanks for the translation updates. I noticed some potential issues while proofreading it: "to modify its installed components, select it from the list and click Change/" "Remove." msgstr "" +"Nasledujúci program môže byť automaticky odinštalovaný. K odstráneniu programu " +"alebo k modifukácii jeho inštalovaných súčastí, zvoľte možnosť zo zoznamu a kliknite " +"Zmeniť/Odstrániť" There should probably be a trailing full stop. msgid "Publisher:" -msgstr "" +msgstr "Vydavateľ" msgid "Version:" -msgstr "" +msgstr "Verzia" These are missing the trailing colon (these are likely field labels in a dialog). msgid "&Settings..." -msgstr "" +msgstr "&Nastavenia" #, fuzzy msgid "&Modify..." -msgstr "Modifikovaný" +msgstr "&Zmeniť" #, fuzzy msgid "&Install" -msgstr "&Skomentovať..." +msgstr "&Inštalovať..." These are either missing the trailing ellipsis or have one that should not be there. Ellipses are very important because, for instance, they make all the difference between a 'Print' button that will send the page to the default printer right away, and a 'Print...' button that will first display a dialog that will let you choose the destination printer or cancel before anything happens. Note that I did not list all ellipsis issues here. Also this is one of the points that my script checks so you'll see any ellipsis issue in Wine's PO file there: http://fgouget.free.fr/wine-po/sk-errors.html #, fuzzy msgid "Unexpected network error.\n" -msgstr "Nedefinovaná externá chyba." +msgstr "Nedefinovaná sieťová chyba." This translation should have a trailing linefeed. Also I notice that you did not remove the 'fuzzy' flag, not only here but also for quite a few other translations, including two others above. The fuzzy flag indicates that the translation is potentially incomplete or incorrect and thus requires more work or a review. So as long as it is present the translation will not be used. Keep up the good work. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

1 0

Re: shlwapi: Implemented StrToInt64ExA/W
by Marvin 26 Feb '12

26 Feb '12

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 http://testbot.winehq.org/JobDetails.pl?Key=17105 Your paranoid android. === W2KPROSP4 (32 bit string) === Timeout

1 0

Re: shlwapi: Implemented StrToInt64ExA/W
by Nikolay Sivov 25 Feb '12

25 Feb '12

On 2/25/2012 17:49, carlo.bramix(a)libero.it wrote: > I tried to implement StrToInt64ExA/W as a reply to bug #27633 > I also corrected the comment in functions FormatInt() and FormatDouble() > because, according to MSDN, GetNumberFormat() returns the number of characters > written (or required) and not the number of bytes emitted: > http://msdn.microsoft.com/en-us/library/windows/desktop/dd318110%28v=vs.85%…. > aspx > I hope my first patch to WINE is correct and it could be useful. > Sincerely, > > Carlo Bramini. > > > > BOOL WINAPI StrToIntExA(LPCSTR lpszStr, DWORD dwFlags, LPINT lpiRet) > { > + LARGE_INTEGER li; > + BOOL bRes; > + > + TRACE("(%s,%08X,%p)\n", debugstr_a(lpszStr), dwFlags, lpiRet); > + > + // Test on lpszStr is done into StrToInt64ExA No cpp comments please. Also this comment is a bit redundant for a function that small. > + if (!lpiRet) > + { > + WARN("Invalid lpiRet would crash under Win32!\n"); > + return FALSE; > + } You don't need to WARN on that, especially with such message. > + > + bRes = StrToInt64ExA(lpszStr, dwFlags,&li.QuadPart); > + if (bRes) > + *lpiRet = li.u.LowPart; > + > + return bRes; > +} This needs tests, take a look at shlwapi/tests for some examples.

1 0

Re: msvcrt/file.c: file mode T (temporary file)
by Nikolay Sivov 25 Feb '12

25 Feb '12

On 2/25/2012 00:19, Robert van Herk wrote: > Windows fopen has some fancy file modes 'T' and 'D'. > Currently, wine wrongly interprets 'T' as 't'. They should be > interpreted differently though: 't' is text file, and 'T' is temporary > file. > > I've fixed this, and added a conformance test. > > Test ran on Windows 7 Home Premium. > > Kind regards, > Robert > > dlls/msvcrt/file.c | 8 +++++- > dlls/msvcrt/tests/Makefile.in | 1 + > dlls/msvcrt/tests/filemodeT.c | 61 +++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 69 insertions(+), 1 deletions(-) > create mode 100644 dlls/msvcrt/tests/filemodeT.c You clearly don't need a new file for that, please place it into existing file.c.

1 0

Re: msvcrt/file.c: file mode T (temporary file)
by Marvin 25 Feb '12

25 Feb '12

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 http://testbot.winehq.org/JobDetails.pl?Key=17097 Your paranoid android. === WNT4WSSP6 (32 bit filemodeT) === filemodeT: unhandled exception c0000005 at 780109BF === WXPPROSP3 (32 bit filemodeT) === filemodeT: unhandled exception c0000005 at 77C41165

1 0

Re: po: Update Chinese (Taiwan) translation.
by Francois Gouget 24 Feb '12

24 Feb '12

Thanks for the translation update. It's a big one. There are pretty few issues given the size: msgid "&Modify..." -msgstr "" +msgstr "�޸�(&M)" The translation is missing the ellipsis here. msgid "" "This value does not lie within the page range.\n" "Please enter a value between %1!d! and %2!d!." msgstr "" -"�@��ֵ��퓔��\n" -"Ոݔ��һ�� %d �� %d ֮�g�Ĕ��" +"ݔ��ֵ��퓔��ȡ�\n" +"Ոݔ��һ�� %d �� %d ֮�g��ֵ��" The formatting directives should match. There's been quite a few changes of that type that had the goal of making it possible to reorder them so there may be other places with the same issue. #, fuzzy msgid "Write fault.\n" -msgstr "Ĭ�J��\n" +msgstr "�A�O��\n" #, fuzzy msgid "Read fault.\n" -msgstr "Ĭ�J��\n" +msgstr "�A�O��\n" ... Is it normal that you did not remove the fuzzy on this series of messages? (Maybe they need further review?) -#, fuzzy msgid "By &Type" msgstr "��" #: shell32.rc:52 -#, fuzzy msgid "By &Size" msgstr "��С" Should preserve the keyboard shortcut? -#, fuzzy msgid "LoadTypeLib( %1 ) failed ($%2!x!)" msgstr "LoadTypeLib( %s ) ʧ�� ($%x)" The format directives also need an update on this one. msgid "&New override for library:" -msgstr "��ʽ��(&N)��" +msgstr "��ʽ�츲�d(&N):" msgid "Existing &overrides:" -msgstr "��еĺ�ʽ��(&o)��" +msgstr "��еĺ�ʽ�츲�d(&O)��" I see that you replaced some full width colons with their half-width equivalent but not everywhere. What is the common practice there? As far as I know for full stops it's the full-width character that is used. However for characters like colons, question marks and exclamation points I don't know (looking at Windows 7 dialogs did not help there). msgid "Full &Path:" -msgstr "" +msgstr "��·��(P):" This one is missing the ampersand. That's the only such case as far as I can tell. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumi��re". Et la lumi��re fut.

2 1

Removing 'all' platform/os from bugzilla
by Austin English 23 Feb '12

23 Feb '12

Howdy, We seem to discourage use of the use of 'all' platform/os on bugzilla. While I personally am not opposed to it, in cases where it's obviously true (e.g., http://bugs.winehq.org/show_bug.cgi?id=29901), changing these fields causes unnecessary spam. It would be easier, imho to remove them. Does anyone have any opposition to this? I'm intending to leave 'other', of course. -- -Austin

2 2

Obscure texts and invalid translations
by Lauri Kenttä 23 Feb '12

23 Feb '12

Hi, Wine has many texts, especially error messages, that are almost impossible to translate without knowing what they're really about. Some are also easy to misunderstand. An example from dlls/kernel32/winerror.mc: msgid "Notify change request in progress.\n" Some interpretations: de, nb: "A request for notifications about changes is in progress." fr, sv: "A request to change a notification is in progress." it, pt: Both have their own versions, I think. There are many more such cases, although the difference is usually in only one or two languages. (Unfortunately it didn't occur to me to put them down from the beginning, so I can't give you a list. I'll just mention "Challenge Password" before I forget that, too.) 1) What should I do if I wanted to clarify a msgid? Just change the original .rc file? 2) Is there a way to add helpful comments to all language files at once without changing the msgid? 3) What should I do if I spot a suspicious translation? Spam the Bugzilla, contact the Last-Translator personally, or send patches to add #fuzzy comments and hope I'm right? And if it's wrong in many of the languages I can read, it's probably wrong in some others as well; who would check them all? 4) There has been discussions about some translation websites. Is there a chance that such a website would allow easy tagging of potential errors? -- Lauri Kenttä

3 5

Re: Alexandre Julliard : gdi32: Avoid overflows for invalid coordinates in line clipping.
by Charles Davis 22 Feb '12

22 Feb '12

On Feb 22, 2012, at 1:27 PM, Alexandre Julliard wrote: > --- a/dlls/gdi32/dibdrv/objects.c > +++ b/dlls/gdi32/dibdrv/objects.c > @@ -372,7 +372,8 @@ static inline DWORD calc_outcode(const POINT *pt, const RECT *clip) > int clip_line(const POINT *start, const POINT *end, const RECT *clip, > const bres_params *params, POINT *pt1, POINT *pt2) > { > - int m, n; > + > + INT64 m, n; /* 64-bit to avoid overflows (FIXME: find a more efficient way) */ What about MulDiv()? As I recall, this is the sort of situation for which it was designed. Or is that not efficient? Chip

2 1

Re: po: Spanish translation update for appwiz.rc and comdlg32.rc
by Francois Gouget 22 Feb '12

22 Feb '12

On Wed, 22 Feb 2012, Eduardo Garcia wrote: > This is the first patch of a series of patches aiming to update and complete > the Spanish interface in current Wine. This patch covers appwiz.rc and > comdlg32.rc. Cool. Thanks! I noticed some issues though: msgid "Publisher:" -msgstr "Editor:" +msgstr "Fabricante" You should not remove the colon here. msgctxt "Saturation" msgid "&Sat:" -msgstr "&Sat.:" +msgstr "&Saturaci??n:" msgctxt "Luminance" msgid "&Lum:" -msgstr "&Lum.:" +msgstr "&Luminancia:" These two are likely to be too long, hence why it's truncated. -#, fuzzy msgid "Files of type:" -msgstr "Archivos de &tipo:" +msgstr "&Tipo de archivo:" Apparently that one is not meant to have a key shortcut. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel