Re: [PATCH 3/3] d3d9/tests: More D3DTSS_TEXTURETRANSFORMFLAGS projection tests.
2012/1/14 Saulius Krasuckas : > * On Tue, 27 Dec 2011, Matteo Bruni wrote: >> --- >> dlls/d3d9/tests/visual.c | 388 >> -- >> 1 files changed, 269 insertions(+), 119 deletions(-) > > Hello Matteo, > > this is > http://source.winehq.org/git/wine.git/commitdiff/8dee7989f242b8ea624abc3b1fe929494d1fd329 > > The patch removed 6 failures on XP on real hardware (nVidia FX5200): > http://test.winehq.org/data/18c20964e1e22f9aa974cc774bf77da6fc013716/xp_s2-sp2-nosound/d3d9:visual.html > > visual.c:4057: Test failed: proj: Pixel 162/122 has color 0x, > expected 0x00FF > visual.c:4062: Test failed: proj: Pixel 158/178 has color 0x, > expected 0x00FF > visual.c:4069: Test failed: proj: Pixel 318/118 has color 0x00ff, > expected 0x > visual.c:4071: Test failed: proj: Pixel 322/118 has color 0x00ff, > expected 0x > visual.c:4075: Test failed: proj: Pixel 322/122 has color 0x00ff, > expected 0x > visual.c:4078: Test failed: proj: Pixel 318/178 has color 0x, > expected 0x00FF > > and introduced 14 new ones: > http://test.winehq.org/data/277361d7be206e1ff7634998f0d750f7c6d66498/xp_s2-sp2-nosound/d3d9:visual.html > > visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom > right: Pixel (401, 361) has color , expected 00ff > visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom > right: Pixel (401, 419) has color , expected 00ff > visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom > right: Pixel (481, 359) has color 00ff, expected > visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom > right: Pixel (481, 361) has color 00ff, expected > visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom > right: Pixel (479, 359) has color 00ff, expected > visual.c:3729: Test failed: D3DTTFF_COUNT3 | D3DTTFF_PROJECTED - bottom > right: Pixel (479, 419) has color , expected 00ff > visual.c:3729: Test failed: D3DTTFF_PROJECTED (like COUNT3 | PROJECTED, > texcoord has only 3 components) - bottom right: Pixel (401, 361) has color > , expected 00ff > visual.c:3729: Test failed: D3DTTFF_PROJECTED (like COUNT3 | PROJECTED, > texcoord has only 3 components) - bottom right: Pixel (401, 419) has color > , expected 00ff > visual.c:3729: Test failed: D3DTTFF_PROJECTED (like COUNT3 | PROJECTED, > texcoord has only 3 components) - bottom right: Pixel (479, 361) has color > , expected 00ff > visual.c:3729: Test failed: D3DTTFF_PROJECTED (like COUNT3 | PROJECTED, > texcoord has only 3 components) - bottom right: Pixel (479, 419) has color > , expected 00ff > visual.c:3729: Test failed: 0x (like COUNT3 | PROJECTED, texcoord has > only 3 components) - top left: Pixel (81, 121) has color , expected > 00ff > visual.c:3729: Test failed: 0x (like COUNT3 | PROJECTED, texcoord has > only 3 components) - top left: Pixel (81, 179) has color , expected > 00ff > visual.c:3729: Test failed: 0x (like COUNT3 | PROJECTED, texcoord has > only 3 components) - top left: Pixel (159, 121) has color , expected > 00ff > visual.c:3729: Test failed: 0x (like COUNT3 | PROJECTED, texcoord has > only 3 components) - top left: Pixel (159, 179) has color , expected > 00ff > > The same machine running Win7 didn't exhibit any changes: > http://test.winehq.org/data/18c20964e1e22f9aa974cc774bf77da6fc013716/win7_s2-enterprise-32-VAS/d3d9:visual.html > http://test.winehq.org/data/277361d7be206e1ff7634998f0d750f7c6d66498/win7_s2-enterprise-32-VAS/d3d9:visual.html > > This probably has something to do with older nVidia driver version being > used on Win7 - v96.85 - than the version used on XP - v163.75 . > > But on Win7 somewhat similar change is seen on virtual machine from > Francois, only the failure count increases by 28 here: > http://test.winehq.org/data/18c20964e1e22f9aa974cc774bf77da6fc013716/win7_fg-win7u64-1spie9-ja/d3d9:visual.html > http://test.winehq.org/data/277361d7be206e1ff7634998f0d750f7c6d66498/win7_fg-win7u64-1spie9-ja/d3d9:visual.html > > Would you mind fixing this please:)? > > S. > > I somehow expected some test failures, since this is really testing "invalid" d3d9 states combinations. Those results show that there are some minor discrepancies with the actual output on the screen, but the bottom line is that invalid settings still work, which was the main objective of the tests. So adding some broken() around is probably okay. I'll send a patch. So, I was more or less expecting this and I did already notice the test failures, but thanks for the nice summary and heads up ;) I think I'll just ignore the virtual machine test failures: too many tests are failing already and I don't think those results are interesting anyway.
Re: richedit: v1.0 richedit uses CR and LF for enter
> Whats the difference between a typecast and &var[0]? I wasn't advocating for a typecast, merely admitting that we use them from time to time. What's the compile warning you're actually seeing on gcc? I don't think we care what warnings are produced in MSVC. --Juan
Re: richedit: v1.0 richedit uses CR and LF for enter
> > > This was deliberate - I did that originally and I got a compile warning > as > > one is const WCHAR * and one is const WCHAR[2] (Not sure if that error > was > > from a MSVC windows or Linux compile, but I was trying to avoid it, and a > > typecast was a bit pointless as the above is accurate as well, isnt it?) > > You could declare it non-const. That's often what we end up doing in > the tests, that or casting away the const. > > Whats the difference between a typecast and &var[0]? Jason
Re: richedit: v1.0 richedit uses CR and LF for enter
> This was deliberate - I did that originally and I got a compile warning as > one is const WCHAR * and one is const WCHAR[2] (Not sure if that error was > from a MSVC windows or Linux compile, but I was trying to avoid it, and a > typecast was a bit pointless as the above is accurate as well, isnt it?) You could declare it non-const. That's often what we end up doing in the tests, that or casting away the const. --Juan
Re: richedit: v1.0 richedit uses CR and LF for enter
2012/1/18 Juan Lang > Hi Jason, > > + ME_InsertTextFromCursor(editor, 0, &endlv10[0], 2, style); > > you want to use endlv10 instead, i.e.: > > + ME_InsertTextFromCursor(editor, 0, endlv10, 2, style); > --Juan > This was deliberate - I did that originally and I got a compile warning as one is const WCHAR * and one is const WCHAR[2] (Not sure if that error was from a MSVC windows or Linux compile, but I was trying to avoid it, and a typecast was a bit pointless as the above is accurate as well, isnt it?) Jason
Re: [SOLVED] Debugging Wine with Lightroom 3.5
On 01/18/2012 10:10 PM, Roland Baudin wrote: You can find the attached complete patch against wine 1.3.35. Hello Roland, Please send patches to wine-patches. Unless you are asking for feedback? HTH, Joris
Re: [SOLVED] Debugging Wine with Lightroom 3.5
Hi, I finally solved the menubar issue (menubar not shown in Lightroom 3.x when Windows version is set to Windows XP or below). I used a mix of the following patches : - http://source.winehq.org/patches/data/67089 from Andrew Eikum (GetMenuBarInfo() partial implementation) - http://www.winehq.org/pipermail/wine-patches/2006-April/026075.html from Thomas Kho (Fix GetMenuItemRect() for top-level menus) You can find the attached complete patch against wine 1.3.35. Have a nice day, RB Le 20/12/2011 12:28, Frédéric Delanoy a écrit : On Tue, Dec 20, 2011 at 10:04, wrote: Yes, I'm that kind of person (I'm the developer of Xfe and TexMaths) but I've seen the +relay logs logs and they are indeed very huge, even for me! RB What you can do to reduce/manage the log size: 1. Launch any application (without logging), e.g. notepad, so the wine startup doesn't produce (much) output 2. Run your app with the wine debugger to help with debug output control http://www.winehq.org/docs/winedev-guide/dbg-commands#WINEDBG-DBG-CHAN http://www.winehq.org/docs/winedev-guide/dbg-control I think those links might help. Frédéric -- X File Explorer http://roland65.free.fr/xfe Toutes Choses http://roland65.free.fr/ttc getmenubarinfo.patch.gz Description: GNU Zip compressed data
Re: "Sound" keyword on bugzilla
On Wed, Jan 18, 2012 at 07:03:24PM +, Jerome Leclanche wrote: > Any comments? > Seems like a useful idea to me, though I'd defer to the heavier Bugzilla users' opinions. Andrew > On Tue, Jan 17, 2012 at 1:09 AM, Jerome Leclanche wrote: > > > Hi, > > > > Joerg and I exchanged a couple of emails where I proposed a "sound" > > keyword on bugzilla. Reasoning: there are multiple sound components, and > > most of the time, the correct component is unknown (or could even be caused > > by non-sound components). > > > > Thoughts? > > > > J. Leclanche > > >
Re: "Sound" keyword on bugzilla
Any comments? J. Leclanche On Tue, Jan 17, 2012 at 1:09 AM, Jerome Leclanche wrote: > Hi, > > Joerg and I exchanged a couple of emails where I proposed a "sound" > keyword on bugzilla. Reasoning: there are multiple sound components, and > most of the time, the correct component is unknown (or could even be caused > by non-sound components). > > Thoughts? > > J. Leclanche >
Re: richedit: v1.0 richedit uses CR and LF for enter
Hi Jason, + ME_InsertTextFromCursor(editor, 0, &endlv10[0], 2, style); you want to use endlv10 instead, i.e.: + ME_InsertTextFromCursor(editor, 0, endlv10, 2, style); --Juan
Re: winex11.drv: Strip the _XXX from X11DRV_GetKeyNameText when approperate
On 1/17/12 10:18 PM, Vitaliy Margolen wrote:
On 01/17/2012 09:32 AM, Aric Stewart wrote:
The problem is that there is no XK keycode for just Shift, Control or Menu
so X11DRV_MapVirtualKeyEx maps them to Shift_L, etc. As a result the string
XKeysymToString returns is a string with a _L or _R at the end, even if the
"don't care" bit is set.
+char *new_name;
+INT rc = 0;
+new_name = HeapAlloc(GetProcessHeap(),0,(idx-name)+1);
+lstrcpynA(new_name,name,(idx-name)+1);
+new_name[idx-name] = 0;
+TRACE("found scan=%04x keyc=%u keysym=%04x new_string=%s\n",
+ scanCode, keyc, (int)keys, new_name);
+if (lpBuffer&& nSize)
+rc = MultiByteToWideChar(CP_UNIXCP, 0, new_name, -1,
lpBuffer, nSize);
+HeapFree(GetProcessHeap(),0,new_name);
+return rc;
I don't think you need an extra buffer. Just do something like:
if (lpBuffer&& nSize)
{
rc = MultiByteToWideChar(CP_UNIXCP, 0, new_name, idx - name, lpBuffer,
nSize);
if (nSize> idx - name)
lpBuffer[idx - name] = 0;
}
Of course need to account for rc.
Vitaliy
Can't really use idx after the MultiByteToWideChar but I could possibly
use rc.
I will investigate quick.
-aric
Re: comdlg32: Remove the font sample characters string.
2012/1/18 Michael Stefaniuc : > And what Francois is saying is that that isn't possible as the string > depends on the font and not on the UI language. So if I select a Klingon > font that has no latin characters I won't be able to see the "AaBbYyZz". > > bye > michael OK. Got it. Must have sounded Klingon to me somehow ;) Frédéric
Re: comdlg32: Remove the font sample characters string.
Frédéric Delanoy wrote:
> 2012/1/18 Francois Gouget :
>> On Wed, 18 Jan 2012, Frédéric Delanoy wrote:
>>
>>> On Wed, Jan 18, 2012 at 10:12, Francois Gouget wrote:
The sample text does not depend on the dialog language but on the scripts
supported by the font. As such translating it in the resource file makes
no sense.
-CTEXT "AaBbYyZz",stc5,103,80,109,24,SS_NOPREFIX | NOT
WS_VISIBLE
+CTEXT "",stc5,103,80,109,24,SS_NOPREFIX | NOT WS_VISIBLE
>>> Actually it's used to show a sample in the font picker (e.g. with
>>> wordpad do Format > Font).
>> No it's not. The code overwrites this string when drawing the dialog and
>> then based on the entry selected in the 'Script:' combobox (cmb5). See
>> CFn_WMPaint():
>>
>>if( GetWindowInfo( GetDlgItem( hDlg, stc5), &info ) )
>>{
>> ...
>>DrawTextW( hdc,
>>sample_lang_text[CHARSET_ORDER[lpcf->lpLogFont->lfCharSet]],
>>-1, &info.rcWindow, DT_CENTER|DT_VCENTER|DT_SINGLELINE );
>> ...
>>
>> So the string which is in the resource file is useless and only causes
>> grief.
>
> That's why I later added:
>
> "If the sample text does not depend on the dialogue language, that's
> what should be done instead IMHO"
>
> i.e. alter the code so it does use the (translatable) string instead
> of removing it altogether.
And what Francois is saying is that that isn't possible as the string
depends on the font and not on the UI language. So if I select a Klingon
font that has no latin characters I won't be able to see the "AaBbYyZz".
bye
michael
Re: comdlg32: Remove the font sample characters string.
2012/1/18 Francois Gouget :
> On Wed, 18 Jan 2012, Frédéric Delanoy wrote:
>
>> On Wed, Jan 18, 2012 at 10:12, Francois Gouget wrote:
>> > The sample text does not depend on the dialog language but on the scripts
>> > supported by the font. As such translating it in the resource file makes
>> > no sense.
>> > - CTEXT "AaBbYyZz",stc5,103,80,109,24,SS_NOPREFIX | NOT
>> > WS_VISIBLE
>> > + CTEXT "",stc5,103,80,109,24,SS_NOPREFIX | NOT WS_VISIBLE
>>
>> Actually it's used to show a sample in the font picker (e.g. with
>> wordpad do Format > Font).
>
> No it's not. The code overwrites this string when drawing the dialog and
> then based on the entry selected in the 'Script:' combobox (cmb5). See
> CFn_WMPaint():
>
> if( GetWindowInfo( GetDlgItem( hDlg, stc5), &info ) )
> {
> ...
> DrawTextW( hdc,
> sample_lang_text[CHARSET_ORDER[lpcf->lpLogFont->lfCharSet]],
> -1, &info.rcWindow, DT_CENTER|DT_VCENTER|DT_SINGLELINE );
> ...
>
> So the string which is in the resource file is useless and only causes
> grief.
That's why I later added:
"If the sample text does not depend on the dialogue language, that's
what should be done instead IMHO"
i.e. alter the code so it does use the (translatable) string instead
of removing it altogether.
I should have been clearer in my initial reply, though.
Frédéric
Re: comdlg32: Remove the font sample characters string.
On Wed, 18 Jan 2012, Frédéric Delanoy wrote:
> On Wed, Jan 18, 2012 at 10:12, Francois Gouget wrote:
> > The sample text does not depend on the dialog language but on the scripts
> > supported by the font. As such translating it in the resource file makes no
> > sense.
> > - CTEXT "AaBbYyZz",stc5,103,80,109,24,SS_NOPREFIX | NOT
> > WS_VISIBLE
> > + CTEXT "",stc5,103,80,109,24,SS_NOPREFIX | NOT WS_VISIBLE
>
> Actually it's used to show a sample in the font picker (e.g. with
> wordpad do Format > Font).
No it's not. The code overwrites this string when drawing the dialog and
then based on the entry selected in the 'Script:' combobox (cmb5). See
CFn_WMPaint():
if( GetWindowInfo( GetDlgItem( hDlg, stc5), &info ) )
{
...
DrawTextW( hdc,
sample_lang_text[CHARSET_ORDER[lpcf->lpLogFont->lfCharSet]],
-1, &info.rcWindow, DT_CENTER|DT_VCENTER|DT_SINGLELINE );
...
So the string which is in the resource file is useless and only causes
grief.
--
Francois Gouget http://fgouget.free.fr/
A polar bear is a cartesian bear after a coordinate transform.
Re: comdlg32: Remove the font sample characters string.
On Wed, Jan 18, 2012 at 10:12, Francois Gouget wrote: > The sample text does not depend on the dialog language but on the scripts > supported by the font. As such translating it in the resource file makes no > sense. > - CTEXT "AaBbYyZz",stc5,103,80,109,24,SS_NOPREFIX | NOT > WS_VISIBLE > + CTEXT "",stc5,103,80,109,24,SS_NOPREFIX | NOT WS_VISIBLE Actually it's used to show a sample in the font picker (e.g. with wordpad do Format > Font). I translated it in French using most common/representative French characters (including accentuated letters). I wouldn't remove it, but rather add a message context clarifying what its purpose is. If the sample text does not depend on the dialogue language, that's what should be done instead IMHO Frédéric
Re: Rethinking WineConf
Hey, Op 17-01-12 22:01, Dan Kegel schreef: On Tue, Jan 17, 2012 at 12:43 PM, Jeremy White wrote: So, exploring #3 a bit further - what if we asked for our own track within FOSDEM 2013? (I presume that would be February 2013 in Brussels) It would let us all get together, allow us to have a few sessions targeted at non Wine developers, and could also save us some hassle. And I like Belgian beer. FOSDEM was the only conference mentioned by more than one person in my little survey :-) I see Fosdem 2012 has a mono room: http://weblog.savanne.be/470-mono-developer-room-at-fosdem-2012-cfp I wonder if that would be a model to, um, emulate. - Dan Yeah there's some Xorg stuff going on as well. I'm visiting fosdem 2012 for that reason. Would be interesting to know if any wine devs go this year. Might meet up, and drink something non-alcoholic together. I'm only there saturday though. ~Maarten
Re: po: French translation updates.
On Wed, 18 Jan 2012, Frédéric Delanoy wrote: > On Tue, Jan 17, 2012 at 23:11, Francois Gouget wrote: > > @@ -9335,7 +9335,7 @@ msgstr "" > > "[nomFichier]\n" > > " [/S [/D]]\n" > > "\n" > >-"où\n" > >+"Où :\n" > > "\n" > > " + Définit un attribut.\n" > > " - Supprime un attribut.\n" > >@@ -10234,7 +10234,7 @@ msgstr "" > > "-ou-\n" > > "NET commande /HELP\n" > > "\n" > >-"où « commande » peut être HELP, START, STOP ou USE.\n" > >+"Où « commande » peut être HELP, START, STOP ou USE.\n" > > > > #: net.rc:28 > > msgid "" > >@@ -10264,7 +10264,7 @@ msgstr "" > > "\n" > > "NET STOP service\n" > > "\n" > >-"où « service » est le nom du service à arrêter.\n" > >+"Où « service » est le nom du service à arrêter.\n" > > I'm not convinced by the capitalization of "où" where placed kind of > in the middle of the "flow" of a sentence. I don't see this as a single sentence for your first example. It starts with 'Syntaxe :' which is not the start of a sentence. I see it more as equivalent to an enumeration on a form: Nom : Mozart Syntaxe : cmd option1 [option2] Classe : Maison Instruments :Où : [x] Piano - Option 1 [ ] Violon - Option 2 Even in the 'NET STOP' I see this as two short sentences, the first one of which describes the general syntax and ends with the word 'service' (but obviously we cannot put a full stop there as it would be confusing), and the second of which describes each option shown on the previous general syntax outline (here just the 'service' parameter). > N.B.: review/reply would be easier if you inlined your patch instead > of an attachment If I do that when the patch contains strange scripts my mailer messes things up. It may be ok for French but I've taken to attach all my PO patches to avoid errors. -- Francois Gouget http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
