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

[Roderick Colenbrander]

A tool which creates a .msstyles theme basically does the same as a uxtheme engine would do. A uxtheme engine plugin would use gtk/qt/cocoa to load colors, bitmaps and so on in a representation needed by uxtheme. The winetheme app would do the same but also have a way to write this data back from uxtheme into a .msstyles theme. I don't know the uxtheme API but it might already offer functionality for this (I mean creating a .msstyles theme from source).

The winetheme app would have plugins for gtk, qt and so on. Using winecfg you would need to set the WineLook to gtk/qt/cocoa and the winetheme app would use the requested backend. At startup winetheme could also detect which of the plugins are available. Plugins are compiled at Wine compile time and when a new toolkit comes out (gtk2->gtk3, qt3->qt4,..) we need to update the plugin or add a new one.

Roderick

> 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

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser