Hi,
There is a discussion going on over at https://bugs.launchpad.net/ubuntu/+source/wine/+bug/111061 about improving Wine's look and feel to better match the system that it is running on.
The situation is as follows:
== Colour Schemes
Wine supports these by reading the settings from the registry. Winecfg can load a .theme file containing a colour profile and adapt accordingly (saving those settings to the registry).
At the moment, if you need to script this (e.g. when installing Wine) you need to manipulate the registry. It would be helpful if winecfg (or some other helper utility) supported setting the theme file on the command line.
In addition to this, if the user changes the theme used on their system it would not be reflected by Wine.
== Windows Theme Support
Windows theming support is in place to some extent, w.r.t. the XP theming APIs. There are some user32 controls and the window/dialog handlers that don't support theming yet and there are some performance issues that need resolving.
This would be set via the command line used to set the colour scheme since they can be set via the same .theme file. This is limited in that you need an XP theme for each native theme available.
== Native Theme Support
The main thing here is that Wine would monitor the native system for theme changes.
The colours of the native theme would be mapped to the Windows system colours, saved to the registry and then a WM_SYSCOLORCHANGED message would be sent to all open top-level windows so they could update to the new look.
Any metric data would be mapped in a similar way.
As for the theme, an implementation of uxtheme would map the API calls to the native calls. Here, it may be possible to just send a request to redraw everything on each active window. If not, a WM_THEMECHANGED message would need to be sent to all active windows.
The challenge with native theme support is two-fold: (1) it should work on any system - some have Gtk, some Qt and some Cocoa/Carbon, while others (like the *BSDs and OpenSolaris) are likely not to have those engines available; (2) it should not break any Windows application.
Note that as Vista has a different msstyles theming engine (it is a DLL), we could have the msstyles DLL expose the uxtheme API and have uxtheme call msstyles to do the rendering. That way, we could have a gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles that would bind to the corresponding theming engine. If the msstyles DLL does not expose those methods, the uxtheme engine could then fallback to the current XP theme processing.
For Mac theme support that would possibly require Objective-C code to be done properly, that theme could be an external package (possibly in darwine) that would be installed in addition to Wine. The same thing for the Qt engines, allowing them to directly interface with the C++ Qt APIs.
Thoughts? Ideas?
- Reece
Hi,
There are a bunch of uxtheme / control theming bugs which need to be fixed but lets ignore those issues for now.
In the end we need to support a bunch of different theme engines GTK, QT, Cocoa and perhaps later on more. In theory it would be possible to create a different uxtheme backend for each different toolkit. One major issue is the language which each of these toolktis is written in. GTK would be fine as it is C but QT and Cocoa require respectively C++ and Objective C. Alexandre doesn't want such languages in (although he might make an exception for the winecocoa driver if it is really, really needed).
While using a language different than C is a definitive no, I think Alexandre might allow the use of other languages in helper programs. The best way would be to write a separate program (which would have backends for all the needed toolkits) which generates a .msstyles theme (or if Vista uses a newer and better format, lets directly move to that format). The main issue would then be on how to sync themes. I guess that would need to be done at wine startup.
Roderick
Hi,
There is a discussion going on over at https://bugs.launchpad.net/ubuntu/+source/wine/+bug/111061 about improving Wine's look and feel to better match the system that it is running on.
The situation is as follows:
== Colour Schemes
Wine supports these by reading the settings from the registry. Winecfg can load a .theme file containing a colour profile and adapt accordingly (saving those settings to the registry).
At the moment, if you need to script this (e.g. when installing Wine) you need to manipulate the registry. It would be helpful if winecfg (or some other helper utility) supported setting the theme file on the command line.
In addition to this, if the user changes the theme used on their system it would not be reflected by Wine.
== Windows Theme Support
Windows theming support is in place to some extent, w.r.t. the XP theming APIs. There are some user32 controls and the window/dialog handlers that don't support theming yet and there are some performance issues that need resolving.
This would be set via the command line used to set the colour scheme since they can be set via the same .theme file. This is limited in that you need an XP theme for each native theme available.
== Native Theme Support
The main thing here is that Wine would monitor the native system for theme changes.
The colours of the native theme would be mapped to the Windows system colours, saved to the registry and then a WM_SYSCOLORCHANGED message would be sent to all open top-level windows so they could update to the new look.
Any metric data would be mapped in a similar way.
As for the theme, an implementation of uxtheme would map the API calls to the native calls. Here, it may be possible to just send a request to redraw everything on each active window. If not, a WM_THEMECHANGED message would need to be sent to all active windows.
The challenge with native theme support is two-fold: (1) it should work on any system - some have Gtk, some Qt and some Cocoa/Carbon, while others (like the *BSDs and OpenSolaris) are likely not to have those engines available; (2) it should not break any Windows application.
Note that as Vista has a different msstyles theming engine (it is a DLL), we could have the msstyles DLL expose the uxtheme API and have uxtheme call msstyles to do the rendering. That way, we could have a gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles that would bind to the corresponding theming engine. If the msstyles DLL does not expose those methods, the uxtheme engine could then fallback to the current XP theme processing.
For Mac theme support that would possibly require Objective-C code to be done properly, that theme could be an external package (possibly in darwine) that would be installed in addition to Wine. The same thing for the Qt engines, allowing them to directly interface with the C++ Qt APIs.
Thoughts? Ideas?
- Reece
2008/11/1 Roderick Colenbrander thunderbird2k@gmx.net:
In the end we need to support a bunch of different theme engines GTK, QT, Cocoa and perhaps later on more. In theory it would be possible to create a different uxtheme backend for each different toolkit. One major issue is the language which each of these toolktis is written in. GTK would be fine as it is C but QT and Cocoa require respectively C++ and Objective C. Alexandre doesn't want such languages in (although he might make an exception for the winecocoa driver if it is really, really needed).
I mentioned that in my email. The idea that wine would host the XP msstyles theme (the fallback behaviour for uxtheme), and a GTK plugin to support GTK themes. Then other projects can provide a Qt and Cocoa plugin, so they can be written in the toolkit's language.
While using a language different than C is a definitive no, I think Alexandre might allow the use of other languages in helper programs. The best way would be to write a separate program (which would have backends for all the needed toolkits) which generates a .msstyles theme (or if Vista uses a newer and better format, lets directly move to that format). The main issue would then be on how to sync themes. I guess that would need to be done at wine startup.
The problem with the Vista theme is that it is binary and completely undocumented, making it very difficult to reverse engineer.
Moving forward, we'll probably need to be able to support both XP and Vista themes (possibly Windows 7 and later as well if the theme format has changed). I don't know if moving the processing of that into a separate process would help, though.
When syncing themes, you can have uxtheme.dll loading the correct engine if enabled (see my "Use the native theme" option idea in my previous discussion on improving winecfg). Then, if the system theme changes, the WM_THEMECHANGED message needs to be sent to all top-level applications so they can refresh themselves to use that new theme. How that happens and where needs to be figured out.
And yes, the bugs in uxtheme and the various controls need fixing.
- Reece
IMHO WINE developers should first focus on applications, not their look. I believe most users would like to see Visual Studio running in gray instead of not running as native.
Dnia 2008-11-01, sob o godzinie 14:58 +0000, Reece Dunn pisze:
2008/11/1 Roderick Colenbrander thunderbird2k@gmx.net:
In the end we need to support a bunch of different theme engines GTK, QT, Cocoa and perhaps later on more. In theory it would be possible to create a different uxtheme backend for each different toolkit. One major issue is the language which each of these toolktis is written in. GTK would be fine as it is C but QT and Cocoa require respectively C++ and Objective C. Alexandre doesn't want such languages in (although he might make an exception for the winecocoa driver if it is really, really needed).
I mentioned that in my email. The idea that wine would host the XP msstyles theme (the fallback behaviour for uxtheme), and a GTK plugin to support GTK themes. Then other projects can provide a Qt and Cocoa plugin, so they can be written in the toolkit's language.
While using a language different than C is a definitive no, I think Alexandre might allow the use of other languages in helper programs. The best way would be to write a separate program (which would have backends for all the needed toolkits) which generates a .msstyles theme (or if Vista uses a newer and better format, lets directly move to that format). The main issue would then be on how to sync themes. I guess that would need to be done at wine startup.
The problem with the Vista theme is that it is binary and completely undocumented, making it very difficult to reverse engineer.
Moving forward, we'll probably need to be able to support both XP and Vista themes (possibly Windows 7 and later as well if the theme format has changed). I don't know if moving the processing of that into a separate process would help, though.
When syncing themes, you can have uxtheme.dll loading the correct engine if enabled (see my "Use the native theme" option idea in my previous discussion on improving winecfg). Then, if the system theme changes, the WM_THEMECHANGED message needs to be sent to all top-level applications so they can refresh themselves to use that new theme. How that happens and where needs to be figured out.
And yes, the bugs in uxtheme and the various controls need fixing.
- Reece
2008/11/1 Tomasz Sałaciński tsalacinski@gmail.com:
IMHO WINE developers should first focus on applications, not their look. I believe most users would like to see Visual Studio running in gray instead of not running as native.
Application functionality is important. Applications should run as well as they do on Windows (ignoring Vista in that statement!) on Wine out of the box, without the user having to do anything aside from run the installer as they do in Windows.
That said, usability and the look and feel of an application are important. Just compare Firefox 2 running on Linux or Mac with Firefox 3 doing the same.
Also, not all the developers know how things like the kernel, networking or cryptographic APIs work on Windows.
I am a GUI developer, so I am focusing on what I know the best -- the UI.
- Reece
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.
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)
Roderick
2008/11/1 Roderick Colenbrander thunderbird2k@gmx.net:
In the end we need to support a bunch of different theme engines GTK,
QT, Cocoa and perhaps later on more. In theory it would be possible to create a different uxtheme backend for each different toolkit. One major issue is the language which each of these toolktis is written in. GTK would be fine as it is C but QT and Cocoa require respectively C++ and Objective C. Alexandre doesn't want such languages in (although he might make an exception for the winecocoa driver if it is really, really needed).
I mentioned that in my email. The idea that wine would host the XP msstyles theme (the fallback behaviour for uxtheme), and a GTK plugin to support GTK themes. Then other projects can provide a Qt and Cocoa plugin, so they can be written in the toolkit's language.
While using a language different than C is a definitive no, I think
Alexandre might allow the use of other languages in helper programs. The best way would be to write a separate program (which would have backends for all the needed toolkits) which generates a .msstyles theme (or if Vista uses a newer and better format, lets directly move to that format). The main issue would then be on how to sync themes. I guess that would need to be done at wine startup.
The problem with the Vista theme is that it is binary and completely undocumented, making it very difficult to reverse engineer.
Moving forward, we'll probably need to be able to support both XP and Vista themes (possibly Windows 7 and later as well if the theme format has changed). I don't know if moving the processing of that into a separate process would help, though.
When syncing themes, you can have uxtheme.dll loading the correct engine if enabled (see my "Use the native theme" option idea in my previous discussion on improving winecfg). Then, if the system theme changes, the WM_THEMECHANGED message needs to be sent to all top-level applications so they can refresh themselves to use that new theme. How that happens and where needs to be figured out.
And yes, the bugs in uxtheme and the various controls need fixing.
- Reece
2008/11/1 Roderick Colenbrander thunderbird2k@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
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@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
On 01.11.2008 16:49, Roderick Colenbrander wrote:
The winetheme app would have plugins
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.
-f.r.
On Sat, Nov 1, 2008 at 1:10 PM, Frank Richter frank.richter@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. 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.
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.
2008/11/1 Steven Edwards sedwards@bordeauxgroup.com:
On Sat, Nov 1, 2008 at 1:10 PM, Frank Richter frank.richter@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
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.
On 01.11.2008 21:21, Reece Dunn wrote:
In order to do that properly, you will need major buy-in from the Gtk, Qt and other widget toolkit developers,
FWIW, I recall having read some Planet GNOME blog posts where people expressed, well, a bit of unhappiness with GTK's current theming system. (Apparently a lot of hacks are needed, some even for specific applications.) So a buy-in might be possible from them, if you promise something better than you have now ;)
-f.r.
On 01.11.2008 14:04, Reece Dunn wrote:
Note that as Vista has a different msstyles theming engine (it is a DLL),
It's also a DLL on XP. Note that in both cases no code is exported, the DLLs serve only as a container for the theme data, stored as resources.
we could have the msstyles DLL expose the uxtheme API and have uxtheme call msstyles to do the rendering. That way, we could have a gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles
That sounds like misappropriating the msstyles 'format'. The idea of "theming engine plugins" is a good one, but then some other mechanism than abusing the msstyles extension should be used to detect these plugins. Some ideas: an extension (but a different, unique one), putting them into a special directory, listing engines in the registry.
Anyhow, this is somewhat bikeshedding ;P
First step would probably be to define a theming plugin API - you say that the theming plugins would just export the whole uxtheme API. However, it could be possible that the theming plugin interface can be simplified compared to that, with uxtheme.dll filling the gaps. (After all, a simpler interface can mean a simpler plugin implementation...)
-f.r.
2008/11/1 Frank Richter frank.richter@gmail.com:
On 01.11.2008 14:04, Reece Dunn wrote:
we could have the msstyles DLL expose the uxtheme API and have uxtheme call msstyles to do the rendering. That way, we could have a gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles
That sounds like misappropriating the msstyles 'format'. The idea of "theming engine plugins" is a good one, but then some other mechanism than abusing the msstyles extension should be used to detect these plugins. Some ideas: an extension (but a different, unique one), putting them into a special directory, listing engines in the registry.
Anyhow, this is somewhat bikeshedding ;P
:). Your point makes more sense.
First step would probably be to define a theming plugin API - you say that the theming plugins would just export the whole uxtheme API. However, it could be possible that the theming plugin interface can be simplified compared to that, with uxtheme.dll filling the gaps. (After all, a simpler interface can mean a simpler plugin implementation...)
That is a good idea.
It would also be a good idea to look at the capabilities of the major theming engines (Gtk, Qt, Cocoa) and possibly some others like the one used by Enlightemnent and try to abstract an API that can accommodate them all in a straightforward way.
Note also that there is the added complication that the interface wine uses will need to be a native one, so it can interact with the native cocoa, qt or gtk libraries.
- Reece
On 01.11.2008 16:06, Reece Dunn wrote:
It would also be a good idea to look at the capabilities of the major theming engines (Gtk, Qt, Cocoa) and possibly some others like the one used by Enlightemnent and try to abstract an API that can accommodate them all in a straightforward way.
Definitely.
Note also that there is the added complication that the interface wine uses will need to be a native one, so it can interact with the native cocoa, qt or gtk libraries.
This is already done in Wine, e.g. look at some of the TWAIN plugins Wine ships - they're DLLs but access native APIs like gphoto, iirc.
-f.r.
Reece Dunn-2 wrote:
Thoughts? Ideas?
I'm just a user, not a dev, so forgive me if this sounds stupid, but it seems to me like it would be simpler to just create some sort of layer that forwards all calls to the Win32 theming API to Qt, and make Wine dependent on Qt (perhaps as a GSoC project?). Qt bends over backwards to maintain a native look and feel on all major platforms, including Windows, OS X, KDE/X11, and GNOME/Xfce/BBQ/X11 (in 4.5), so Wine's codebase wouldn't have to be overly complicated by hacks to support each platform. This approach would also have the benefit of rendering the QuartzDriver planned for Wine 1.2 completely unnecessary, if I'm not mistaken. Since Qt is maintained by a ton of devs unrelated to the Wine project, this would also allow Wine to ignore changes in this area specific to each platform, whereas with other approaches I've seen in this thread Wine would have to constantly adapt to each change and put in the work necessary to port the native theming to a new platform; of course, Wine would still have to adapt to changes in the Qt API, but that would be much more predictable and presumably less to deal with.
Reece Dunn-2 wrote:
Thoughts? Ideas?
I'm just a user, not a dev, so forgive me if this sounds stupid, but it seems to me like it would be simpler to just create some sort of layer that forwards all calls to the Win32 theming API to Qt, and make Wine dependent on Qt (perhaps as a GSoC project?). Qt bends over backwards to maintain a native look and feel on all major platforms, including Windows, OS X, KDE/X11, and GNOME/Xfce/BBQ/X11 (in 4.5), so Wine's codebase wouldn't have to be overly complicated by hacks to support each platform. This approach would also have the benefit of rendering the QuartzDriver planned for Wine 1.2 completely unnecessary, if I'm not mistaken. Since Qt is maintained by a ton of devs unrelated to the Wine project, this would also allow Wine to ignore changes in this area specific to each platform, whereas with other approaches I've seen in this thread Wine would have to constantly adapt to each change and put in the work necessary to port the native theming to a new platform; of course, Wine would still have to adapt to changes in the Qt API, but that would be much more predictable and presumably less to deal with. -- View this message in context: http://www.nabble.com/Wine-integration-with-native-%28Gtk%2C-Qt%2C-Cocoa-Car... Sent from the Wine - Devel mailing list archive at Nabble.com.
This is technically not possible. We can't use native APIs for drawing. Roderick
Roderick Colenbrander wrote:
This is technically not possible. We can't use native APIs for drawing.
Ah, that sucks. Out of curiosity, why is that? As a non-dev, logically it seems like Wine, which translates Win32 calls for the kernel and X11, would be able to do the same for Qt, but then again I know next to nothing about the internals of Wine. Is it that doing so would require a major redesign, isn't feasible for whatever reason, or just isn't possible at all?
buu700 wrote:
Roderick Colenbrander wrote:
This is technically not possible. We can't use native APIs for drawing.
Ah, that sucks. Out of curiosity, why is that? As a non-dev, logically it seems like Wine, which translates Win32 calls for the kernel and X11, would be able to do the same for Qt, but then again I know next to nothing about the internals of Wine. Is it that doing so would require a major redesign, isn't feasible for whatever reason, or just isn't possible at all?
Windows' standard controls, windows, fonts, etc work completely different from QT ones. Win32 API exposes a lot of inner-workings of each control. And lots of applications depend on that. I'm not even talking about how the pieces fit together.
In short - for most windows apps to work controls have to behave in a very particular way which dramatically differs from any other toolkit.
And no Wine doesn't just "translates win calls to kernel and X". Wine re-implements all of the windows' user space on top of X, kernel and other libraries.
Vitaliy
-
buu700 -
Frank Richter -
Reece Dunn -
Roderick Colenbrander -
Steven Edwards -
Tomasz Sałaciński -
Vitaliy Margolen