The future of the native theming support
So my GSoC proposal wasn't accepted this year. Probably it was my mistake by applying it too late, but this mail is not about this. Since a big research was already done, it would be fine to implement this feature anyway. The problem is that I still don't know what such people as Alexandre Julliard think about it. I got some positive feedback from normal users and even some Wine developers. However they don't make decisions about the Wine future and I don't want to spend my time if this feature will never get into upstream. As far as I know there already were some attempts to do something in this direction. But interesting patches I found in wine-patches were left without any response and Wine still looks like a monster from 90s. At the same time I see a lot of patches affecting the DirectX API. Is it the official position of the Wine maintainers to keep Wine as an OpenGL wrapper? Of course there are a lot of users who just want to play their Windows games on the Unix-like systems, but the need of working with normal desktop applications is still very high. There also were some questions about integrating new themes to the existing system. If it matters, I found a way to make it transparently for the end users. A new "GTK+" or even "Mac" theme can live together with old MSSTYLES themes without need of switching any "theme drivers" as it was said in my GSoC proposal. Regards, Ivan
On Mon, Apr 25, 2016 at 10:23:43AM +0200, Ivan Akulinchev wrote:
As far as I know there already were some attempts to do something in this direction. But interesting patches I found in wine-patches were left without any response and Wine still looks like a monster from 90s. At the same time I see a lot of patches affecting the DirectX API. Is it the official position of the Wine maintainers to keep Wine as an OpenGL wrapper? Of course there are a lot of users who just want to play their Windows games on the Unix-like systems, but the need of working with normal desktop applications is still very high.
I don't think anyone is ideologically opposed to the idea, but the problem is it's very hard to get right in such a way that won't break applications. I think a more likely option would be to bring it up to look like a modern Windows UI, or just any generic "modern" UI, even if it doesn't match the native toolkit. But even that would be a massive and difficult undertaking. Andrew
I don't think anyone is ideologically opposed to the idea, but the problem is it's very hard to get right in such a way that won't break applications.
Honestly I didn't see a popular GTK theme without tons of comments like "Oh my God! They killed XXX!". This way, if a GTK theme can break a native GTK application, a conflict with Windows applications is very likely. However this "break" doesn't mean a SEGFAULT crash, rather an unpleasant sight. You shouldn’t use this feature if you don't like it. On 25.04.2016 17:59, Andrew Eikum wrote:
On Mon, Apr 25, 2016 at 10:23:43AM +0200, Ivan Akulinchev wrote:
As far as I know there already were some attempts to do something in this direction. But interesting patches I found in wine-patches were left without any response and Wine still looks like a monster from 90s. At the same time I see a lot of patches affecting the DirectX API. Is it the official position of the Wine maintainers to keep Wine as an OpenGL wrapper? Of course there are a lot of users who just want to play their Windows games on the Unix-like systems, but the need of working with normal desktop applications is still very high.
I don't think anyone is ideologically opposed to the idea, but the problem is it's very hard to get right in such a way that won't break applications. I think a more likely option would be to bring it up to look like a modern Windows UI, or just any generic "modern" UI, even if it doesn't match the native toolkit. But even that would be a massive and difficult undertaking.
Andrew
Ivan Akulinchev <ivan.akulinchev(a)gmail.com> writes:
So my GSoC proposal wasn't accepted this year. Probably it was my mistake by applying it too late, but this mail is not about this.
Since a big research was already done, it would be fine to implement this feature anyway. The problem is that I still don't know what such people as Alexandre Julliard think about it. I got some positive feedback from normal users and even some Wine developers. However they don't make decisions about the Wine future and I don't want to spend my time if this feature will never get into upstream.
Improvements to the existing comctl32 and uxtheme to properly support Windows themes would be most welcome, and would be a prerequisite for other changes anyway. More test cases would also be very helpful. Whether we want to load a native toolkit to replace common controls is debatable, and that part is not going to get upstream without some very convincing arguments. A tool to generate Windows themes from the native ones would probably give most of the benefits, without the compatibility issues of a native toolkit. -- Alexandre Julliard julliard(a)winehq.org
Improvements to the existing comctl32 and uxtheme to properly support Windows themes would be most welcome, and would be a prerequisite for other changes anyway. More test cases would also be very helpful.
The best way to test uxtheme.dll is to create an own theme. However Windows has a protection against third-party themes. It’s easy to break, but isn’t allowed by EULA. Do we need Wine-only tests?
Whether we want to load a native toolkit to replace common controls is debatable, and that part is not going to get upstream without some very convincing arguments.
But I don't want to *replace* common controls with a native toolkit. I suggest another solution. There is already a way for styling this controls. For example, there is a function DrawThemeBackground [1]. GTK provides a similar function named gtk_render_background [2]. The only thing we need to do, is to convert the arguments of the first function to the arguments of the second one. In this case, DrawThemeBackground works with a GDI device context, and gtk_render_background uses as Cairo surface. This thing was already done. Then I figured out, the communication between Common Controls and Visual Styles API is very poor. According to MSDN, it's not a design problem, rather an implementation. This way I want to improve this "communication" and to make the existing UxTheme implementation friends with GTK. Again, the only thing I want to change is a library, corresponding for providing of some images. This images can NOT break anything. The reason why I don't use the existing implementation is because the algorithm of generating this images is not trivial and it's very hard to implement it using the existing (MSSTYLES) file format.
A tool to generate Windows themes from the native ones would probably give most of the benefits, without the compatibility issues of a native toolkit.
Many themes are shipped in different implementations. This way we can make our msstyles implementations for the most common themes and change winecfg to look for the available themes in Z:\usr\share\themes\*\mssttyles as well. However we can’t do it automatically. The basic idea of Windows themes is too split all controls in 9 areas and combine it for the requested size. First of all, we don’t know where to crop. Then, many GTK themes have a complex background. If you try to stretch it, the result will be terrible. So I’m against this idea. See also the last paragraph of the previous point. For example, you want to create a button. The code corresponding for the signals handling and so on still lives in comctl32.dll. It also calls uxtheme.dll to draw a representation of this button in some area. But now uxtheme.dll draws this representation according to a bitmap from a .msstyles file and I want to get this bitmap directly from GTK. Just a bitmap, with the same size and the same purpose. And nothing more. I fail to see how can this bitmap break something in an application. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb773289%28v=vs.85%... [2] https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-render-back... On 26.04.2016 15:58, Alexandre Julliard wrote:
Ivan Akulinchev <ivan.akulinchev(a)gmail.com> writes:
So my GSoC proposal wasn't accepted this year. Probably it was my mistake by applying it too late, but this mail is not about this.
Since a big research was already done, it would be fine to implement this feature anyway. The problem is that I still don't know what such people as Alexandre Julliard think about it. I got some positive feedback from normal users and even some Wine developers. However they don't make decisions about the Wine future and I don't want to spend my time if this feature will never get into upstream.
Improvements to the existing comctl32 and uxtheme to properly support Windows themes would be most welcome, and would be a prerequisite for other changes anyway. More test cases would also be very helpful.
Whether we want to load a native toolkit to replace common controls is debatable, and that part is not going to get upstream without some very convincing arguments.
A tool to generate Windows themes from the native ones would probably give most of the benefits, without the compatibility issues of a native toolkit.
Ivan Akulinchev <ivan.akulinchev(a)gmail.com> writes:
Improvements to the existing comctl32 and uxtheme to properly support Windows themes would be most welcome, and would be a prerequisite for other changes anyway. More test cases would also be very helpful.
The best way to test uxtheme.dll is to create an own theme. However Windows has a protection against third-party themes. It’s easy to break, but isn’t allowed by EULA. Do we need Wine-only tests?
I expect that it would be possible to test already quite a bit by using the standard Windows themes.
Again, the only thing I want to change is a library, corresponding for providing of some images. This images can NOT break anything. The reason why I don't use the existing implementation is because the algorithm of generating this images is not trivial and it's very hard to implement it using the existing (MSSTYLES) file format.
If it's only the images, I agree that it's less likely to break things, but it's not a very good user experience either, since the controls look native but behave like Windows controls. That doesn't mean it couldn't be added as an option, but we should first make sure that we can support MSSTYLES themes properly, and ideally provide some decent-looking default theme with Wine. -- Alexandre Julliard julliard(a)winehq.org
There also were some questions about integrating new themes to the existing system. If it matters, I found a way to make it transparently for the end users. A new "GTK+" or even "Mac" theme can live together with old MSSTYLES themes without need of switching any "theme drivers" as it was said in my GSoC proposal.
wine-staging has an optional feature to do this with Gtk [1]. The results are so-so. The issue is that typically uxtheme and an external toolkit have very different ways of describing layout and therefore the there is no 1:1 mapping between any arbitrary Gtk theme and uxtheme. The result is that certain themes look much more glitchy than others - but it will look extremely crappy if the integration is less than pixel perfect, which is going to be extremely hard without lots of fragile heuristics, or manual artistic tweaks. I recommend having a conversation with the author of those wine-staging patches, so you can find out how things are going with that. He's got some things working, but still lots of glitches. These glitches may be fixable - but I'm fearful that some problems may come down to a design conflict between windows and Gtk+. If you want to spend time on this, I personally would love to see it come to fruition - but be warned, it's a risky project. In some ways this is analogous to the wine icon set. Ideally it would be nice to pick up icons from the host /usr/share/icons directory. The problem being that in windows, icons are baked into the executable binary. In principle applications could be tricked about the binary resources at runtime, but in practice this is getting into very unpleasant territory where we're in severe danger of causing breakage. So when I updated the icons [2], I chose the Tango icon theme because it represented a modern-looking compromise between the icon styles of most desktop environments. Andrew Eikum's suggestion is rather similar, but for the ux theme. To me that sounds a lot easier to do. Joel [1] https://github.com/wine-compholio/wine-staging/tree/master/patches/uxtheme-G... [2] https://airwebreathe.org.uk/doku.php?id=wine_icons
I recommend having a conversation with the author of those wine-staging patches
As far as I know, the feature you have seen in Wine Staging is based on my old Proof-of-Concept implementation of this idea [1, 2], and this conversation with myself would be a little bit weird. I have tested it with some popular themes and it looks fine for me [3, 4, 5, 6]. But then I saw some screenshots by the Wine Staging team [7, 8] and it was terrible. By the way, someone asked me why does the existing implementation suck. Just look at the screenshots [7] and [8] again. This is the limit of what can be done by replacing the uxtheme.dll implementation. If you want more, comctl32 should be fixed. So, my solution wasn’t perfect, I agree. But to fix it, I’ll have to do a lot of changes inside the existing Wine code. And that’s the problem. [1] https://github.com/akulinchev/uxthemegtk [2] https://wine-staging.com/news/2015-08-09-release-1.7.49.html [3] https://github.com/akulinchev/uxthemegtk/raw/master/dist/winecfg-clearlooks.... [4] https://github.com/akulinchev/uxthemegtk/raw/master/dist/winecfg2-clearlooks... [5] https://github.com/akulinchev/uxthemegtk/raw/master/dist/winecfg-ambiance.pn... [6] https://github.com/akulinchev/uxthemegtk/raw/master/dist/winecfg2-ambiance.p... [7] https://wine-staging.com/images/gtk3_winecfg.png [8] https://wine-staging.com/images/gtk3_file.png On 26.04.2016 17:35, Joel Holdsworth wrote:
There also were some questions about integrating new themes to the existing system. If it matters, I found a way to make it transparently for the end users. A new "GTK+" or even "Mac" theme can live together with old MSSTYLES themes without need of switching any "theme drivers" as it was said in my GSoC proposal.
wine-staging has an optional feature to do this with Gtk [1]. The results are so-so.
The issue is that typically uxtheme and an external toolkit have very different ways of describing layout and therefore the there is no 1:1 mapping between any arbitrary Gtk theme and uxtheme. The result is that certain themes look much more glitchy than others - but it will look extremely crappy if the integration is less than pixel perfect, which is going to be extremely hard without lots of fragile heuristics, or manual artistic tweaks.
I recommend having a conversation with the author of those wine-staging patches, so you can find out how things are going with that. He's got some things working, but still lots of glitches. These glitches may be fixable - but I'm fearful that some problems may come down to a design conflict between windows and Gtk+.
If you want to spend time on this, I personally would love to see it come to fruition - but be warned, it's a risky project.
In some ways this is analogous to the wine icon set. Ideally it would be nice to pick up icons from the host /usr/share/icons directory. The problem being that in windows, icons are baked into the executable binary. In principle applications could be tricked about the binary resources at runtime, but in practice this is getting into very unpleasant territory where we're in severe danger of causing breakage.
So when I updated the icons [2], I chose the Tango icon theme because it represented a modern-looking compromise between the icon styles of most desktop environments.
Andrew Eikum's suggestion is rather similar, but for the ux theme. To me that sounds a lot easier to do.
Joel
[1] https://github.com/wine-compholio/wine-staging/tree/master/patches/uxtheme-G...
I saw some screenshots by the Wine Staging team [7, 8] and it was terrible. By the way, someone asked me why does the existing implementation suck. Just look at the screenshots [7] and [8] again. This is the limit of what can be done by replacing the uxtheme.dll implementation. If you want more, comctl32 should be fixed.
This is my experience running Adwaita: https://airwebreathe.org.uk/lib/exe/fetch.php?media=space:20160426-wine-gtk-... . - Clipped tab edges - Clipped check boxes - Clipped slider handle It looks a bit better if I boost the DPI so that the font size matches the rest of the desktop. But the clipping issues don't go away. Joel
participants (4)
-
Alexandre Julliard -
Andrew Eikum -
Ivan Akulinchev -
Joel Holdsworth