The future of the native theming support

[Ivan Akulinchev]

 > 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%29.aspx
[2] 
https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-render-background

On 26.04.2016 15:58, Alexandre Julliard wrote:
> Ivan Akulinchev <ivan.akulinchev at 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.
>