Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
2008/11/3 Dan Kegel <[EMAIL PROTECTED]>: > On Sun, Nov 2, 2008 at 2:52 PM, Roderick Colenbrander > <[EMAIL PROTECTED]> wrote: >> Anyway desktops will never move to this microsoft format. >> I think both gtk and qt are now moving to xml based formats. >> We could define our own spec for that but I doubt they will move to this. > > Right, I doubt we can have any influence on them. > That's why I think we should focus on the most > superficial kind of compatibility, i.e. just supporting > Windows theming and providing theme files that > make us look not so jarring. I was not proposing that Gtk and the other frameworks adopted the msstyles format (which has changed in Vista to an unintelligible binary format). What I was proposing, after some discussion, was standardising at the *API* level. Something that would be acceptable with (and have the buy-in from) the toolkit writers and key applications. The various toolkits would still use their current formats for those themes. Wine could then use this standardised API, Alternatively, there could be a Universal Theming Engine that does the same thing. That would be an external project that provides bindings to at least the major theming engines available, but such that applications can use it to simplify their code. Wine could then use this external library. But Dan is right, the first step for Wine is making the uxtheme/msstyles support work well so that it can be used by distributions to theme Wine. Another thing that potentially needs resolution is that Vista has added support for theming menus, but this will require us to use the new binary msstyles if Wine intends to properly support this without adding our own custom extensions to the XP format. This is where deeper integration will help: an XP msstyles theme will not support menu theming, but a native theme will. > I doubt we can ever do automatic theme extraction. Agreed. - Reece
Re: General script for installing Wine build dependencies
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? > > Working around that issue is the whole point of packagekit ;) No, it's orthogonal. But having packagekit around does make it stand out more like the sore thumb it is... - Dan
Re: General script for installing Wine build dependencies
Dan Kegel wrote: > On Sat, Nov 1, 2008 at 11:32 PM, Scott Ritchie <[EMAIL PROTECTED]> 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? > > Working around that issue is the whole point of packagekit ;) Thanks, Scott Ritchie
patchwatcher status: still offline
Let me know if these updates get annoying. I'm bringing up a three-node patchwatcher cluster (master plus two build slaves), and updating http://winezeug.googlecode.com/svn/trunk/patchwatcher/readme.txt as I go. It's coming along ok, but it'll probably be another few days before it's up. - Dan
RE: [Re] Vertex pipeline replacement
> 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? Yes, file bugs please. I think I have Oblivion here somewhere, this should be easier to debug than Morrowind. Note that it will be a while before I send another version of this. I did some benchmarking, and there isn't much of a performance improvement. In most cases the replacement pipeline is slower. We still need it some day, so I'll continue the work, but this makes it less of a priority. I also think that we can improve the performance quite a bit, but it will need quite a bit more work.
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
On Sun, Nov 2, 2008 at 2:52 PM, Roderick Colenbrander <[EMAIL PROTECTED]> wrote: > Anyway desktops will never move to this microsoft format. > I think both gtk and qt are now moving to xml based formats. > We could define our own spec for that but I doubt they will move to this. Right, I doubt we can have any influence on them. That's why I think we should focus on the most superficial kind of compatibility, i.e. just supporting Windows theming and providing theme files that make us look not so jarring. I doubt we can ever do automatic theme extraction. - Dan
Re: Henri Verbeet : ddraw: Make sure pWineDirect3DCreate and pWineDirect3DCreateClipper match the header .
2008/10/24 Alexandre Julliard <[EMAIL PROTECTED]>: > diff --git a/dlls/ddraw/ddraw_private.h b/dlls/ddraw/ddraw_private.h > index 7ff3c5c..cd1ce15 100644 > --- a/dlls/ddraw/ddraw_private.h > +++ b/dlls/ddraw/ddraw_private.h > @@ -414,8 +414,7 @@ struct IDirectDrawClipperImpl > > const IDirectDrawClipperVtbl IDirectDrawClipper_Vtbl; > > -typedef IWineD3DClipper* (WINAPI *fnWineDirect3DCreateClipper)(IUnknown *); > -fnWineDirect3DCreateClipper pWineDirect3DCreateClipper; > +typeof(WineDirect3DCreateClipper) *pWineDirect3DCreateClipper; This isn't portable to some compilers, like MSVC. Can this be reverted? -- Rob Shearman
Re: rfc: refactoring msxml3 to get rid of aggregation
Hi Jacek. > Hi Michael, > Casting function in vtbl is not an acceptable solution. If you have to > do that, it means that the design is bad. So in short that means that using deriving for objects to implement derived interfaces is not possible in Wine, as it is not cleanly implementable in plain C. Too bad, but I also don't like casts in the vtbl, as they are definitely not typesafe. I think one could come up with a preprocessor macro hack that enforces typesafety and results in plain casts, but macro-magic is rightly frowned upon in wine. I don't think anyone would like to maintain the macro-mess that would be needed (including myself). > > Any oppions on that? > I think other solution would be better. There is no reason for xmlnode > object to implement any interface. xmlnode could provide a default implementation for most of the functions, so one only has to override the functions that need specific handling. If derivation could be used, one does not have to write tons of separate stubs that just do the same, namely forward calls to the xmlnode default handlers (I would call that poor man's derivation), which would kill a lot of boilerplate source code, and thus reduce executable size (who needs 300[1] functions containing [if gcc optimizes correctly, not verified] just one jump instruction if the address of the target could have been put instead in the vtable) and improve performance a bit. On the other hand, 300 jumps instructions (if the optimizer works...) are just 1.5 kilobytes, and that shouldn't hurt that much on modern computers. [1] order-of-magnitude estimate. > All its child objects already have IXMLDOMNode interface. Yes, of course, as the child objects implement interfaces that are derived from IXMLDOMNode (either directly or indirectly). > xmlnode could be a common struct stored by child > objects and there could be set of function with common method > implementation. Right. That is quite like the direction I was also heading to. The extra memory allocation and use of COM aggregation for the xmlnode object definitely seems like overkill, and is also avoided by the containment approach you suggest. > This way we could also avoid ugly tests for node type in > node.c, because we can handle the difference outside node.c. Very good point, didn't take a look at them. These tests should get expunged and replaced by different implementation chosen by the vtable of the IXMLDOMFoo imlementing objects. Thanks for your input, Michael Karcher
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
For fun I looked a bit at the format. An msstyles file is just a win32 resource file. It contains various sections each containing strings, colors or bitmaps. Colors are just stored in a text file. Uxtheme parses this text file and loads the colors 1:1 from this section into the registry. The main issue is creating a resource file it can either be compiled using wrc or it could an empty file could be created from a program and then updated using UpdateResource and friends. The first solution is the nicest way but not everyone might install wrc. Anyway desktops will never move to this microsoft format. I think both gtk and qt are now moving to xml based formats. We could define our own spec for that but I doubt they will move to this. They attempted before to use the same theme format but it didn't work out well. Roderick > On Sun, Nov 2, 2008 at 3:01 PM, Dan Kegel <[EMAIL PROTECTED]> wrote: > > FWIW, my opinion is that any deep integration > > is going to be hard, and that for the moment > > we should go with something much simpler: > > simply support mstheme files well, and provide > > themes that look like the default themes on > > Ubuntu / OpenSuse / Fedora. > > I agree. I simply think any outside tools we develop should be used in > conjunction with a proposed formal standard. If the MS formats are > open there is no reason we cannot propose the usage of them, or a > variation on them as part of FreeDesktop making Wine play nicer with > everyone (mono and moonlight prove MS standards and formats can be of > use for Linux). I'll spend some of the copious amounts of free-time I > have at work researching for formats and we can continue the propose > standard discussion off list later in the week. > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
On Sun, Nov 2, 2008 at 3:01 PM, Dan Kegel <[EMAIL PROTECTED]> wrote: > FWIW, my opinion is that any deep integration > is going to be hard, and that for the moment > we should go with something much simpler: > simply support mstheme files well, and provide > themes that look like the default themes on > Ubuntu / OpenSuse / Fedora. I agree. I simply think any outside tools we develop should be used in conjunction with a proposed formal standard. If the MS formats are open there is no reason we cannot propose the usage of them, or a variation on them as part of FreeDesktop making Wine play nicer with everyone (mono and moonlight prove MS standards and formats can be of use for Linux). I'll spend some of the copious amounts of free-time I have at work researching for formats and we can continue the propose standard discussion off list later in the week. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: [PATCH] mountmgr: Add and remove drives when they are (un)mounted.
On Sun, Nov 2, 2008 at 7:54 AM, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: > 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. > How about leaving cdrom / floppies alone and only add/remove disks on (un)mount. Currently , if we add a disk, and then unmount, but not remove it, the disk end up in a state where it's still there, but all of its contents are gone.
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
2008/11/2 Dan Kegel <[EMAIL PROTECTED]>: > FWIW, my opinion is that any deep integration > is going to be hard, and that for the moment > we should go with something much simpler: > simply support mstheme files well, and provide > themes that look like the default themes on > Ubuntu / OpenSuse / Fedora. Yes. That's why I ordered the level of integration the way I did (colours, msstyles, deep integration). - Reece
re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.
Re: wininet: let automated testers force all DNS lookups to return localhost
Rob wrote: >> 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. > > This approach won't help users of the Wine conformance > tests running on Windows, Sure it would; just make the test server setup script run on cygwin properly. > 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). Yes, absolutely. The more tests that set up their own mock servers, the better. But while we're waiting for that, a "nuke DNS resolution" approach makes tests behave repeatably, and would even be useful after we implement the fix you propose, as it would protect us from new tests that sloppily depend on the public internet. As someone pointed out, actually nuking DNS resolution is kind of tricky; my patch did it for DLLs that use win32 networking, but not for DLLs that use native networking. It probably can't be done the same way everywhere, so I guess for Linux I'll punt and try shared library overriding. - Dan
Re: General script for installing Wine build dependencies
On Sun, Nov 2, 2008 at 8:41 AM, Marcus Meissner <[EMAIL PROTECTED]> wrote: > 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. Again, I'm aiming at having something independent of, and perhaps upstream of, the list that the packagers maintain.
Re: General script for installing Wine build dependencies
On Sun, Nov 2, 2008 at 8:31 AM, Evil Jay <[EMAIL PROTECTED]> 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
Re: rfc: refactoring msxml3 to get rid of aggregation
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
Re: General script for installing Wine build dependencies
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
Re: General script for installing Wine build dependencies
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. > > >
Re: [PATCH] mountmgr: Add and remove drives when they are (un)mounted.
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.
Re: wininet: let automated testers force all DNS lookups to return localhost
2008/10/31 Dan Kegel <[EMAIL PROTECTED]>: > 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
Re: Please, look at my patch, I'm not sure it's correct
2008/10/31 Vitaly Perov <[EMAIL PROTECTED]>: > 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
Re: General script for installing Wine build dependencies
On Sat, Nov 1, 2008 at 11:32 PM, Scott Ritchie <[EMAIL PROTECTED]> 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?
Re: Wine integration with native (Gtk, Qt, Cocoa/Carbon) themes
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. signature.asc Description: OpenPGP digital signature
Re: [Re] Vertex pipeline replacement
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
Re: General script for installing Wine build dependencies
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. > > Bonus points if you somehow manage to use packagekit. Thanks, Scott Ritchie
