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