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

Roderick Colenbrander thunderbird2k at
Sat Nov 1 10:18:24 CDT 2008

My whole point is maintenance and distribution. Sure you could create different plugins for uxtheme but the language limitation won't allow such plugins to enter Wine. They would need to be maintained outside of Wine which would be bad. It has risks of bitrotting and second it would be a pain to package it all. I don't think we want such components maintained outside of Wine.

That all is the reason for having a 'winetheme' app which creates .msstyles themes and which uses GTK/QT/Cocoa as I think Alexandre could perhaps live with this as we wouldn't pollute any Wine dlls with 'bad' languages. But as I said this approach would require syncing themes at Wine startup and theme refreshing wouldn't work without some evil polling mechanism. Personally I wouldn't find this switching at runtime important though and I wonder if our dlls support this at all. (That would have to be fixed then but personally I don't give it a high priority)


> 2008/11/1 Roderick Colenbrander <thunderbird2k at>:
> > In the end we need to support a bunch of different theme engines GTK,
> QT, Cocoa and perhaps later on more. In theory it would be possible to create
> a different uxtheme backend for each different toolkit. One major issue is
> the language which each of these toolktis is written in. GTK would be fine
> as it is C but QT and Cocoa require respectively C++ and Objective C.
> Alexandre doesn't want such languages in (although he might make an exception
> for the winecocoa driver if it is really, really needed).
> I mentioned that in my email. The idea that wine would host the XP
> msstyles theme (the fallback behaviour for uxtheme), and a GTK plugin
> to support GTK themes. Then other projects can provide a Qt and Cocoa
> plugin, so they can be written in the toolkit's language.
> > While using a language different than C is a definitive no, I think
> Alexandre might allow the use of other languages in helper programs. The best
> way would be to write a separate program (which would have backends for all
> the needed toolkits) which generates a .msstyles theme (or if Vista uses a
> newer and better format, lets directly move to that format). The main issue
> would then be on how to sync themes. I guess that would need to be done at
> wine startup.
> The problem with the Vista theme is that it is binary and completely
> undocumented, making it very difficult to reverse engineer.
> Moving forward, we'll probably need to be able to support both XP and
> Vista themes (possibly Windows 7 and later as well if the theme format
> has changed). I don't know if moving the processing of that into a
> separate process would help, though.
> When syncing themes, you can have uxtheme.dll loading the correct
> engine if enabled (see my "Use the native theme" option idea in my
> previous discussion on improving winecfg). Then, if the system theme
> changes, the WM_THEMECHANGED message needs to be sent to all top-level
> applications so they can refresh themselves to use that new theme. How
> that happens and where needs to be figured out.
> And yes, the bugs in uxtheme and the various controls need fixing.
> - Reece

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden:

More information about the wine-devel mailing list