http://bugs.winehq.org/show_bug.cgi?id=5382
--- Comment #19 from loonyphoenix@gmail.com 2009-11-15 12:24:05 ---
It only seems so easy. Wine shouldn't depend on GTK/Qt or anything else, controls should be drawn and work as much close to natives as possible.
I thought Wine was supposed to provide a seamless native layer for Windows application in Unixes, but this philosophy of separation seems a lot like what we get with virtual machines. Whereas Wine Myths (http://wiki.winehq.org/Debunking_Wine_Myths) supposedly states: "Wine integrates with the desktop ... and makes Windows applications first-class citizens. Now you can ... place that application's window side by side with native applications". The next logical step with the integration aspect is, in my opinion, theme integration, so that placing Wine applications side by side with native ones wouldn't make them look crippled in comparison.
Complete native themes support is enough here to treat this bug fixed. I don't know if generating .theme file + some registry data from Qt/GTK theme data is possible, but it definitely should be an external tool.
As far as I know, those themes are unusable in Wine, because they are so slow and CPU-hungry no one uses them. Besides, there is no external tool yet, so the problem isn't solved. Plus, I think this tool should be part of the Wine project. Who said Wine should only consist of the layer itself plus applications that it can run? Who would object to an external, Linux-native configurtion tool, I wonder?