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

Error with msgfmt
by Christian Costa 01 Mar '12

01 Mar '12

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

1 1

Re: winemenubuilder: Nothing useful is done on Mac OS X so just exit.
by Michael Stefaniuc 01 Mar '12

01 Mar '12

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

1 0

Re: start: Remove the license and the /L option.
by Lauri Kenttä 01 Mar '12

01 Mar '12

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

1 1

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 29 Feb '12

29 Feb '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 29 Feb '12

29 Feb '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