The future of the native theming support

Ivan Akulinchev ivan.akulinchev at
Tue Apr 26 17:10:58 CDT 2016

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


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]
> [2]

More information about the wine-devel mailing list