Re: comctl32: Fix TB_SETEXTENDEDSTYLE to use mask passed in wParam
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=16982 Your paranoid android. === WNT4WSSP6 (32 bit toolbar) === toolbar.c:1898: Test failed: 1: got style 0x0008, expected 0x0099 toolbar.c:1898: Test failed: 7: got style 0x0008, expected 0x toolbar.c:1898: Test failed: 8: got style 0x0010, expected 0x toolbar.c:1898: Test failed: 9: got style 0x0008, expected 0x
Re: gdi32: Make output of dumping GDI objects more compact.
Dmitry Timoshkov dmi...@baikal.ru writes: Dmitry Timoshkov dmi...@baikal.ru wrote: --- dlls/gdi32/gdiobj.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) What's the reason for the 'rejected' status? Traces without prefixes are confusing when they are interleaved with other things. -- Alexandre Julliard julli...@winehq.org
Re: gdi32: Make output of dumping GDI objects more compact.
Alexandre Julliard julli...@winehq.org wrote: Traces without prefixes are confusing when they are interleaved with other things. This dump is being printed only in the emergency case, so, this is not really a trace. Besides there are other places in Wine which use the same style: 'if (TRACE_ON()) MESSAGE();', what makes this dumping functions different from them? -- Dmitry.
Re: gdi32: Make output of dumping GDI objects more compact.
Dmitry Timoshkov dmi...@baikal.ru writes: Alexandre Julliard julli...@winehq.org wrote: Traces without prefixes are confusing when they are interleaved with other things. This dump is being printed only in the emergency case, so, this is not really a trace. Besides there are other places in Wine which use the same style: 'if (TRACE_ON()) MESSAGE();', what makes this dumping functions different from them? In general, these are because they don't print full lines. If they do, they should be fixed. All traces should have a trace prefix. -- Alexandre Julliard julli...@winehq.org
Re: gdi32: Make output of dumping GDI objects more compact.
Alexandre Julliard julli...@winehq.org wrote: In general, these are because they don't print full lines. If they do, they should be fixed. All traces should have a trace prefix. Is it OK to add a prefix manually to the MESSAGE calls? -- Dmitry.
Re: msxml3: Fix varargs handling in libxml2 error callback implementation
Nikolay Sivov nsi...@codeweavers.com writes: The problem is that vsnprintf() was called multiple times with same va_list. Ti fix that it was necessary to get rid of some tracing bits like macro-defined callback calls and a single function for all kinds of error types. Actually there's no need to call vsnprintf multiple times. The debug buffer has a limited size anyway, so we might as well use a limited stack buffer here. -- Alexandre Julliard julli...@winehq.org
Re: gdi32: Make output of dumping GDI objects more compact.
Dmitry Timoshkov dmi...@baikal.ru writes: Is it OK to add a prefix manually to the MESSAGE calls? No, that wouldn't handle +tid and the like. -- Alexandre Julliard julli...@winehq.org
Re: advapi32/tests: Marked some tests that fail on Wine as todo_wine.
Now I ran the tests on another Linux system with wine, and there the failing tests are skipped, so it seems I did not fully understand what's going on here and why the tests are run on my system.
Re: winmm: Allow new sounds to interrupt previous PlaySound invocations.
On Thu, Feb 16, 2012 at 10:10:09AM +0100, joerg-cyril.hoe...@t-systems.com wrote: Hi, this fixes bug #28413. Thanks Jörg, looks sane to me and I can confirm it fixes the problem. Andrew
re: How program are Loaded to wine
Have you read the documentation, e.g. http://www.winehq.org/docs/winedev-guide/architecture ? Have you tried stepping through the source of CreateProcess by hand? http://source.winehq.org/source/dlls/kernel32/process.c#L2389 If you need more background, I hear Windows Internals is useful, http://www.amazon.com/windows-internals-5-rainbow-pony/dp/0735625301
Re: po: Add and fix a few Finnish translations.
On Thu, 16 Feb 2012, Lauri Kenttä wrote: Thai is right, Thain is wrong. Sorry. I mistook 'Thai' as refering to the Thai language where in this case it actually refers to the Thai script. Please don't mess with Finnish if you don't know it. As I've said, I'm working on it. If you feel I'm too slow, feel free to hire me and I'll do it faster. ;) Sorry, I did not mean to imply you're too slow or anything. I also meant to CC you to be sure you'd have a chance to review my patches and I'm not sure how you got left out of my emails. Avankuvan väli: has this colon on purpose. It's the best way to make this translation meaningful in the context (Avainkuvan väli: [BOX] kuvaa). I've already discussed this with you in private. Sorry. I had not made the connection. I'm not sure how the colon helps as this is meant to form just one sentence 'Key every 9 frames' but I'll just trust you on that. My opinion is that the original text should be in one piece or at least have a msgctxt to allow better translations. I'm not sure how a message context would help. Could you elaborate? -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Re: [1/2] msxml3: Use static buffer when tracing libxml2 error messages
Nikolay Sivov nsi...@codeweavers.com writes: Use static buffer when tracing libxml2 error messages I don't think it's necessary to rename all the functions. Please keep patches small, especially during code freeze. -- Alexandre Julliard julli...@winehq.org
Re: gdi32: Make output of dumping GDI objects more compact.
Alexandre Julliard julli...@winehq.org wrote: Is it OK to add a prefix manually to the MESSAGE calls? No, that wouldn't handle +tid and the like. As a person, who have debugged and fixed quite a bit of GDI handle leaks, and who actually have introduced that facility in the first place, I can say, that an ability to see each line of GDI handle table prefixed with 'dump_gdi_objects:', thread id, or whatever doesn't help at all, but an ability to see more information on the screen wihout need to scroll forth and back, an ability to quickly figure out some pattern in that table really does. -- Dmitry.
Re: gdi32: Make output of dumping GDI objects more compact.
Dmitry Timoshkov dmi...@baikal.ru writes: As a person, who have debugged and fixed quite a bit of GDI handle leaks, and who actually have introduced that facility in the first place, I can say, that an ability to see each line of GDI handle table prefixed with 'dump_gdi_objects:', thread id, or whatever doesn't help at all, but an ability to see more information on the screen wihout need to scroll forth and back, an ability to quickly figure out some pattern in that table really does. I'm sure everybody thinks the traces they are interested in deserve a different format, but that's not possible for obvious reasons. Just learn to use grep and sed. -- Alexandre Julliard julli...@winehq.org
Re: gdi32: Make output of dumping GDI objects more compact.
Alexandre Julliard julli...@winehq.org wrote: As a person, who have debugged and fixed quite a bit of GDI handle leaks, and who actually have introduced that facility in the first place, I can say, that an ability to see each line of GDI handle table prefixed with 'dump_gdi_objects:', thread id, or whatever doesn't help at all, but an ability to see more information on the screen wihout need to scroll forth and back, an ability to quickly figure out some pattern in that table really does. I'm sure everybody thinks the traces they are interested in deserve a different format, but that's not possible for obvious reasons. Just learn to use grep and sed. Unfortunately that's not always possible, for instance the log created by the app in the bug 29894 is more than 6 Gb. And once I see a suspect GDI handle, I want to see where it was created and how used, if that's wrong handle, I'd like to try another one from the same place of the log. -- Dmitry.
Known DLLs
Hello I've been a Wine user for a long time alreadey, since all Wine could do was running winesweper very slowly ;) I'd like to propose a feature that could be implemented in Wine. Wine does not implement all Windows APIs (yet ;)) and big parts of existing implementations are only stubs. Therefore, it could be usefull if Wine would be able to detect when a program tries to use a DLL that is not implememnted, but is easily available for download. .NET, MSXML, VCRUN* comes in mind. Instead of just failing, Wine could offer advice to the user how to deal with that. This could also help with APIs that are mostly stubbed, work for some use cases, but are expected to fail in other - they could detect if an app is trying to use unsuported case and take action. Adam Klobukowski
Translators wanted!
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! pWine is looking for translators for the 1.4 release!/p pWine'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./p pLuckily, 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./p 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 actiong. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: msxml3: Fix varargs handling in libxml2 error callback implementation
On Thu, Feb 16, 2012 at 03:15:59AM +0300, Nikolay Sivov wrote: If I remember correctly, you can even process a va_list only once on some platforms. We use it that way in couple of places, so it seems to work and I can't find a proper description or part of a standard that says it's not portable. It definitely isn't portable. The fact that it works sometimes is irrelevant. See winegcc/wrc for --- char* strmake(const char* fmt, ...) --- as an example. That probably means vsnprintf() and similar calls were added as part of C99 as well, so their presence implies working va_copy() is available. vsnprintf() was added to a lot of system much earlier than va_copy(). Last time I looked I couldn't find a va_copy() for the Microsoft C compiler we were using at the time. In my case it wasn't a printf, but a function that took a list of pointers followed by a NULL - so I copied them into an on-stack array. David -- David Laight: da...@l8s.co.uk
Re: Translators wanted!
Hello, On Fri, Feb 17, 2012 at 2:13 AM, Francois Gouget fgou...@free.fr wrote: 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 I would like to help to update the Simplified Chinese translation, but most likely I have no enouth time to complete it before wine-1.4 final release. Could anyone give a deadline? If anyone would like to translate Simplified Chinese please post a reply here to prevent duplication work. Also I'll forward this mail to Traditional Chinese community, since as a native Simplified Chinese speaker I can't use Traditional Chinese correctly every time. Thanks Francois and the Wine community :) -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Re: Known DLLs
Am Donnerstag, 16. Februar 2012, 18:45:37 schrieb Adam Kłobukowski: Therefore, it could be usefull if Wine would be able to detect when a program tries to use a DLL that is not implememnted, but is easily available for download. .NET, MSXML, VCRUN* comes in mind. Instead of just failing, Wine could offer advice to the user how to deal with that. This could also help with APIs that are mostly stubbed, work for some use cases, but are expected to fail in other - they could detect if an app is trying to use unsuported case and take action. Well, if a DLL is outright missing you should get an ERR. If the app calls a stub, the stub writes a FIXME. I'm not sure what else we can do - showing up a dialog box in those cases is a bad idea. Or do you mean make the messages more informative, like write you may want to install the Visual Basic 6 runtime from http://microsoft.com/foo/bar; instead of something like could not load msvb60.dll? Arguably the worst situation is when the app loads a library at runtime instead of linking and thus doesn't cause linker errors, or if it attempts to load a OLE class and users misinterpret the err:ole: error as an OLE issue rather than a missing library. Overall I'd prefer to maintain such information in the documentation or wiki instead of the code.
Re: Known DLLs
W dniu 16.02.2012 19:34, Stefan Dösinger pisze: Am Donnerstag, 16. Februar 2012, 18:45:37 schrieb Adam Kłobukowski: Therefore, it could be usefull if Wine would be able to detect when a program tries to use a DLL that is not implememnted, but is easily available for download. .NET, MSXML, VCRUN* comes in mind. Instead of just failing, Wine could offer advice to the user how to deal with that. This could also help with APIs that are mostly stubbed, work for some use cases, but are expected to fail in other - they could detect if an app is trying to use unsuported case and take action. Well, if a DLL is outright missing you should get an ERR. If the app calls a stub, the stub writes a FIXME. I'm not sure what else we can do - showing up a dialog box in those cases is a bad idea. Or do you mean make the messages more informative, like write you may want to install the Visual Basic 6 runtime from http://microsoft.com/foo/bar; instead of something like could not load msvb60.dll? While Wine log might be enough for me, for less tech savvy users it is a mistery, and in most cases they do not even know it exists. Log message seems an easy solution, but a dialog box might be much better for a 'customer base' of such feature. Such dialog should be shown only once per program run, In some cases (.NET?) such deature could even offer an auto-fix (using winetricks?). Arguably the worst situation is when the app loads a library at runtime instead of linking and thus doesn't cause linker errors, or if it attempts to load a OLE class and users misinterpret the err:ole: error as an OLE issue rather than a missing library. Still, apps loads some DLL, ant this can be intercepted. I do not know enough about how OLE works, but maybe a sister 'Known OLE keys' feature might me usefull too :) Overall I'd prefer to maintain such information in the documentation or wiki instead of the code. This could be handled by some kind of configuration (xml?) file. AdamK
Re: Translators wanted!
On Thu, Feb 16, 2012 at 7:13 PM, Francois Gouget fgou...@free.fr wrote: 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/ Hi Francois, I checked the dutch translation, and your site gives 95% for nl. I have a few questions 1) It says there are 39 todo, is it possible to show which ones still need to be done? 2) Most of the consistency errors are false positives (whe use quite a lot english words), is it possible to mark them as false positive or something? 3) There's an consistency ignore list, does that mean that the original english translation is used there? 4) Same for spell list, there are also quite a few false positives there. I'd like to help get the dutch translation to 100%, but I would need to filter out the false positives first. Thanks, Matijn
Re: Translators wanted!
Qian Hong fract...@gmail.com writes: I would like to help to update the Simplified Chinese translation, but most likely I have no enouth time to complete it before wine-1.4 final release. Could anyone give a deadline? Seeing how things are progressing, we are probably about two weeks from final release. There will be a 1.4.1 release a couple of months afterwards where we can add the translations that didn't make it into 1.4, so your efforts won't be wasted even if you can't make the deadline. -- Alexandre Julliard julli...@winehq.org
wineapploader in wine64
Hi, Any explanation for why the wineapploader script doesn't use 'wine64' instead of 'wine' in a 64bit Linux with 64bit wine? That's the script that is used to build /usr/bin/wineboot and /usr/bin/regedit, for instance. In Fedora 15 with wine 1.3.24, the upshot is that the 'wineboot' command doesn't work. /usr/lib/wine/wineboot.exe.so is not installed; only /usr/lib64/wineboot.exe.so is. Since the /usr/bin/wineboot is running 'wine' instead of 'wine64' it is looking for the 32bit /usr/lib/wine/wineboot.exe.so. It can't be found since it isn't installed so the loader gives up. $ wineboot wine: cannot find LC:\\windows\\system32\\wineboot.exe If it used wine64 instead, it would work. There must be a reason that wine64 is starting 32bit apps, but I haven't been able to glean anything from the web. Thanks for any info, -- Michael Ost
Re: wineapploader in wine64
Michael Ost m...@museresearch.com writes: In Fedora 15 with wine 1.3.24, the upshot is that the 'wineboot' command doesn't work. /usr/lib/wine/wineboot.exe.so is not installed; only /usr/lib64/wineboot.exe.so is. Since the /usr/bin/wineboot is running 'wine' instead of 'wine64' it is looking for the 32bit /usr/lib/wine/wineboot.exe.so. It can't be found since it isn't installed so the loader gives up. It could be considered it a bug, but 64-bit-only setups are not really supported. You need to have the 32-bit side, if only to create a valid prefix (besides, there shouldn't be any reason to run wineboot by hand). -- Alexandre Julliard julli...@winehq.org
Re: wineapploader in wine64
Le jeudi 16 février 2012 20:57:10, Alexandre Julliard a écrit : (besides, there shouldn't be any reason to run wineboot by hand). FWIW, on wine (32bits) I use wineboot -ks to get rid of a crashing app (stuck eating cpu, or just willing to stay). -- Vincent Pelletier
Re: wineapploader in wine64
On Thu, Feb 16, 2012 at 14:21, Vincent Pelletier plr.vinc...@gmail.com wrote: Le jeudi 16 février 2012 20:57:10, Alexandre Julliard a écrit : (besides, there shouldn't be any reason to run wineboot by hand). FWIW, on wine (32bits) I use wineboot -ks to get rid of a crashing app (stuck eating cpu, or just willing to stay). Most people use `wineserver -k` for that. -- -Austin
Re: wineapploader in wine64
On 02/16/2012 11:57 AM, Alexandre Julliard wrote: prefix (besides, there shouldn't be any reason to run wineboot by hand). We use it with --shutdown to cleanly terminate (as in WM_CLOSE, not kill) all wine apps from a hardware button press. Is there a preferred way? Thanks! -- Michael Ost
re: Known DLLs
This has been discussed off and on over the years, e.g. http://www.winehq.org/pipermail/wine-devel/2009-September/078441.html http://www.winehq.org/pipermail/wine-devel/2010-September/086465.html http://www.winehq.org/pipermail/wine-devel/2010-September/086469.html There is a kind of notification system in place, the winediag debug channel. I think the intent of that was to make it possible for distros to show those messages to the user (maybe with a dialog), and hide all the other log messages. At the moment, the dll load failure message doesn't go to +winediag. Maybe it should (although there are probably times when it's safe to ignore them, so I'm not sure). Anyway, +winediag or not, one can imagine a wrapper outside wine that notices events like this and offers to assist the user in those few cases (mfc42? vb6run?) where there's a high likelihood of success. Here's a crude example: wine $@ 21 | tee foo.log if grep -i Library MFC42.DLL foo.log then zenity --warning --text This app seems to need mfc42. Try running winetricks mfc42. fi It would take a bunch of work to get something worth deploying, but if you're interested, go for it...
Re: wineapploader in wine64
Michael Ost m...@museresearch.com writes: On 02/16/2012 11:57 AM, Alexandre Julliard wrote: prefix (besides, there shouldn't be any reason to run wineboot by hand). We use it with --shutdown to cleanly terminate (as in WM_CLOSE, not kill) all wine apps from a hardware button press. Is there a preferred way? No that's OK, though in general I'd suggest using 'wine64 wineboot' in scripts so that you don't depend on the /usr/bin wrapper scripts. -- Alexandre Julliard julli...@winehq.org
Removing 'all' platform/os from bugzilla
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
Re: Translators wanted!
On Thu, 16 Feb 2012, Matijn Woudt wrote: [...] 1) It says there are 39 todo, is it possible to show which ones still need to be done? Look for 'fuzzy' in the PO file. 2) Most of the consistency errors are false positives (whe use quite a lot english words), is it possible to mark them as false positive or something? Sure. Send me an email with the msgids of the false positives and I'll update the Wine PO site so they are ignored. Note that I've already done an update for the ones I could identify and I've sent a couple of patches with the issues I've identified (and I've CC-ed you). 3) There's an consistency ignore list, does that mean that the original english translation is used there? The ignore list corresponds to the false positives I could identify. Indeed it only had strings where the translation is identical to the English string. That's what 'potool-flags=translated' says. 4) Same for spell list, there are also quite a few false positives there. Send me a list of the words to add to aspell's dictionary. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Be careful of reading health books, you might die of a misprint. -- Mark Twain
Re: Problems with translatable strings
On Tue, 14 Feb 2012, Gustavo Henrique Milaré wrote: [...] while the string in wine.pot file reads Allows you to install new software, or remove existing software from your computer. Just in case you missed it, this got fixed: http://bugs.winehq.org/show_bug.cgi?id=27246 -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
Re: Translators wanted!
On 16-02-2012 at 7:55 PM, Matijn Woudt tijn...@gmail.com wrote: I'd like to help get the dutch translation to 100%, but I would need to filter out the false positives first. I started with this a while ago, but every time I was nearly done, more translations were marked as fuzzy, more strings were introduced, and usually Francois changed some strings, which meant that I had to manually apply the patch I was working on (with some conflicts). After a while I just gave up on this (I don't have the time to fix it all in one day), so for me the po system actually works counterproductive... What I want to say here is that if that if you want to get some small fixes in without actually knowing the language you're working on (like Francois), please don't send separate patches every few days, because that's really annoying. Just send them all at once, or just let translators fix it. Or at least set a string freeze, after which people who are actual translators can translate strings. @Matijn, please go ahead and update the Dutch translation. Sven
Re: Translators wanted!
On Fri, Feb 17, 2012 at 12:40 AM, Sven Baars sven.w...@gmail.com wrote: On 16-02-2012 at 7:55 PM, Matijn Woudt tijn...@gmail.com wrote: I'd like to help get the dutch translation to 100%, but I would need to filter out the false positives first. I started with this a while ago, but every time I was nearly done, more translations were marked as fuzzy, more strings were introduced, and usually Francois changed some strings, which meant that I had to manually apply the patch I was working on (with some conflicts). After a while I just gave up on this (I don't have the time to fix it all in one day), so for me the po system actually works counterproductive... What I want to say here is that if that if you want to get some small fixes in without actually knowing the language you're working on (like Francois), please don't send separate patches every few days, because that's really annoying. Just send them all at once, or just let translators fix it. Or at least set a string freeze, after which people who are actual translators can translate strings. @Matijn, please go ahead and update the Dutch translation. Sven You may be right on that, especially because there are translators that don't know how to fix things after their patch --merge fails. I didn't start too because I thought that it might conflict with Francois patches too. Francois: The untranslated errors at the consistency are almost all because of the use of english words in dutch. Would it be OK if I send you the L numbers that can have # potool-flags=translated so you can send a patch? - Matijn
Re: Problems with translatable strings
Ok, that's good :) I'm editing the resource files to adjust the size of the widgets. I'll send the patches in a minute. Gustavo Em 16 de fevereiro de 2012 20:42, Francois Gouget fgou...@free.frescreveu: On Tue, 14 Feb 2012, Gustavo Henrique Milaré wrote: [...] while the string in wine.pot file reads Allows you to install new software, or remove existing software from your computer. Just in case you missed it, this got fixed: http://bugs.winehq.org/show_bug.cgi?id=27246 -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.
Re: [PATCH] server: Add sessions directory and 0 session symlink
On 02/16/2012 08:37 PM, Vitaliy Margolen wrote: Fixes bug 29905. --- Please ignore this. Didn't read the last bug comment. Vitaliy.
Re: [1/3] comdlg32: Adjust the size of CHOOSE_COLOR dialog.
Gustavo Henrique Milaré gugamil...@gmail.com wrote: Adjusting size for the translation to fit. You can't do that, read the comment in that file slightly before all common dialog templates. -- Dmitry.
Re: [2/2] kernel32/tests: DeviceIoControl.IOCTL_DVD_READ_STRUCTURE.DvdPhysicalDescriptor: check output buffer byte order (try 4)
On Wed, Feb 15, 2012 at 4:35 PM, Dan Kegel d...@kegel.com wrote: Change since last try: - moved back to kernel32 per AJ's remark on irc - runs even if dvd in 2nd... drive - simplified Passes on Wine/Linux, Wine/Mac (according to Charles), and Win7. Here's the same patch with the wayward utf-8 char removed from the standards comment. Please ignore this patch. I simplified too far; it has a structure packing problem that only shows up in crosstest on windows. I sent an updated series to Charles for testing.
Re: Translators wanted!
On Fri, 17 Feb 2012, Sven Baars wrote: On 16-02-2012 at 7:55 PM, Matijn Woudt tijn...@gmail.com wrote: I'd like to help get the dutch translation to 100%, but I would need to filter out the false positives first. I started with this a while ago, but every time I was nearly done, more translations were marked as fuzzy, more strings were introduced, and usually Francois changed some strings, which meant that I had to manually apply the patch I was working on (with some conflicts). After a while I just gave up on this (I don't have the time to fix it all in one day), so for me the po system actually works counterproductive... What I want to say here is that if that if you want to get some small fixes in without actually knowing the language you're working on (like Francois), please don't send separate patches every few days, because that's really annoying. That's what I've been trying to do. For the Dutch translation I only sent one round of patches in September (before the conversion of the dialogs to PO files), one after all the dialogs where converted on the 19th of January, two single translation ones on the 23rd and 24th that were unlikely to cause any conflicts, and this round. Now I did fix English strings as I found issues with them more often. But those impact all translators so no matter when I send them in they will cause conflicts for one translator. So there's no point in delaying those. That said I'm willing to help translators that have trouble resolving conflicts with their translations. Just send them all at once, or just let translators fix it. Or at least set a string freeze, after which people who are actual translators can translate strings. You're in luck, we are in string freeze since the beginning of the week. -- Francois Gouget fgou...@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.
Re: Translators wanted!
On Fri, 17 Feb 2012, Matijn Woudt wrote: [...] Francois: The untranslated errors at the consistency are almost all because of the use of english words in dutch. Would it be OK if I send you the L numbers that can have # potool-flags=translated so you can send a patch? Line numbers are unreliable. Send me the msgids instead. So for instance if the following in the report is a false positive: L339:[translated]: not translated: 'Help' msgid Help msgstr Help Then tell me: msgid Help is a false positive -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Vote Electronique: Les gens qui votent ne décident rien. Ceux qui comptent les votes décident de tout.
Re: [1/3] comdlg32: Adjust the size of CHOOSE_COLOR dialog.
On Fri, 17 Feb 2012, Dmitry Timoshkov wrote: Gustavo Henrique Milaré gugamil...@gmail.com wrote: Adjusting size for the translation to fit. You can't do that, read the comment in that file slightly before all common dialog templates. That comment would deserve some explanation (the b96b3d15 commit message does no provide that explanation either). What are our next options? Can the control be resized just enough without changing the overall dialog size? -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
Re: kernel32/tests: initial tests for cdrom.c
On Fri, 10 Feb 2012, joerg-cyril.hoe...@t-systems.com wrote: Dan Kegel wrote: These require a DVD in the drive, so they are skipped without WINETEST_INTERACTIVE=1. I don't see the causality. Presumably the tests require no human intervention. winmm/tests/mcicda also skips tests if no CD-ROM is in the bay. However, even a regular winetest.exe run *will* run as many tests as it can should it find a CD-ROM. Users are invited to submit test results to test.winehq with audio and/or mixed data CD-ROMs in the drive. Any such instructions on how to run WineTest should be mentioned on the page below, which is not the case here: http://wiki.winehq.org/ConformanceTests Are there tests that are impossible if there is a CD in the drive? -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
