March 2012 - Wine-Devel - list.winehq.org

Re: Hungarian translation patch 2

by Nagy Zoltán

I would like to send a translation patch again. I am sending the file attached with the mail. Best regards,Zoltan Nagy Francois Gouget <fgouget(a)free.fr> írta: > >Thanks. That first patch made quite a big difference already. Hungarian >is now in the 90% range :-) > >I noticed some issues though: > >-#, fuzzy > msgid "&Modify/Remove" > msgstr "&Módosítás/Eltávolítás..." > >You should remove the ellipsis here. > > > msgctxt "Saturation" > msgid "&Sat:" >-msgstr "" >+msgstr "&Telítettség:" > > msgctxt "Luminance" > msgid "&Lum:" >-msgstr "" >+msgstr "&Fényerő" > >These two may be too long, hence why they are truncated in English. You >can check in winecfg. Go to Desktop Integration, pick an Item, click on >Color and click on Define Custom Colors. They should also have a >trailing colon. > > > msgctxt "All key" > msgid "A" >-msgstr "" >+msgstr "A" > >Given that 'All' is translated into 'Mind', this should most likely be >an 'M'. > > >-#, fuzzy > msgid "Certificate &status:" >-msgstr "Tanusítvány beszerzés" >+msgstr "Tanusítvány &állapot" > >-#, fuzzy > msgid "&Friendly name:" > msgstr "Keresztnév" > >More missing colons... Also the second one looks like it's supposed to >have a keyboard shortcut. > > > msgid "Connection is active.\n" >-msgstr "Kapcsolat aktív" >+msgstr "Kapcsolat aktív\n" > >This one should probably have a trailing full stop. > > > >You'll find more issues like this on the Wine PO site. >http://fgouget.free.fr/wine-po/ > > >Specifically: >http://fgouget.free.fr/wine-po/hu-errors.html > > >-- >Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > La terre est une bêta...

March 1, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Maarten Lankhorst

Hey Joerg, Op 01-03-12 14:39, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > Hi, > > Maarten Lankhorst wrote: >>>> - Align buffer size to a multiple of period size >>> How can you pass the tests with that? It's wrong with both capture (annoyingly IMHO) and playback. >> I only really need it for capture, rendering needs it too since the tests >> show that this is the case, >> and seems to be against the tests too that everything is a multiple of period. > What is the case? Where did you see that? > > Native mmdevapi does not align GetBufferSize on period boundaries,neither render > nor capture. The current tests may not reveal it, because 500ms is a multiple of 10ms, > but I've enough additional tests in my git and log data from testbot to be sure about that. > > I consider it unsafe to diverge from native when rendering. Ah ok. I was under the impression it was supposed to, but I guess not then. >> but there's nothing in the code that depends on it. > Good. > >> For capture it's different, you need to keep track of packets somehow. >> [...] Having one packet that's not a period is a pain, > I felt the same pain with winecoreaudio. I think I'm going to agree (with myself) to disagree > (with mmdevapi), as standards would say, and align capture GetBufferSize on period boundaries. > This will considerably simplify the code. I've not changed winecoreaudio capture yet. > > So I find it ok if winepulse does the same: > - capture buffer as multiple of periods if it simplifies packet handling, > - render buffer exactly like native, not a multiple of period (cf. MulDiv in the tests). > > And I'll change the capture tests to ensure it asks for buffer sizes as multiples of period, > so the divergence won't show up :-) > > BTW, please use the MulDiv computations so as to minimize differences among the 3-4 drivers. > Or exhibit tests that prove them wrong. It is allowed to allocate a buffer with a larger than requested time, see: http://msdn.microsoft.com/en-us/library/windows/desktop/dd370875%28v=vs.85%… The comment in hnsBufferDuration indicates it may allocate a larger buffer. Also, exclusive mode rendering seems to fail the period check on my laptop. >> I'd have to recheck on my windows pc > I forgot: Don't be wary of returning GetMixFormat with 6 channels if PA's device is 5:1. Native > does that too (we had a few logs on test.winehq with that result) > (it may be too early if dsound chokes on that, but that would be a bug in dsound). I return the result of the pulseaudio configuration, which may indeed be 5.1. :) I should probably do another getmixformat for capturing, because while it can be 5.1 if you're using the monitor stream as source, it's not necessarily the case. For example 5.1 output to speakers with a usb headset at 32kHz rate for capturing. >> Is it really IsFormatSupported's job to deal with a WAVEFORMATEX struct >> with only cbSize and wFormatTag and it will get out something sane all the >> time, no matter how stupid the input? > I've never seen IsFormatSupported return something else than GetMixFormat and that is EXTENSIBLE. > For months I thought it would always return S_FALSE and GetMixFormat, no matter how stupid the input, but: > a) I've no tested this with ADPCM or other such stuff; > b) I've not tested channel variations with >2 channels, lacking a 5:1 or such card; > c) recent test.winehq has one Vista machine return E_UNSUPP_FORMAT > when the rate was != GetMixFormat. I have a patch in my queue to have the render test accept that variation. That was my belief when testing too, unfortunately for dsound and winmm we will have to accept rate != GetMixFormat.rate, so that is a test I won't be able to pass with winepulse on wine. Fortunately the windows programs will not break on this, since they get the rate from GetMixFormat or IsFormatSupported. > What I believe is: > 1. During mmdevapi init, MS queries a GetMixFormat from each working device and caches that. > 2. Later, IsFormatSupported returning GetMixFormat is a cheap operation: clone_format(cached_mix_format). > None of our drivers work this way. Doing it would need some thinking about dynamic reconfiguration and plug-in devices. I'm actually doing similar things. However on moving stream from old sink to new sink I'll keep returning the metrics of the initial sink. Hopefully it's not that big a problem, since pulseaudio will remember the device used for each stream. The next time the program executes it will get the updated GetMixFormat for the new sink. Winepulse does similar things for mix format actually, although maybe I should just cache the WaveFormatExtensible for capture and render instead of deriving it at runtime. ~Maarten

March 1, 2012

Re: Error with msgfmt

by Christian Costa

I know now. gettext is required for maintainer mode and optional for normal one. Version 0.15 or above is required to have the build working. Will send a patch for that. 2012/3/1 Christian Costa <titan.costa(a)gmail.com> > Hi, > > When compiling wine on another machine I got this error : > > po/ar.po:359: keyword "msgctxt" unknown > po/ar.po:359:8: parse error > po/ar.po:591: keyword "msgctxt" unknown > po/ar.po:591:8: parse error > > Is po files generation supposed to be done only in maintener mode ? > In any case gettext version check should be added in configure.ac. Which > first version supports msgctxt ? > > Thanks in advance > Bye > Christian > >

March 1, 2012

Re: winemenubuilder: Nothing useful is done on Mac OS X so just exit.

by Michael Stefaniuc

Hello Francois, On 03/01/2012 03:07 AM, Francois Gouget wrote: > --- > > A real Mac OS X implementation would be nice but barring that it seems > better to do nothing than to create .desktop files and directories that > make no sense on Mac OS X. > > programs/winemenubuilder/winemenubuilder.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/programs/winemenubuilder/winemenubuilder.c b/programs/winemenubuilder/winemenubuilder.c > index 1588e50..458e207 100644 > --- a/programs/winemenubuilder/winemenubuilder.c > +++ b/programs/winemenubuilder/winemenubuilder.c > @@ -3619,6 +3619,10 @@ int PASCAL wWinMain (HINSTANCE hInstance, HINSTANCE prev, LPWSTR cmdline, int sh > HRESULT hr; > int ret = 0; > > +#ifdef __APPLE__ > + WINE_FIXME("creating menus is not supported on Mac OS X\n"); > + return 0; > +#endif > if (!init_xdg()) > return 1; > no clue if the compiler there complains but you are producing unreachable code in the #ifdef __APPLE__ case. bye michael

March 1, 2012

Error with msgfmt

by Christian Costa

Hi, When compiling wine on another machine I got this error : po/ar.po:359: keyword "msgctxt" unknown po/ar.po:359:8: parse error po/ar.po:591: keyword "msgctxt" unknown po/ar.po:591:8: parse error Is po files generation supposed to be done only in maintener mode ? In any case gettext version check should be added in configure.ac. Which first version supports msgctxt ? Thanks in advance Bye Christian

March 1, 2012

Re: start: Remove the license and the /L option.

by Lauri Kenttä

On 2012-03-01 15:53, Lauri Kenttä wrote: > Your patch only changes the cmd.rc strings in the po files. You > should probably fix the start.rc strings as well. Ignore this, I somehow misunderstood your explanation. Now I got it. -- Lauri Kenttä

March 1, 2012

Re: Major mmdevapi and winmm audio bugs

by Joerg-Cyril.Hoehle＠t-systems.com

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

March 1, 2012

Re: start: Remove the license and the /L option.

by Lauri Kenttä

Your patch only changes the cmd.rc strings in the po files. You should probably fix the start.rc strings as well. -- Lauri Kenttä

March 1, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Maarten Lankhorst wrote: >>> - Align buffer size to a multiple of period size >> How can you pass the tests with that? It's wrong with both capture (annoyingly IMHO) and playback. >I only really need it for capture, rendering needs it too since the tests >show that this is the case, >and seems to be against the tests too that everything is a multiple of period. What is the case? Where did you see that? Native mmdevapi does not align GetBufferSize on period boundaries,neither render nor capture. The current tests may not reveal it, because 500ms is a multiple of 10ms, but I've enough additional tests in my git and log data from testbot to be sure about that. I consider it unsafe to diverge from native when rendering. >but there's nothing in the code that depends on it. Good. >For capture it's different, you need to keep track of packets somehow. >[...] Having one packet that's not a period is a pain, I felt the same pain with winecoreaudio. I think I'm going to agree (with myself) to disagree (with mmdevapi), as standards would say, and align capture GetBufferSize on period boundaries. This will considerably simplify the code. I've not changed winecoreaudio capture yet. So I find it ok if winepulse does the same: - capture buffer as multiple of periods if it simplifies packet handling, - render buffer exactly like native, not a multiple of period (cf. MulDiv in the tests). And I'll change the capture tests to ensure it asks for buffer sizes as multiples of period, so the divergence won't show up :-) BTW, please use the MulDiv computations so as to minimize differences among the 3-4 drivers. Or exhibit tests that prove them wrong. >I'd have to recheck on my windows pc I forgot: Don't be wary of returning GetMixFormat with 6 channels if PA's device is 5:1. Native does that too (we had a few logs on test.winehq with that result) (it may be too early if dsound chokes on that, but that would be a bug in dsound). >Is it really IsFormatSupported's job to deal with a WAVEFORMATEX struct >with only cbSize and wFormatTag and it will get out something sane all the >time, no matter how stupid the input? I've never seen IsFormatSupported return something else than GetMixFormat and that is EXTENSIBLE. For months I thought it would always return S_FALSE and GetMixFormat, no matter how stupid the input, but: a) I've no tested this with ADPCM or other such stuff; b) I've not tested channel variations with >2 channels, lacking a 5:1 or such card; c) recent test.winehq has one Vista machine return E_UNSUPP_FORMAT when the rate was != GetMixFormat. I have a patch in my queue to have the render test accept that variation. What I believe is: 1. During mmdevapi init, MS queries a GetMixFormat from each working device and caches that. 2. Later, IsFormatSupported returning GetMixFormat is a cheap operation: clone_format(cached_mix_format). None of our drivers work this way. Doing it would need some thinking about dynamic reconfiguration and plug-in devices. Regards, Jörg

March 1, 2012

Re: gdiplus: Create GDI brush only when needed. Take 2.

by Vincent Povirk

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

March 1, 2012