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

[Steven Edwards]

On Sat, Nov 1, 2008 at 4:21 PM, Reece Dunn <msclrhd at googlemail.com> wrote:
> 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.

Maybe I should not have said that wine cannot solve it but that Wine
alone cannot solve this problem without a proper HIG or Theming spec
as part of FDo would be an effort doomed to obsolescence or constant
maintaince. Francois spent a lot of time working on menus for
CodeWeavers as the menu system evolved on Linux over the years and the
ultimate results we see with XDG are the result of evolution and
catchup until a good spec was ultimately written and adopted. Thanks
to this spec, the portland toolset was developed and many new
applications don't have to go through hell just to do simple stuff
like creating and deleting menus in an automated fashion.

> 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.

It sounds like we have the beginnings of the requirements section for a
proposed specification already =)

> 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.

I like this idea. If the msstyles/theme file format is already
documented and not license restricted I don't see any reason why the
spec could not adopt the Microsoft format or something similar to it.

As I stated in my first reply, I know less than nothing about themes
and the current state of Linux Human Interface Guidelines with regards
to theming. If the consensus is that before this theming bridge tool
is developed, that we look in to making it or a library/file format
regarding theming a standard part of FD.o, I am happy to do some
research and help write a draft spec with you.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo