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

Re: [Patch] for wined3d: Correcting order issue

by Vijay Kiran Kamuju

On Nov 30, 2007 3:26 AM, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > Hi all, > > > > This patch repairs my previous one, as the command never got executed, > > because 8600 matches before 8600M. > > > > > > Marco Schuster > > > > ---- > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > > index e4b5bdf..50b3250 100644 > > --- a/dlls/wined3d/directx.c > > +++ b/dlls/wined3d/directx.c > > @@ -950,6 +950,11 @@ BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info > > *gl_info) { > > gl_info->gl_card = CARD_NVIDIA_GEFORCE_8800GTS; > > vidmem = 320; /* The 8800GTS uses 320MB, a 8800GTX > > can have 768MB */ > > } > > + /* Geforce8 - midend mobile */ > > + else if(strstr(gl_info->gl_renderer, "8600 M")) { > > + gl_info->gl_card = CARD_NVIDIA_GEFORCE_8600MGT; > > + vidmem = 512; > > + } > > /* Geforce8 - midend */ > > else if(strstr(gl_info->gl_renderer, "8600") || > > strstr(gl_info->gl_renderer, "8700")) > > @@ -957,11 +962,6 @@ BOOL IWineD3DImpl_FillGLCaps(WineD3D_GL_Info > > *gl_info) { > > gl_info->gl_card = CARD_NVIDIA_GEFORCE_8600GT; > > vidmem = 256; > > } > > - /* Geforce8 - midend mobile */ > > - else if(strstr(gl_info->gl_renderer, "8600 M")) { > > - gl_info->gl_card = CARD_NVIDIA_GEFORCE_8600MGT; > > - vidmem = 512; > > - } > > /* Geforce8 - lowend */ > > else if(strstr(gl_info->gl_renderer, "8300") || > > strstr(gl_info->gl_renderer, "8400") || > > > > I would prefer not to extend the list with lots of additional models. In my opinion it isn't really needed as the list would become a lot longer and this makes it harder to maintain. If we would continue this way we would easily have to add two dozen additional mobile cards which are now handled as their desktop equivalents. I Would rather have a registry entry for all the cards, and user can add new cards. If they feel its not there. But I think this idea came up quite a long back and was rejected in favor of in the code values. Sorry for raising it up again. -- VJ

Nov. 30, 2007

Re: xdg_user_dirs patches

by Juan Lang

> I'm not sure we want to handle the desktop directory the same way. It's > really a special case because applications often put their 'icons' on > the desktop. So if the Windows desktop is just a symbolic link to the > Unix one, the user will end up with a lot of 'xxx.lnk' files on his > desktop. In particular these files will show the wrong icon: they will > have the icon associated with 'lnk' files, instead of the one of the > application they are supposed to start. While this is annoying, I find it confusing to go to the "Desktop" directory and not find the files on my desktop there. I prefer having the two desktops the same, and just delete the .lnk files myself. --Juan

Nov. 30, 2007

d3dx8 [patch 1/10] Implement D3DXPlaneFromPointNormal

by tony.wasserka＠freenet.de

> So, just to clarify, you propose to create a d3dx9.dll dll, putting its > code in dlls/d3dx9. Does this dll exist on Windows? If not, then we > should call it wined3dx9 (and its code would go in dlls/wined3dx9). Well, it shouldn't even be a dll, just a folder were put in all the d3dx9 code and let the d3dx9_xx.dlls just export the functions they need. I don't know of how much the makefile system is capable, but maybe we can put all the d3dx9_xx.spec files in the same directory to improve overviewability, I don't like these 13 dlls/d3dx9 directories that much :D Anyways, what are the concrete differences between the d3dx9_xx.dlls?

Nov. 30, 2007

Re: [4/4] WineD3D: Enabling too many lights is silently ignored

by Stefan Dösinger

Am Freitag, 30. November 2007 09:49:06 schrieb H. Verbeet: > On 30/11/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > But you're not creating the lights first with SetLight(). IIRC you can > create lots of lights with SetLight(), but only enable MaxActiveLights > at the same time with LightEnable(). I guess calling LightEnable on a > light that isn't created first is simply ignored. LightEnable() on a light that doesn't exist creates a new light.

Nov. 30, 2007

Re: [1/4] WineD3D: mov to a0.x does a floor(), not a round to nearest

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > I sent this patch already, and it was committed and shows up in the 0.9.49 > changelog. The commit ID is 6209b36acbef6e7f8edcf3a45a006bb09bffe4af, but > somehow the functional change was reverted again in > 0183f3e305ae1e40a806682ec85e8b4507e4ddd8 and the test was reverted in > 4454096db27e7560cce99367b45be3b24dd0894a Most likely what happened is that I applied it, then reverted it because it caused test failures, but I didn't remove the commit properly. Anyway, it's still failing: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:5165: Test failed: The device was not properly freed: refcount 1 make[2]: *** [visual.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2007

Re: Some thoughts about next GSoC

by Kai Blin

On Friday 30 November 2007 12:30:56 Francois Gouget wrote: > On Thu, 22 Nov 2007, Kai Blin wrote: > [...] > > I know some projects did an introductory quiz to figure out the student's > > coding skills, I'm not convinced the knowledge needed for Wine can be > > tested in a quiz. What do you think? > > Maybe just asking them to compile Wine and submit their include/config.h > or make test results. This can be used to check that their config does > not have big problems like a bad fontforge or 64/32bit issues that could > cause them problems when they start their project. Well, that's something we should take care of, ideally in the one-month period after being accepted and before the student is supposed to start working on SoC code. > Asking them to submit conformance tests is an interesting idea too, but > depending on the area it can be quite a bit of work. For some projects > it may also not be possible to write relevant tests (e.g. we cannot test > ExitWindows() or KDE/Gnome theme integration). But for those projects > where it makes sense it could be a good idea. Well, the way I'd like it to work is like this: 1. Student sends application draft to mailing list for review. 2. Wine developers with experience in the area covered by the application review the draft giving feedback. (Repeat steps 1 and 2 until application is suitable) 3. Students apply via Google web-app. 4. We contact students with request for a test case or the like. 5. Students send test case 6. Mentors review test cases, possibly asking for improvements (back to 5). Of course, I'm afraid it's unlikely that it actually will work like that, at least if we define test case as something that will fit right into the wine test suite. But I think a test case like a simple program that will use parts of the API that should be implemented and works on windows should be sufficient, and people will want to have something like that anyway later. I think it's also worth investing some time to help people get the initial code submission right. That's a point where we can teach people about code style, dos and don'ts, etc. If we get this right, it will benefit all the developers starting off with Wine, not only the SoC students. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Nov. 30, 2007

Re: xdg_user_dirs patches

by Chris Robinson

On Friday 30 November 2007 03:35:14 am Francois Gouget wrote: > I'm not sure we want to handle the desktop directory the same way. It's > really a special case because applications often put their 'icons' on > the desktop. So if the Windows desktop is just a symbolic link to the > Unix one, the user will end up with a lot of 'xxx.lnk' files on his > desktop. In particular these files will show the wrong icon: they will > have the icon associated with 'lnk' files, instead of the one of the > application they are supposed to start. Just to note, Wine already does this. The desktop directory is linked to ~/Desktop by default, which is the X desktop directory for most systems. You also should take into account that apps will sometimes place non-lnk files onto the desktop that the user may expect to see (extracted files, downloaded files, readme's, etc).

Nov. 30, 2007

Re: shell32: symlink user's profile shell folders to xdg well known directories [2/2] (try 3)

by Francois Gouget

On Thu, 29 Nov 2007, Alexandre Julliard wrote: > "Dan Kegel" <dank(a)kegel.com> writes: > > > I feel like a broken record, but: > > some apps don't like following symlinks, and the > > native Windows way to configure what the "My Foo" > > folders point to is called shell folder redirection; > > These are documented at > > http://support.microsoft.com/kb/242557 > > among other places, and I think Wine supports these > > registry settings. Is there any reason we don't want > > to use these instead of symlinks? > > We want the paths to remain valid even if the drive configuration is > changed, so they have to point somewhere inside the C: drive. Also, iirc, on the Unix side these directories are supposed to be movable relatively easily. If we put their path directly in the registry, we'll get lots of bad copies in the applications MRU lists, and elsewhere when they change (or when you move the .wine directory to another account/machine). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

Nov. 30, 2007

Re: xdg_user_dirs patches

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > On Wed, 28 Nov 2007, Alexandre Julliard wrote: > [...] >> Also these variables should take priority over the default heuristics, >> and you most likely want to handle the desktop dir the same way. > > I'm not sure we want to handle the desktop directory the same way. It's > really a special case because applications often put their 'icons' on > the desktop. So if the Windows desktop is just a symbolic link to the > Unix one, the user will end up with a lot of 'xxx.lnk' files on his > desktop. In particular these files will show the wrong icon: they will > have the icon associated with 'lnk' files, instead of the one of the > application they are supposed to start. > > So I think it's best to keep the Windows desktop separate from the Unix > one, and let winemenubuilder put 'xxx.desktop' files on the Unix desktop > when appropriate. You are right, that one doesn't need to be changed in shell32, but we have to fix winemenubuilder (or rather wineshelllink) to also take the xdg user dirs config into account for the desktop. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2007

Re: xdg_user_dirs patches

by Francois Gouget

On Wed, 28 Nov 2007, Alexandre Julliard wrote: [...] > Also these variables should take priority over the default heuristics, > and you most likely want to handle the desktop dir the same way. I'm not sure we want to handle the desktop directory the same way. It's really a special case because applications often put their 'icons' on the desktop. So if the Windows desktop is just a symbolic link to the Unix one, the user will end up with a lot of 'xxx.lnk' files on his desktop. In particular these files will show the wrong icon: they will have the icon associated with 'lnk' files, instead of the one of the application they are supposed to start. So I think it's best to keep the Windows desktop separate from the Unix one, and let winemenubuilder put 'xxx.desktop' files on the Unix desktop when appropriate. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Nov. 30, 2007