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

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

by Dan Kegel

On Sun, Nov 2, 2008 at 2:52 PM, Roderick Colenbrander <thunderbird2k(a)gmx.net> 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

Nov. 3, 2008

Re: Henri Verbeet : ddraw: Make sure pWineDirect3DCreate and pWineDirect3DCreateClipper match the header .

by Rob Shearman

2008/10/24 Alexandre Julliard <julliard(a)winehq.org>: > 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

Nov. 3, 2008

Re: rfc: refactoring msxml3 to get rid of aggregation

by Michael Karcher

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

Nov. 2, 2008

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

by Roderick Colenbrander

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 <dank(a)kegel.com> 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

Nov. 2, 2008

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

by Steven Edwards

On Sun, Nov 2, 2008 at 3:01 PM, Dan Kegel <dank(a)kegel.com> 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

Nov. 2, 2008

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

by Lei Zhang

On Sun, Nov 2, 2008 at 7:54 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> 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.

Nov. 2, 2008

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

by Reece Dunn

2008/11/2 Dan Kegel <dank(a)kegel.com>: > 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

Nov. 2, 2008

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

by Dan Kegel

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.

Nov. 2, 2008

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

by Dan Kegel

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

Nov. 2, 2008

Re: General script for installing Wine build dependencies

by Dan Kegel

On Sun, Nov 2, 2008 at 8:41 AM, Marcus Meissner <marcus(a)jet.franken.de> 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.

Nov. 2, 2008