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

[Reece Dunn]

2008/11/1 Steven Edwards <sedwards at bordeauxgroup.com>:
> On Sat, Nov 1, 2008 at 1:10 PM, Frank Richter <frank.richter at gmail.com> wrote:
>> So winetheme would have plugins - that seems to make the whole thing an
>> additional complication over straight uxtheme plugins, since you have
>> the application as an extra layer in the middle. And as already said, an
>> application may complicate things such as reacting to theme changes on
>> the fly.
>
> I've been lurking on this thread for a while and it seems to me the
> problem with themes really is one Wine cannot solve.

Wine can create an infrastructure to support bindings to different
toolkits. Due to the nature of some of those toolkits, some of the
bindings will have to live outside the Wine tree. So in that respect,
the problem can be something that Wine can solve.

> I don't know if
> the LSB or FDo specs have a human interface guideline system but it
> seems to me there needs to be some sort of theme engine bridge or some
> such at a lower level than WIne that the differing toolkits can use to
> come close to having a consistent interface even if its not 100% all
> of the time. I know there used to be back in the KDE2 days support to
> use GTK 1.x themes but this was before the days of FreeDesktop.org.

It would be fantastic to have one or more FDo specs for human-computer
interaction and - specifically for this topic - theming, widgets and
rendering those widgets using the selected theme.

In order to do that properly, you will need major buy-in from the Gtk,
Qt and other widget toolkit developers, as well as from Firefox,
OpenOffice, Gimp and other applications that have to have
infrastructures in place to support different toolkits. Done right, it
would mean that applications would only need to write to one back-end
to render the various widgets. They would need to ensure that the
correct bindings for this are on the system, but the bindings could be
external packages to the applications (for Mac, Windows and existing
versions of the Widget libraries) or in the widget libraries
themselves (for Gtk, Qt and others), so that you have a consistent
implementation.

The spec would also need to provide a way of notifying applications
when the theme has changed.

This would have the benefit of applications written using Gtk, Qt or
some other framework looking native on the users system.

> The right solution it would seem, if we cannot get proper human
> interface guidelines for linux, at get a free desktop spec that lays
> out a generic theme engine any of these toolkits can plug in to or a
> common file format they can all read at least. Perhaps that theme
> engine spec should then have a case for output in a format that Wine
> can understand or Wine's uxtheme and whatever else could be extended
> to read this FDo theme spec. We already do such a similar thing in
> shell32 for XDG Folders and the Root unix namespace. Of course this
> would not address Aqua/OS case but such a spec if adopted by
> KDE/GNOME/Enlightenment/etc would do wonders for us on
> BSD/Linux/Solaris/etc.

For Aqua/OS you would have an external package that implemented the
FDo spec and mapped it to the correct Carbon calls. Similarly for
Windows.

Also, it would be possible to provide an implementation of the spec
that used an msstyles/theme file. This would mean that the existing
uxtheme handling of the msstyles format will move there and the
uxtheme dll will just make the correct FDo spec calls. That also opens
up to people being able to use XP themes as the theme on their system
if they so choose.

- Reece