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

Re: General script for installing Wine build dependencies

by Dan Kegel

On Sun, Nov 2, 2008 at 8:31 AM, Evil Jay <wine(a)eternaldusk.com> wrote: > I can see where this would be useful for building on some platforms, but > doesn't "sudo apt-get build-dep wine" work fine (for the most part) for > Ubuntu? I don't trust that. > The last time I compiled on a fresh *buntu, I recall using build-dep and > then having to install one nvidia-specific '-dev' package to get DirectX > support working. I think it was nvidia-glx-177-dev; Until it added some > headers or whatnot, ./configure insisted it was going to build without > DirectX. See? In general, I would like install-build-deps.sh to be independent of the people who package wine. Think of it as perhaps the upstream of build-dep. > As far as specific tweaks: on Intrepid Ibex I don't believe x-dev or > qt3-dev-tools are required. X-dev's a transitional package only > dependent on x11proto-core-dev, which is already in your list. I don't > have qt3-dev-tools installed (and everything compiles/runs clean). Hmm, I'm not really sure how the qt stuff snuck in there. I guess libqt3-mt-dev was in the build deps when I started. I'll try removing all the qt stuff and see what happens. - Dan

Nov. 2, 2008

Re: rfc: refactoring msxml3 to get rid of aggregation

by Jacek Caban

Hi Michael, Michael Karcher wrote: > Any oppions on that? I think other solution would be better. There is no reason for xmlnode object to implement any interface. All its child objects already have IXMLDOMNode interface. xmlnode could be a common struct stored by child objects and there could be set of function with common method implementation. This way we could also avoid ugly tests for node type in node.c, because we can handle the difference outside node.c. > I (obviously) think that b is the right solution, > but as a quick grep over the Wine source code revealed, this solution > seems to be used nowhere. Is that because this is the first place where > deriving makes sense or is that because I'm completely off-track? > Casting function in vtbl is not an acceptable solution. If you have to do that, it means that the design is bad. Jacek

Nov. 2, 2008

Re: General script for installing Wine build dependencies

by Marcus Meissner

On Sun, Nov 02, 2008 at 10:31:11AM -0600, Evil Jay wrote: > I can see where this would be useful for building on some platforms, but > doesn't "sudo apt-get build-dep wine" work fine (for the most part) for > Ubuntu? > > The last time I compiled on a fresh *buntu, I recall using build-dep and > then having to install one nvidia-specific '-dev' package to get DirectX > support working. I think it was nvidia-glx-177-dev; Until it added some > headers or whatnot, ./configure insisted it was going to build without > DirectX. > > As far as specific tweaks: on Intrepid Ibex I don't believe x-dev or > qt3-dev-tools are required. X-dev's a transitional package only > dependent on x11proto-core-dev, which is already in your list. I don't > have qt3-dev-tools installed (and everything compiles/runs clean). Same for RPM building, just one "rpm -i wine-.....src.rpm" will also request necessary dependencies. Afterwards you can deinstall the wine-...src.rpm again. Ciao, Marcus

Nov. 2, 2008

Re: General script for installing Wine build dependencies

by Evil Jay

I can see where this would be useful for building on some platforms, but doesn't "sudo apt-get build-dep wine" work fine (for the most part) for Ubuntu? The last time I compiled on a fresh *buntu, I recall using build-dep and then having to install one nvidia-specific '-dev' package to get DirectX support working. I think it was nvidia-glx-177-dev; Until it added some headers or whatnot, ./configure insisted it was going to build without DirectX. As far as specific tweaks: on Intrepid Ibex I don't believe x-dev or qt3-dev-tools are required. X-dev's a transitional package only dependent on x11proto-core-dev, which is already in your list. I don't have qt3-dev-tools installed (and everything compiles/runs clean). -J Dan Kegel wrote: > I have in the past written one script per version of > Ubuntu to install Wine's build dependencies. > Many versions on, that's getting old, and I figure > it'd be better to have a single script that handles > all common versions on Linux. > > I've taken a first stab at that, combining my scripts > for gutsy and hardy, and adding ibex. The result is at > http://winezeug.googlecode.com/svn/trunk/install-wine-deps.sh > > If anyone wants to add support to that script for another > OS, please do, and send me the patch. > > I'd like to see this in the wine tree sometime. It's > kind of silly we have to direct people to a big, > confusing wiki page (or set of them) to explain > how to install the needed packages; let's just > have a unified script and be done with it. > > >

Nov. 2, 2008

Re: [PATCH] mountmgr: Add and remove drives when they are (un)mounted.

by Vitaliy Margolen

Lei Zhang wrote: > Hi, > > It looks like mountmgr.sys does not remove drives when devices are > unmounted. We should look at the is_mounted property and take the > appropriate action when it changes. This is going the wrong way. Wine already can't deal with blank media without some "hackish" workarounds. With this patch you will break even that. Wine should keep drive visible for applications even if there is not media or a blank media inserted. Vitaliy.

Nov. 2, 2008

Re: wininet: let automated testers force all DNS lookups to return localhost

by Rob Shearman

2008/10/31 Dan Kegel <dank(a)kegel.com>: > The public internet can (and does) go pear-shaped > in the middle of test runs, which means any test > that tries to access the public internet is de facto > flaky, even if it tries to protect itself by skipping > if the internet is down. > > So let's provide a way for automated testers to > force all hostname resolution requests to > return the same result (say, 'localhost' or 'mytestserver'). > Only include this in debugging builds. > > Later we should provide a script to set up > a local test server that can handle all of > our conformance tests' requests, but for > now, just letting patchwatcher or winetest > redirect everything to localhost will let tests > fail reliably instead of randomly. > See http://bugs.winehq.org/show_bug.cgi?id=15716 This approach won't help users of the Wine conformance tests running on Windows, so it appears to me to be a flawed approach. We should instead rewrite any existing tests that use a public server to instead use a server started by the Wine test code (see dlls/wininet/tests/http.c:server_thread). This has the additional benefit of allowing us to be much more precise with what we're testing and to be able to emulate the implementations of different HTTP servers, instead of just what winehq.org runs. -- Rob Shearman

Nov. 2, 2008

Re: Please, look at my patch, I'm not sure it's correct

by Rob Shearman

2008/10/31 Vitaly Perov <vitperov(a)etersoft.ru>: > This patch add a stub implementation of IMarshal interface. > > I have no experience at implementing interfaces, so I'm not sure it's > implemented correctly. > Please, look at this patch. I'll be grateful for any remarks. What makes you think IMarshal is supposed to be implemented by HTMLDocument objects? -- Rob Shearman

Nov. 2, 2008

Re: General script for installing Wine build dependencies

by Dan Kegel

On Sat, Nov 1, 2008 at 11:32 PM, Scott Ritchie <scott(a)open-vote.org> wrote: >> http://winezeug.googlecode.com/svn/trunk/install-wine-deps.sh > > Bonus points if you somehow manage to use packagekit. I s'pose, but because the package names change from distro to distro, it wouldn't add that much portability, would it?

Nov. 2, 2008

Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes

by Frank Richter

On 01.11.2008 21:21, Reece Dunn wrote: > In order to do that properly, you will need major buy-in from the Gtk, > Qt and other widget toolkit developers, FWIW, I recall having read some Planet GNOME blog posts where people expressed, well, a bit of unhappiness with GTK's current theming system. (Apparently a lot of hacks are needed, some even for specific applications.) So a buy-in might be possible from them, if you promise something better than you have now ;) -f.r.

Nov. 2, 2008

Re: [Re] Vertex pipeline replacement

by Rico Schüller

Stefan Dösinger schrieb: > Here is an updated version of the patches. Can you retest the games? (the > ones that worked already as well as the broken ones) > > What are the differences? > > -> Proper handling of RHW vertices which do not come from a vbo(should fix > Star Wars Jedi Knight 1) > -> Proper handling of the alpha value in the lighting code(+ a test). Fixes > the water in AoM. > > Those issues had a quite big effect potentially, so more games may be fixed > now. > > > ------------------------------------------------------------------------ > > > Oblivion has rendering errors in the menu (white boxes). Also the status/action bar isn't drawn correctly (both with fbo). Should I file a bug? WarCraft 3 had some glitches with the previous version but it is fixed in version 2 of the Vertex pipeline replacement patch. Cheers Rico

Nov. 2, 2008