Re: [1/2] user32: Add a bunch of RealChildWindowFromPoint tests.

[Dmitry Timoshkov]

Alexandre Julliard  wrote:

> > win.c:6753: Test failed: FlashWindowEx succeeded
> > win.c:6764: Test failed: FlashWindowEx failed with -559038737
> >
> > are intermittent, and have nothing to do with these tests.
> 
> Maybe not directly, but the failures are clearly caused by your change,
> and they look pretty bad on the test results. Please fix that.

Something is wrong with the test itself, some machines still fail,
some pass it. And of course the tests pass here and on the test bot...
Perhaps increasing timeout to 500 or even 1000 may help?

-- 
Dmitry.

Re: po: Remove untranslated English strings from the Romanian translation

[Frédéric Delanoy]

On Tue, Feb 7, 2012 at 13:39, Michael Stefaniuc  wrote:
> Francois Gouget wrote:
>> On Tue, 7 Feb 2012, Michael Stefaniuc wrote:
>> [...]
  #: regedit.rc:282
  msgid "Hexadecimal"
 -msgstr "Hexadecimal"
 +msgstr ""

  #: regedit.rc:283
  msgid "Decimal"
 -msgstr "Decimal"
 +msgstr ""
>>> Those aren't untranslated but the Romanian words match the English ones.
>>
>> Are you sure? If I look at Wikipedia it looks like they're spelled
>> Hexazecimal and Zecimal respectively:
> Of course I'm sure until proven wrong! ;)
>
>> http://ro.wikipedia.org/wiki/Sistem_zecimal
> I could swear to have never seen that word before. But I left Romania 20
> years ago so things might have changed.
>
>        michael

Google translate gives decimal => zecimal and hexadecimal => hexazecimal
Same for wikipedia, dictionarenglezroman.ro and a couple other
dictionaries (sensagent, ...)
http://dictionare.com/phpdic/enro40.php?field0=decimal gives both versions

Babylon gave me "zecimala" and "hexazecimal"

I don't know what's the reference Romanian dictionary, so make your
choice and tell me...

Or maybe Octavian Voicu also speaks Romanian? That name sounded
Romanian to me for some reason ;)

Frédéric

winealsa.drv patch to enum all software devices from .asoundrc

[Нискородов Серёжа]

Hi, all.

I'm not so good at programming. I just was looking for a way to
make possible play sound from WINE to ALSA software device other than
"default".

I wrote a patch that allows you to select the ALSA software device
from control panel, along with the hardware devices.

Perhaps the code is not so clear and beautiful, but it works for me,
and maybe someone wants to send it to the repository, or to correct
and send a corrected.


alsa_enum_all.diff
Description: Binary data

Re: po: Fix some trailing ellipses errors in Catalan translation

[Frédéric Delanoy]

2012/2/7 Alex Henrie :
>  #: ieframe.rc:68 winhlp32.rc:66
>  msgid "Print..."
> -msgstr "Imprimeix"
> +msgstr "Imprimeix..."
>
> I intentionally left the ellipse off of the word "Imprimeix" in
> Internet Explorer so that the text would fit on the toolbar button.
> Any suggestions?
>
> -Alex

The ellipsis is a standard "naming convention" for button labels which
present another dialog to the user, so the ellipsis needs to stay.
The size issue occurs in many (most?) languages (checked 4 of them),
so this would probably need larger icons anyway.

Frédéric

Re: po: Fix some trailing ellipses errors in Catalan translation

[Francois Gouget]

On Tue, 7 Feb 2012, Alex Henrie wrote:

>  #: ieframe.rc:68 winhlp32.rc:66
>  msgid "Print..."
> -msgstr "Imprimeix"
> +msgstr "Imprimeix..."
> 
> I intentionally left the ellipse off of the word "Imprimeix" in
> Internet Explorer so that the text would fit on the toolbar button.
> Any suggestions?

The ellipses are important. 'Print...' tells the user that a dialog will 
be opened where he will be asked for details and have the oportunity to 
cancel before the print job is actually launched. 'Print' on the other 
hand means the print job will be sent right away to the default printer.

http://msdn.microsoft.com/en-us/library/aa511453.aspx#ellipses

So the ellipses can never be removed or added in translations.


So the solution is to tweak the dialog to make the button larger. Given 
that in French that translation is 'Imprimer...', such a change would 
probably be beneficial there too.

-- 
Francois Gouget   http://fgouget.free.fr/
 Stolen from an Internet user:
  "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

Re: po: Fix some trailing ellipses errors in Catalan translation

[Alex Henrie]

 #: ieframe.rc:68 winhlp32.rc:66
 msgid "Print..."
-msgstr "Imprimeix"
+msgstr "Imprimeix..."

I intentionally left the ellipse off of the word "Imprimeix" in
Internet Explorer so that the text would fit on the toolbar button.
Any suggestions?

-Alex

Re: po: Update finnish locales

[Lauri Kenttä]

On 2012-02-06 23:00, Olli-Pekka Wallin wrote:

+msgstr "KB/s"
...
+msgstr "Yksi sivua"
...
+msgstr "Wordpad ojelman käynnistys epäonnistui"


I'm sorry to say this, but these translations are really bad. I suggest 
you either have someone check your translations thoroughly before 
submitting or leave the whole job for others. (I'm already working on 
it.)


The patch is also based on an old revision and changes a msgid.

--
Lauri Kenttä

Re: [1/2] user32: Add a bunch of RealChildWindowFromPoint tests.

[Alexandre Julliard]

Dmitry Timoshkov  writes:

> win.c:6753: Test failed: FlashWindowEx succeeded
> win.c:6764: Test failed: FlashWindowEx failed with -559038737
>
> are intermittent, and have nothing to do with these tests.

Maybe not directly, but the failures are clearly caused by your change,
and they look pretty bad on the test results. Please fix that.

-- 
Alexandre Julliard
julli...@winehq.org

Re: SourceForge forbids download

[Marcus Meissner]

On Mon, Feb 06, 2012 at 10:31:01PM +0330, Aidin Gharibnavaz wrote:
> Dear Wine developers,
> 
> SourceForge blocked download for some countries by default, such as Iran.
> (More detail can be found
> here
> )
> 
> So, if it's not illegal to you to let Iranians download your software,
> please go to the SourceForge's ProjectAdmin, and set the ExportControl
> option, to let us enjoy the great work of yours.

Wine does contain cryptographic algorithms which are object to US export
control, so making it available for all from sourceforge would make SF
and us liable.

That said, there might be more than just the SourceForge download page
to get Wine sources which do not enforce Iran blocking, see
http://www.winehq.org/download/
for some links to try.

Ciao, Marcus

Re: po: Remove untranslated English strings from the Romanian translation

[Michael Stefaniuc]

Francois Gouget wrote:
> On Tue, 7 Feb 2012, Michael Stefaniuc wrote:
> [...]
>>>  #: regedit.rc:282
>>>  msgid "Hexadecimal"
>>> -msgstr "Hexadecimal"
>>> +msgstr ""
>>>  
>>>  #: regedit.rc:283
>>>  msgid "Decimal"
>>> -msgstr "Decimal"
>>> +msgstr ""
>> Those aren't untranslated but the Romanian words match the English ones.
> 
> Are you sure? If I look at Wikipedia it looks like they're spelled 
> Hexazecimal and Zecimal respectively:
Of course I'm sure until proven wrong! ;)

> http://ro.wikipedia.org/wiki/Sistem_zecimal
I could swear to have never seen that word before. But I left Romania 20
years ago so things might have changed.

> That said I'm all ears for false positives to improve the Wine-PO 
> reports.

> http://fgouget.free.fr/wine-po/

bye
michael

Re: SourceForge forbids download

[Juan Lang]

Hi Aidin,

On Mon, Feb 6, 2012 at 11:01 AM, Aidin Gharibnavaz  wrote:
> SourceForge blocked download for some countries by default, such as Iran.
> (More detail can be found here)
>
> So, if it's not illegal to you to let Iranians download your software,
> please go to the SourceForge's ProjectAdmin, and set the ExportControl
> option, to let us enjoy the great work of yours.

While it may or not be illegal, and I am not a lawyer, I believe it
isn't legal to allow a download from the US without having applied for
a review first:
http://www.bis.doc.gov/encryption/encfaqs6_17_02.html

Wine includes general encryption algorithms, not just authentication,
and doesn't have restrictions on key length.  While many of the
cryptographic primitives were obtained from freely-available source
code, I don't know whether things like certificate verification fall
under the review requirements.

Hence, I don't believe that we can enable downloads from Iran on
SourceForge.  It's entirely possible to get the Wine source via other
means, however.

Sorry for the hassle.
--Juan

Re: po: Remove untranslated English strings from the Romanian translation

[Francois Gouget]

On Tue, 7 Feb 2012, Michael Stefaniuc wrote:
[...]
> >  #: regedit.rc:282
> >  msgid "Hexadecimal"
> > -msgstr "Hexadecimal"
> > +msgstr ""
> >  
> >  #: regedit.rc:283
> >  msgid "Decimal"
> > -msgstr "Decimal"
> > +msgstr ""
> Those aren't untranslated but the Romanian words match the English ones.

Are you sure? If I look at Wikipedia it looks like they're spelled 
Hexazecimal and Zecimal respectively:

http://ro.wikipedia.org/wiki/Sistem_zecimal

That said I'm all ears for false positives to improve the Wine-PO 
reports.

http://fgouget.free.fr/wine-po/

-- 
Francois Gouget   http://fgouget.free.fr/
  Computers are like airconditioners
They stop working properly if you open WINDOWS

Re: po: Update finnish locales

[Francois Gouget]

On Mon, 6 Feb 2012, Olli-Pekka Wallin wrote:

> po: Update finnish locales
> 
>  #: appwiz.rc:49
>  msgid "Installing..."
> -msgstr ""
> +msgstr "Asennetaan.."

It looks like there's a missing dot here.
But thanks a lot for the patch. Feel free to tackle any other issue in:
http://fgouget.free.fr/wine-po/fi-errors.html

Also don't hesitate to let me know about false positives so I can 
silence them.

-- 
Francois Gouget   http://fgouget.free.fr/
  Any sufficiently advanced bug is indistinguishable from a feature.
-- from some indian guy

Re: po: Remove untranslated English strings from the Romanian translation

[Michael Stefaniuc]

Hello Frédéric,

the patch is wrong.

Frédéric Delanoy wrote:
> ---
>  po/ro.po |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/po/ro.po b/po/ro.po
> index a0912c2..c9375c4 100644
> --- a/po/ro.po
> +++ b/po/ro.po
> @@ -11803,11 +11803,11 @@ msgstr "Bază"
>  
>  #: regedit.rc:282
>  msgid "Hexadecimal"
> -msgstr "Hexadecimal"
> +msgstr ""
>  
>  #: regedit.rc:283
>  msgid "Decimal"
> -msgstr "Decimal"
> +msgstr ""
Those aren't untranslated but the Romanian words match the English ones.

>  #: regedit.rc:290
>  msgid "Edit Binary"
> @@ -13243,7 +13243,7 @@ msgstr "Afișează opțiunile a&vansate"
>  
>  #: winecfg.rc:240
>  msgid "De&vice:"
> -msgstr "De&vice:"
> +msgstr ""
>  
>  #: winecfg.rc:242
>  msgid "Bro&wse..."

bye
michael

Re: ID3DXBaseEffect::SetValue

[luis.busqu...@ilidium.com]

For the textures point, it is judt that the implemenyation is just the change 
of one pointer

- Reply message -
De: "Rico Schüller" 
Para: "Luis Carlos Busquets Pérez" 
CC: 
Asunto: ID3DXBaseEffect::SetValue
Fecha: mar., feb. 7, 2012 10:03


Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez:
> 1. If the functions returns E_FAIL for a sample then
> test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK)
I'll have a look at those.
> 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL
> avoids
>test_effect.c:1812: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)
>test_effect.c:1814: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)
>test_effect.c:1881: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)
Sure, that's not implemented, yet. You should get a FIXME for those cases.
> 3. If the function just sets the memory with the data for a bool then
> test_effect.c:969: Test failed: Got 46, expected 1
In this case it may be required, that the input has to be converted 
before it is put into data. A solution would be to use Set*Array to set 
the values. In general, I think it's also fine to convert the values in 
get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) 
- I'll send a patch for this. But I also think a test to show, that the 
value is converted while it is set, is still the way to go. Well 
SetValue isn't complete, yet.
> 5. Concerning textures, the compiler does not accept arrays of textures,
> so any change to a texture type should be just a change of the pointer
> to the texture at param->data (or NULL)
I didn't got the point. Only that it is impossible to declare texture 
arrays in effect files, which I could confirm.
Do you mean, that the HeapAlloc for the additional pointer for textures 
should be avoided? This could be done, it just needs separate handling 
for textures. As it is now, it mostly uses the same handling together 
with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)).

Cheers
Rico

Re: ID3DXBaseEffect::SetValue

[luis.busqu...@ilidium.com]

Concerning the vertrd a picel shadet, the truth is that sin e very soon in the 
history of d3dx the functions ID3DXEffect::SetPixelShader and 
ID3DXEffect::DetVertexShader wete removed. So actually it does not seem that 
you can change them. Because of that, the MS implementation replies with 
D3DERR_INVALIDCALL and their implementation in SetValue is straight.

- Reply message -
De: "Rico Schüller" 
Para: "Luis Carlos Busquets Pérez" 
CC: 
Asunto: ID3DXBaseEffect::SetValue
Fecha: mar., feb. 7, 2012 10:03


Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez:
> 1. If the functions returns E_FAIL for a sample then
> test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK)
I'll have a look at those.
> 2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL
> avoids
>test_effect.c:1812: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)
>test_effect.c:1814: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)
>test_effect.c:1881: Test failed: Got result 0, expected 0x80004005
> (E_FAIL)
Sure, that's not implemented, yet. You should get a FIXME for those cases.
> 3. If the function just sets the memory with the data for a bool then
> test_effect.c:969: Test failed: Got 46, expected 1
In this case it may be required, that the input has to be converted 
before it is put into data. A solution would be to use Set*Array to set 
the values. In general, I think it's also fine to convert the values in 
get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) 
- I'll send a patch for this. But I also think a test to show, that the 
value is converted while it is set, is still the way to go. Well 
SetValue isn't complete, yet.
> 5. Concerning textures, the compiler does not accept arrays of textures,
> so any change to a texture type should be just a change of the pointer
> to the texture at param->data (or NULL)
I didn't got the point. Only that it is impossible to declare texture 
arrays in effect files, which I could confirm.
Do you mean, that the HeapAlloc for the additional pointer for textures 
should be avoided? This could be done, it just needs separate handling 
for textures. As it is now, it mostly uses the same handling together 
with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)).

Cheers
Rico

Re: comctl32: Remove an obsolete resource attribute.

[Michael Stefaniuc]

Marvin wrote:
> 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=16849
> 
> Your paranoid android.
> 
> 
> === WNT4WSSP6 (32 bit) ===
> No test summary line found
WTB is confused by the change to a non-c file and didn't run any tests.

bye
michael

Re: comctl32: Remove an obsolete resource attribute.

[Marvin]

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=16849

Your paranoid android.


=== WNT4WSSP6 (32 bit) ===
No test summary line found

=== W2KPROSP4 (32 bit) ===
No test summary line found

=== WXPPROSP3 (32 bit) ===
No test summary line found

=== W2K3R2SESP2 (32 bit) ===
No test summary line found

=== WVISTAADM (32 bit) ===
No test summary line found

=== W2K8SE (32 bit) ===
No test summary line found

=== W7PRO (32 bit) ===
No test summary line found

=== W7PROX64 (32 bit) ===
No test summary line found

=== TEST64_W7SP1 (32 bit) ===
No test summary line found

=== W7PROX64 (64 bit) ===
No test summary line found

=== TEST64_W7SP1 (64 bit) ===
No test summary line found

Re: ID3DXBaseEffect::SetValue

[Rico Schüller]

Am 07.02.2012 06:02, schrieb Luis Carlos Busquets Pérez:

1. If the functions returns E_FAIL for a sample then
test_effect.c:1917: Test failed: Got result 80004005, expected 0 (D3D_OK)

I'll have a look at those.

2. For D3DXPT_VERTEXSHADER and D3DXPT_PIXELSHADER replying with E_FAIL
avoids
   test_effect.c:1812: Test failed: Got result 0, expected 0x80004005
(E_FAIL)
   test_effect.c:1814: Test failed: Got result 0, expected 0x80004005
(E_FAIL)
   test_effect.c:1881: Test failed: Got result 0, expected 0x80004005
(E_FAIL)

Sure, that's not implemented, yet. You should get a FIXME for those cases.

3. If the function just sets the memory with the data for a bool then
test_effect.c:969: Test failed: Got 46, expected 1
In this case it may be required, that the input has to be converted 
before it is put into data. A solution would be to use Set*Array to set 
the values. In general, I think it's also fine to convert the values in 
get_int() and get_float() in the case of D3DXPT_BOOL with get_bool(data) 
- I'll send a patch for this. But I also think a test to show, that the 
value is converted while it is set, is still the way to go. Well 
SetValue isn't complete, yet.

5. Concerning textures, the compiler does not accept arrays of textures,
so any change to a texture type should be just a change of the pointer
to the texture at param->data (or NULL)
I didn't got the point. Only that it is impossible to declare texture 
arrays in effect files, which I could confirm.
Do you mean, that the HeapAlloc for the additional pointer for textures 
should be avoided? This could be done, it just needs separate handling 
for textures. As it is now, it mostly uses the same handling together 
with the shaders (e.g. IUnknown_Release(*(IUnknown **)param->data)).


Cheers
Rico