Comment 39 for bug 111061

> Why is all the talk about adapting color schemes, when a much cleaner solution would be to just
> have GTK draw the wine windows, like mono, java and other languages do? What makes wine
>so special that it cant implement something like Qt does with QGtkStyle (making qt look like gtk)?

Qt has its own theming API, so that calls to the Qt engine can be mapped to the Gtk engine.

Windows did not support a theming engine before XP (and then you have to call the correct APIs and mark your application to be theming aware). Applications can get the system colours and interrogate some of the metric information (such as the width of a scrollbar). An application will (if it is written correctly) get those system colours to render different parts of the application. If it is a text editor, it will select the window background and text colour to use, for example.

For applications that support theming the situation is better, but there you are limited to what is available in the XP, Vista and soon to be Windows 7 APIs.

Note that because Wine is multi-platform it will need to work with Gtk, Gt, Cocoa/Carbon and also in the absence of these (e.g. if you are running on OpenSolaris).

In addition to this, the Wine theming support is not yet to the point where it will render an XP theme (like the Zune theme) perfectly and efficiently.

Providing a colour scheme profile will make any Windows compliant application look better and stand out less. Having an XP-style theme that matches the Gtk theme will give a more natural look. Providing hooks into the native theming engines will give the best look and feel, but will need to be done right in order to get it accepted upstream.

It's all about ordering the tasks by how easy they are. The colour profile stuff already works, so is the easiest to do. Full blown integration is the hardest.