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