Hi,
There are a bunch of uxtheme / control theming bugs which need to be fixed but lets ignore those issues for now.
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).
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.
Roderick
Hi,
There is a discussion going on over at https://bugs.launchpad.net/ubuntu/+source/wine/+bug/111061 about improving Wine's look and feel to better match the system that it is running on.
The situation is as follows:
== Colour Schemes
Wine supports these by reading the settings from the registry. Winecfg can load a .theme file containing a colour profile and adapt accordingly (saving those settings to the registry).
At the moment, if you need to script this (e.g. when installing Wine) you need to manipulate the registry. It would be helpful if winecfg (or some other helper utility) supported setting the theme file on the command line.
In addition to this, if the user changes the theme used on their system it would not be reflected by Wine.
== Windows Theme Support
Windows theming support is in place to some extent, w.r.t. the XP theming APIs. There are some user32 controls and the window/dialog handlers that don't support theming yet and there are some performance issues that need resolving.
This would be set via the command line used to set the colour scheme since they can be set via the same .theme file. This is limited in that you need an XP theme for each native theme available.
== Native Theme Support
The main thing here is that Wine would monitor the native system for theme changes.
The colours of the native theme would be mapped to the Windows system colours, saved to the registry and then a WM_SYSCOLORCHANGED message would be sent to all open top-level windows so they could update to the new look.
Any metric data would be mapped in a similar way.
As for the theme, an implementation of uxtheme would map the API calls to the native calls. Here, it may be possible to just send a request to redraw everything on each active window. If not, a WM_THEMECHANGED message would need to be sent to all active windows.
The challenge with native theme support is two-fold: (1) it should work on any system - some have Gtk, some Qt and some Cocoa/Carbon, while others (like the *BSDs and OpenSolaris) are likely not to have those engines available; (2) it should not break any Windows application.
Note that as Vista has a different msstyles theming engine (it is a DLL), we could have the msstyles DLL expose the uxtheme API and have uxtheme call msstyles to do the rendering. That way, we could have a gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles that would bind to the corresponding theming engine. If the msstyles DLL does not expose those methods, the uxtheme engine could then fallback to the current XP theme processing.
For Mac theme support that would possibly require Objective-C code to be done properly, that theme could be an external package (possibly in darwine) that would be installed in addition to Wine. The same thing for the Qt engines, allowing them to directly interface with the C++ Qt APIs.
Thoughts? Ideas?
- Reece