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

[Reece Dunn]

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