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

[Reece Dunn]

2008/11/1 Roderick Colenbrander <thunderbird2k at gmx.net>:
> My whole point is maintenance and distribution. Sure you could create different plugins for uxtheme but the language limitation won't allow such plugins to enter Wine. They would need to be maintained outside of Wine which would be bad. It has risks of bitrotting and second it would be a pain to package it all. I don't think we want such components maintained outside of Wine.

Sure. Those are potential problems. You can mitigate that by having an
extensible versioned API. COM (despite its flaws) has mechanisms in
place to support upward and backward compatibility of both sides of
the call (in this case uxtheme and the theme engine binding) and is
thus a potential platform for the API. A flat C API would work as
well, though.

> That all is the reason for having a 'winetheme' app which creates .msstyles themes and which uses GTK/QT/Cocoa as I think Alexandre could perhaps live with this as we wouldn't pollute any Wine dlls with 'bad' languages. But as I said this approach would require syncing themes at Wine startup and theme refreshing wouldn't work without some evil polling mechanism. Personally I wouldn't find this switching at runtime important though and I wonder if our dlls support this at all. (That would have to be fixed then but personally I don't give it a high priority)

Generating msstyles themes on the fly seems too complicated to me, as
well as being time consuming and potentially resource intensive. Also,
will winetheme be implemented to support all the available theme
engines in the single binary? If so, what about supporting additional
engines (e.g. Enlightenment)? How will it support both the Qt3 and Qt4
APIs? How do you differentiate what are available at build time and
what are available at runtime?

- Reece