January 2010 - Wine-Devel - list.winehq.org

Re: comctl32: Get the test in the correct format

by Nikolay Sivov

On 1/2/2010 12:47, Jeff Latimer wrote: > --- > dlls/comctl32/listview.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) You don't need this. Conversion is done next lines if needed: --- if (isW) bSame = (lstrcmpW(dispInfo.item.pszText, pszText) == 0); else { LPWSTR tmp = textdupTtoW(pszText, FALSE); bSame = (lstrcmpW(dispInfo.item.pszText, tmp) == 0); textfreeT(tmp, FALSE); } ---

Jan. 2, 2010

Re: Thanks Wylda

by wylda＠volny.cz

Hi Austin, i was really pleased by this mail. It's always good to know, weather your work has some sense. Thank you too and all the people around Wine. W. PS: You know i'm father, so her->his ;-) But don't worry, even in Czech language you can not decide HE/SHE just based on "Wylda" (in 99.9% you can, but Wylda is nickname). ----- PŮVODNÍ ZPRÁVA ----- > I just wanted to extend a thanks to Wylda for all her > work on bugzilla. It helps a lot when users help to confirm > bugs, find fixed bugs, etc. So thanks! > > -- > -Austin

Jan. 2, 2010

Is native dbghelp useful?

by Austin English

I noticed Microsoft's got dbghelp in a download available...would the native dll be useful to anyone? E.g., should I add it to winetricks? http://www.microsoft.com/downloads/details.aspx?FamilyID=cd1fc4b2-0885-47f4… -- -Austin

Jan. 2, 2010

Re: Thanks Wylda

by Vitaliy Margolen

Austin English wrote: > I just wanted to extend a thanks to Wylda for all her work on > bugzilla. It helps a lot when users help to confirm bugs, find fixed > bugs, etc. So thanks! I second that. Thanks a lot for all the great work. Vitaliy

Jan. 2, 2010

Re: dinput: Initialize js state with sane values when the application acquires the device instead of at allocation.

by Loïc Hoguin

On 01/01/2010 10:44 PM, Vitaliy Margolen wrote: > Loïc Hoguin wrote: >> See the attached patch. >> >> + /* Get sane state values for the joystick before giving control to the application. >> + Before this call was made in alloc_device, before the application sets the joystick >> + properties, so the values given by fake_current_js_state weren't in the range >> + of values expected by a few applications. */ >> + fake_current_js_state(This); >> + > > The comment is a bit too verbose. First line is enough. > > However my main problem with your patch is you doing it on every acquire > call which invalidates prior state of the joystick which could have been > correct. I'm afraid you'll need to find a way to do it once or pull the real > device state from the device. > > Vitaliy OK for the comment. I had two possible solutions in mind, doing it in Acquire, which doesn't seem good, and doing it when the range properties are being changed (and keeping the original call in alloc_device for a safe initialization). This would mean the values would be correct at all time from the point of view of the application. I'm guessing the second solution is better then; after all, the axis data in 'js' should be invalidated if the range is changed (and possibly when the dead zone is changed too). In fact if I understand it correctly it should be possible to simply convert the existing data into the new range when this range is changed by the application. This would fix my issue without invalidating the data already available. Doing it for the dead zone doesn't sound as straightforward though, it would work perfectly if it is being increased but not when decreased, as data in the dead zone can't be recovered until the joystick sends more information. And as far as I know no application would benefit from doing this when the dead zone property is changed. Tell me what you think about this and I'll start working on a better patch. -- Loïc Hoguin mel: essen(a)dev-extend.eu web: http://dev-extend.eu

Jan. 1, 2010

Re: dinput: Initialize js state with sane values when the application acquires the device instead of at allocation.

by Vitaliy Margolen

Loïc Hoguin wrote: > See the attached patch. > > + /* Get sane state values for the joystick before giving control to the application. > + Before this call was made in alloc_device, before the application sets the joystick > + properties, so the values given by fake_current_js_state weren't in the range > + of values expected by a few applications. */ > + fake_current_js_state(This); > + The comment is a bit too verbose. First line is enough. However my main problem with your patch is you doing it on every acquire call which invalidates prior state of the joystick which could have been correct. I'm afraid you'll need to find a way to do it once or pull the real device state from the device. Vitaliy

Jan. 1, 2010

Thanks Wylda

by Austin English

I just wanted to extend a thanks to Wylda for all her work on bugzilla. It helps a lot when users help to confirm bugs, find fixed bugs, etc. So thanks! -- -Austin

Jan. 1, 2010

Re: [PATCH] wined3d: Do not try to use not available texture stages in set_tex_op_nvr

by Stefan Dösinger

> Yeah. A rather old one... ;-) > > I don't know this code much but I would say it is partly 2 and 3. Is a FIXME suitable then ? This would be much more informative that just GL errors. I'd prefer if we could track down the real issue. There might still be some confusion between texture stages, number of simultanous textures and texture coordinates(currently we assume texture coordinates == texture stages, which is a bug in itself, but I think not the issue here) A few questions that could provide hints: Is a non 1:1 texture mapping used? Look for "Using non 1:1 mapping" WARNs Does the call come from alpha or color? Color filters out unused stages and doesn't call set_tex_op_nvrc at all. Alpha doesn't do that because the colorop setup disables the texture unit, but this could cause GL errors, and I am not sure if it is correct with NVRC.

Jan. 1, 2010

RE: winetestbot busted?

by Greg Geldorp

Hi Dan, (adding wine-devel, this info might be interesting for other people as well) > Does the queuing system prioritize jobs at all? e.g. > do quick interactive jobs with low timeouts have > to wait behind the massive three hour daily runs? There is some prioritization, you can see the assigned job priority on the main status page. The priority levels I'm currently using (or plan to use): 1 (highest) - Daily run for base VMs 3 - Rebuild of Wine (cross) tests after Alexandre pushes out git updates 5 - User submitted jobs 7 - Daily run for extra and 64-bit VMs 9 - Jobs automatically generated from wine-patches submissions So user jobs will be blocked during the daily run on base VMs, that takes about 45 min. However, they will have higher priority than the daily run for extra/64-bit VMs. It might take some time for user-submitted jobs to actually start, they might need a VM that's "dirty" and needs to be reverted to a clean snapshot. Ge.

Jan. 1, 2010

Re: [1/7] avifile: Initial test data and simple test for avifil32 depends

by Austin English

On Fri, Jan 1, 2010 at 2:18 PM, Julius Schwartzenberg <julius.schwartzenberg(a)gmail.com> wrote: > I think it was also stupid of me to send all the patches as a serie, while > they do not actually depend on each other. I'm not sure though how I would > submit the patches next time. Should I send the tests depending on each > other in a separate serie from the actual fixes or is the right way actually > to send a fix with it's test in the same serie? It's better to send the test in first, in case the fix isn't committed. As for the series, if the patches don't depend on each other, there's no need to make a series, though it doesn't hurt anything. -- -Austin

Jan. 1, 2010