June 2007 - Wine-Devel - list.winehq.org

Re: cmd:Ru:Update Russian translation.[try2][fixed]
by Kirill K. Smirnov June 7, 2007

June 7, 2007

> I think original phrase "Файл, ассоциированный с > расширением %s,отсутствует\n" is better (but there is a typo in it - > missing space after second ","). And word "ассоциированный" do sounds like > Russian (and has frequent use in books and speech), and I like it more than > less familiar (to me) word "сопоставление". So I think word "сопоставление" > maybe only good choice if Wine already using it instead of word > "ассоциированный" (I'm not sure about this because I'm using English > interface with Wine). (Just a note: Russian is my native language). > Anyway, in my opinion such discussion "what synonym is better" is > pointless because it is just a matter of personal taste. I do not mean "ассоциированный" и "сопоставление" synonyms. Prase "Файл, ассоциированный с расширением %s, отсутствует" is invalid. File never is associated with extension. Program is associated. And not "File" is absent, but "File association" - "Сопоставление файлов" ("сопоставление расширений файлов соответствующим программам"). I do not have anything against synonym "ассоциированный". -- Kirill

2 1

Adding support for both wine_gecko and Mozilla ActiveX.
by Andrew Riedi June 6, 2007

June 6, 2007

A lot of users would enjoy an option between installing wine_gecko and Mozilla ActiveX. Would it be very difficult to add a little dialogue box or registry key to toggle between the two? Is there a better way? If it is too difficult or will slow down work on eg. MSHTML and the like, don't worry about it. Anyhow, regardless of response, thanks for your work. :) -- Andrew Riedi

1 0

Re: wined3d [2/5]: Extend the D3DFMT table to include gamma corrected formats
by Stefan Dösinger June 6, 2007

June 6, 2007

Am Donnerstag, 7. Juni 2007 01:05 schrieb Phil Costin: > Extend the D3DFMT table to include gamma corrected formats. This patch(and 3 and 4) look good to me on a quick check.

1 0

Re: wined3d [1/5]: Add GL_EXT_texture_sRGB constants and corresponding CheckDeviceFormat query
by Stefan Dösinger June 6, 2007

June 6, 2007

Am Donnerstag, 7. Juni 2007 01:03 schrieb Phil Costin: > Adds necessary GL constants and allows the application to query whether a > particular texture format is compatible with sample-time texture > linearization. Ideally you shouldn't enable the srgb formats in this patch already, but rather in 4/5, but since the current code returns WINED3D_OK this is an unimportant detail.

1 0

Re: d3d9/tests [5/5]: Test CheckDeviceFormat returns correctly for D3DUSAGE_QUERY_SRGBREAD queries
by Stefan Dösinger June 6, 2007

June 6, 2007

Am Donnerstag, 7. Juni 2007 01:16 schrieb Phil Costin: > Test CheckDeviceFormat returns correctly for D3DUSAGE_QUERY_SRGBREAD > queries. This test will fail on any card that doesn't support sRGB at all. What would be more useful is to find out what assertion hl2 makes, ie if D3DFMT_X8R8G8B8 is supported, then D3DFMT_L8 and D3DFMT_A8L8 are supported too. No idea how this really looks like. Another idea would be to set up a table of formats that are found supported on some cards, and complain if a format that is known NOT to be supported(like Q8W8V8U8) is found supported - see the query test for an example.

1 0

wined3d: Void functions should not return a value
by Andrew Talbot June 6, 2007

June 6, 2007

Please note: I set the indentation of some amended lines to match that in the majority of the surrounding functions. -- Andy.

1 0

Re: cmd:builtints.c Fix convert from lower case to upper case
by Juan Lang June 6, 2007

June 6, 2007

This appears to be missing the patch. --Juan ____________________________________________________________________________________ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/

1 0

Re: [patch 2] mshtml: Added support for coexisting different Gecko versions installation.
by Alexandre Julliard June 6, 2007

June 6, 2007

Jacek Caban <jacek(a)codeweavers.com> writes: > - /* @@ Wine registry key: HKCU\Software\Wine\MSHTML */ > - res = RegOpenKeyW(HKEY_CURRENT_USER, wszMshtmlKey, &hkey); > + memcpy(mshtml_key, wszMshtmlKey, sizeof(wszMshtmlKey)); > + MultiByteToWideChar(CP_ACP, 0, GECKO_VERSION, -1, > + mshtml_key+sizeof(wszMshtmlKey)/sizeof(WCHAR), -1); Please pass the correct dest buffer size, not -1. > + GetEnvironmentVariableA("windir", install_dir, sizeof(install_dir)); GetWindowsDirectory is preferable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [Patch for Bug 8551] MoveFileWithProgressW unconditional fails for directories with flag MOVEFILE_REPLACE_EXISTING
by James Hawkins June 5, 2007

June 5, 2007

On 6/5/07, Jens Nestler <jn(a)nessi-online.de> wrote: > http://bugs.winehq.org/show_bug.cgi?id=8551 > > Hello, > > please find attached the patch for the bug mentioned above. > > Jens Nestler > The bug also has a test case that needs to be integrated into the Wine test suite and submitted to wine-patches. -- James Hawkins

1 0

Re: OpenGL 2.3 to 3.0
by Matthew Clark June 5, 2007

June 5, 2007

Ah this makes perfect sense and is exactly what I was looking for, thank you for your response! My limited understanding from the article was that 2.3 was simply cleanup and putting some extensions in the official API that have been in drivers for a while just not in the official API and then 3.0 is where the real change will be, BUT that it will only activate the 3.0 functionality if it's on supporting hardware(i.e. DX10 cards). Please correct me if my understanding is incorrect and again I think we all realize this is all in the future and is just fun to talk about^_^ Thanks for all THE fish, -Matt PS Yes I am an idiot some times =P > > Stefan Dösinger wrote: >> We are waiting for the final API before deciding if we like it or not. But >> from what I've read so far the changes make sense. >> >> My concern is backwards compatiblity. For dx 1 to dx9 we will still need the >> old apis. For one part because the new api may not offer fixed function >> functionality, but more importantly because old cards will most likely not >> see any driver updates. >> >> If the interface is vastly different we'll need 2 d3d implementations, one >> wrapping to old gl and one for the new version. An idea would be to just >> leave dx1 to 9 with gl 2.0 and write dx10 only for opengl 3.0. >> >> If the new API allows it however, we want to keep the wine code unified. This >> could happen by simply duplicating very specific functions which are >> different, and then select them at creation time by choosing a different >> virtual function table. If we need an if condition for every opengl call we >> do it would be pointless to keep everything in one lib. >> >> But we need to know the final opengl 3.0 API to decide what to do. >> > >

2 1