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