[GSoC] Support of pluggable theming engines

[André Hentschel]

Hi Ivan, all,

You say in your proposal that you want to start with rewriting 30% of comctl32.
Why so much?
Is it currently needed for the gtk3 code in wine-staging?

[Ivan Akulinchev]

Hi André!

Well, I didn't do exact calculations. But as I wrote, the theming
support in comctl32.dll done wrong. As far I know, the authors are aware
of this, but have no time or wish to fix it (just see their tests marked
as todo_wine, all this tests done right).
> Is it currently needed for the gtk3 code in wine-staging?

Yep. Try to run winecfg, select any theme, launch any application. Find
a themed button, push it and hold. See what's happend? There was a patch
for fixing it [1], another one [can't find a link], but all this patches
were not accepted, because the common problem lies above.

Now open notepad, click Help -> About, see what's happend? The whole
dialog is not themed! I already tryed to locate this problem.
shell32.dll called user32.dll, which created a dialog. But user32 has
it's own controls and wasn't aware comctl32.dll has another. That's
because the theming support in comctl32.dll done in the wrong way.

The whole theming support in comctl32 is a big hack. So I can write some
hacks for hacks, but why? What should do the next guy, who decides to
add some hacks for hacks for hacks? :-) It's a dead way...

[1] https://www.winehq.org/pipermail/wine-patches/2015-August/141599.html

26.03.16 15:47, André Hentschel wrote:
> Hi Ivan, all,
>
> You say in your proposal that you want to start with rewriting 30% of comctl32.
> Why so much?
> Is it currently needed for the gtk3 code in wine-staging?

[Nikolay Sivov]

On 26.03.2016 20:24, Ivan Akulinchev wrote:
> Hi André!
>
> Well, I didn't do exact calculations. But as I wrote, the theming
> support in comctl32.dll done wrong. As far I know, the authors are aware
> of this, but have no time or wish to fix it (just see their tests marked
> as todo_wine, all this tests done right).
> > Is it currently needed for the gtk3 code in wine-staging?
>
> Yep. Try to run winecfg, select any theme, launch any application. Find
> a themed button, push it and hold. See what's happend? There was a patch
> for fixing it [1], another one [can't find a link], but all this patches
> were not accepted, because the common problem lies above.
>
> Now open notepad, click Help -> About, see what's happend? The whole
> dialog is not themed! I already tryed to locate this problem.
> shell32.dll called user32.dll, which created a dialog. But user32 has
> it's own controls and wasn't aware comctl32.dll has another. That's
> because the theming support in comctl32.dll done in the wrong way.
>
> The whole theming support in comctl32 is a big hack. So I can write some
> hacks for hacks, but why? What should do the next guy, who decides to
> add some hacks for hacks for hacks? :-) It's a dead way...

If you're talking about comctl32 v6 separation, that's true, it's not
working right now. Getting it right could be a gsoc project on its own,
and the way to approach it has to be discussed beforehand. Theming
support is minor issue though comparing to missing new features for
Button for example, and likely for the rest of former user32 controls
too. Having properly implemented user controls is far more important
than having partially working gtk3 disguise, I agree with you, making it
work without hacks is a preferred way.
> [1] https://www.winehq.org/pipermail/wine-patches/2015-August/141599.html
>
> 26.03.16 15:47, André Hentschel wrote:
> > Hi Ivan, all,
> >
> > You say in your proposal that you want to start with rewriting 30% of comctl32.
> > Why so much?
> > Is it currently needed for the gtk3 code in wine-staging?

[Ivan Akulinchev]

> Having properly implemented user controls is far more important than
> having partially working gtk3 disguise.

One thing depends on another. When I worked on my own UxTheme
implementation, I found that comctl32 likes to send 0 instead of
properly arguments. It angered me.

So if I want to get a perfect GTK3-theming, I have to fix comctl32 too.

[Nikolay Sivov]

On 26.03.2016 20:52, Ivan Akulinchev wrote:
> > Having properly implemented user controls is far more important than
> > having partially working gtk3 disguise.
>
> One thing depends on another. When I worked on my own UxTheme
> implementation, I found that comctl32 likes to send 0 instead of
> properly arguments. It angered me.

Do you mean the way comctl32 uses uxtheme API currently is wrong? How
did you find out it's not using it right way, with proper arguments?
> So if I want to get a perfect GTK3-theming, I have to fix comctl32 too.

[Ivan Akulinchev]

> > One thing depends on another. When I worked on my own UxTheme
> > implementation, I found that comctl32 likes to send 0 instead of
> > properly arguments. It angered me.
>
> Do you mean the way comctl32 uses uxtheme API currently is wrong?
> How did you find out it's not using it right way, with proper
> arguments?

I didn't write it uses UxTheme API wrong. Let's say it doesn't use all
features. Thus I can't unfold to the full.

For example, uxtheme provides a great function named DrawThemeText. My
first implementation used Pango because it's the native text engine
for all GTK- applications. Unfortunately I had to refuse this idea
because only a couple of controls used it. Thus the result was very
ugly. But the problem is not limited to the text layout engine. Even
if you want to draw some text yourself, you should probably get the
right color and the right font from GetThemeColor and GetThemeFont
respectively first. At the worst way ask what GetSysColor thinks. But
sometimes comctl32 believes the plain black color should please
everyone. This is crazy, guys!

Back to the words about using the improper arguments. There is a theme
class named LISTBOX. It defines 4 different parts depends on the
scrollbar position. This parts have ids from 1 to 4. If you look at
the file comctl32/theme_listbox.c you see it always sends the
undocumented value 0.

Take a look at the theme class EDIT. One part exists for the
background (EP_BACKGROUND) and 4 parts were generously provided by
Microsoft for the borders around. Let's open the comctl32/theme_edit.c
source file. Firstly it uses only EP_EDITTEXT (probably created for
the text inside). Secondly it doesn't ask UxTheme to draw the
background. Even if you draw the background as a part of EP_EDITTEXT
(as I did), it will be overlapped. This makes problems for such
themes as Ambiance (the default Ubuntu theme).

There is also a cool theme class named LISTVIEW. It provides a lot of
parts for such things as list items (LVP_LISTITEM) which even support
6 states (normal, hot, selected, etc.) Guess how many parts comctl32
uses? Right, only one (the undocumented 0 again). Although a lot of
GTK themes like to use gradients for list items. Even the Windows Aero
theme does it. Therefore I don't believe Windows does it in the same
way (just according to the things I see on the screen).

P.S. I noticed there was a typo in my previous mails. Of course I
wanted to write "flickering" instead of "flipping" saying about the
double buffering advantages. It looks like you understood me right,
just to be sure.

[Ivan Akulinchev]

I wrote a brief roadmap:

1. Improve uxtheme handles. Currently they are just void pointers to
   the internal structures. All other libraries do it using a handle
   table [1, 2, 3].
2. Move all MSSTYLES-related code to winemsstyles.drv. At this step
   such uxtheme functions as DrawThemeBackground will be stubbed.
3. Add support for uxtheme drivers. At the startup the registry key
   HKCU\Software\Wine\Drivers\Theme will be read. This is a comma-
   separated list such as "gtk3,qt5,mac,msstyles". In the loop all
   drivers will be tried until the working one found. Note the
   suggested order. If winegtk3.drv see the DESKTOP_SESSION
   environment variable is set to KDE, it should return FALSE from the
   entry point, so wineqt5.drv will be tried. This is a bug founded by
   Ruslan Kabatsayev last year [4]. If nothing found, the last one
   (winemsstyles.drv) should be used.
4. Work on the activation context. This is a complex step I need to
   describe separately...
5. Implement Buffered Paint API [5].
6. Add double buffering support to comctl32 (I hate flipping!!!)
7. Add support for animated transitions like Windows Vista does.
8. Fix other problems in comctl32 that I hate...
9. Move the existing code from uxthemegtk [6] to winegtk3.drv.
10. Improve winegt3.drv until the deadline ;-)

[1] https://github.com/wine-mirror/wine/blob/master/dlls/gdi32/gdiobj.c
[2] https://github.com/wine-mirror/wine/blob/master/dlls/winhttp/handle.c
[3] https://github.com/wine-mirror/wine/blob/master/server/handle.c
[4] https://www.winehq.org/pipermail/wine-devel/2015-July/108232.html
[5]
https://msdn.microsoft.com/en-us/library/windows/desktop/bb773257%28v=vs.85%...
[6] https://github.com/akulinchev/uxthemegtk

[Nikolay Sivov]

On 26.03.2016 22:34, Ivan Akulinchev wrote:
> I wrote a brief roadmap:
> - Improve uxtheme handles. Currently they are just void pointers to
> the internal structures. All other libraries do it using a handle
> table [1, 2, 3].

Right.
> - Move all MSSTYLES-related code to winemsstyles.drv. At this step
> such uxtheme functions as DrawThemeBackground will be stubbed.

I don't think this step is needed, MSSTYLES stuff could stay in uxtheme,
acting similar to null driver from user32.
> - Add support for uxtheme drivers. At the startup the registry key
> HKCU\Software\Wine\Drivers\Theme will be read. This is a comma-
> separated list such as "gtk3,qt5,mac,msstyles". In the loop all
> drivers will be tried until the working one found. Note the
> suggested order. If winegtk3.drv see the DESKTOP_SESSION
> environment variable is set to KDE, it should return FALSE from the
> entry point, so wineqt5.drv will be tried. This is a bug founded by
> Ruslan Kabatsayev last year [4]. If nothing found, the last one
> (winemsstyles.drv) should be used.

Just curious, did you explore the ways to implement qt5 variant (let
alone mac)?
> - Work on the activation context. This is a complex step I need to
> describe separately...

Class redirection context support is already there, user32 does not
honor it, that's the problem.
> - Add double buffering support to comctl32 (I hate flipping!!!)

Some controls have double buffering mode, when working without theme.
You mean here only the case when theme is active?
> - Add support for animated transitions like Windows Vista does.

What is affected by this exactly?
> - Fix other problems in comctl32 that I hate...

Sure, but could you give a draft list for that?

[Ivan Akulinchev]

> > - Move all MSSTYLES-related code to winemsstyles.drv. At this step
> > such uxtheme functions as DrawThemeBackground will be stubbed.
>
> I don't think this step is needed, MSSTYLES stuff could stay in
> uxtheme, acting similar to null driver from user32.

Of course I thought about it, but for a long time ago. Then it was
better to keep all MSSTYLES-related stub separately.

Now I see some reasons to keep it inside. You're right, thanks.
> Just curious, did you explore the ways to implement qt5 variant (let
> alone mac)?

I didn't plan to implement this in the context of GSoC, but yes. If
you mean something like MOC (Qt preprocessor), it's not necessary
until you want to inherit some QObject class. It looks a little bit
tricky, but it's the documented way. The only thing you need is a
modern C++ compiler and Qt headers installed on the build system.

The mac driver has no unsolvable problems too.
> Class redirection context support is already there, user32 does not
> honor it, that's the problem.

Sorry, can't find it. Could you please provide a link?
> > - Add double buffering support to comctl32 (I hate flipping!!!)
>
> Some controls have double buffering mode, when working without
> theme. You mean here only the case when theme is active?

I don't know which case I mean, but such complex controls as toolbars
flip on the window resize.
> > - Add support for animated transitions like Windows Vista does.
>
> What is affected by this exactly?

Sorry, didn't understand the question. If mean how I'm going to do it:

1. Implement BeginBufferedAnimation and EndBufferedAnimation.
2. Call GetThemeTransitionDuration when the state changes.
3. Use BeginBufferedAnimation and EndBufferedAnimation, see the
   example from MSDN. Even if the transition duration is set to 0, you
   get double buffering for free.
> > - Fix other problems in comctl32 that I hate...
>
> Sure, but could you give a draft list for that?

I'll write you later (you already asked me in another mail above).

[Nikolay Sivov]

On 27.03.2016 14:17, Ivan Akulinchev wrote:
> > Class redirection context support is already there, user32 does not
> > honor it, that's the problem.
>
> Sorry, can't find it. Could you please provide a link?

I mean window class manifest data is already parsed in ntdll/actctx.c
and FindActCtxSectionStringW() already returns versioned class names.
> > > - Add double buffering support to comctl32 (I hate flipping!!!)
> >
> > Some controls have double buffering mode, when working without
> > theme. You mean here only the case when theme is active?
>
> I don't know which case I mean, but such complex controls as toolbars
> flip on the window resize.

For toolbar in particular double buffering is supposed to be enabled
with TBSTYLE_EX_DOUBLEBUFFER style, so it's probably up to application
to activate it (could be that active theme always triggers double
buffering too).
> > > - Add support for animated transitions like Windows Vista does.
> >
> > What is affected by this exactly?
>
> Sorry, didn't understand the question. If mean how I'm going to do it:
> - Implement BeginBufferedAnimation and EndBufferedAnimation.
> - Call GetThemeTransitionDuration when the state changes.
> - Use BeginBufferedAnimation and EndBufferedAnimation, see the
> example from MSDN. Even if the transition duration is set to 0, you
> get double buffering for free.

I mean where in user controls such transition effects are supposed to be
used?

[Ivan Akulinchev]

> I mean window class manifest data is already parsed in
> ntdll/actctx.c and FindActCtxSectionStringW() already returns
> versioned class names.

Good news. I have less work to do.
> I mean where in user controls such transition effects are supposed
> to be used?

Take a look at the default button in Vista and 7. It changes here and
there between PBS_DEFAULTED and PBS_DEFAULTED_ANIMATING (the last one
not described in MSDN, sorry). If you hover the mouse, the state will
be changed smoothly as well. So the push button is the candidate
number one. But other controls have animations too, perhaps you didn't
recognize it due to a very small transition time.

Speaking about GTK, animated widgets can await you everywhere. For
example, in Adwaita (the default theme from GNOME3) tabs have the same
behavior as buttons in Windows Vista. For this reason all controls
should support animated transitions.

[Ruslan Kabatsayev]

I'd like to point out that DESKTOP_SESSION=KDE isn't a robust way to
detect oxygen-gtk. I use it in XFCE, for example, too. If not checking
the theme name, it'd be better to refrain from refusing to use gtk3 on
KDE, as the user may have set up a simpler to emulate GTK theme.

On Sat, Mar 26, 2016 at 10:34 PM, Ivan Akulinchev
 wrote:
> I wrote a brief roadmap:
> - Improve uxtheme handles. Currently they are just void pointers to
> the internal structures. All other libraries do it using a handle
> table [1, 2, 3].
> - Move all MSSTYLES-related code to winemsstyles.drv. At this step
> such uxtheme functions as DrawThemeBackground will be stubbed.
> - Add support for uxtheme drivers. At the startup the registry key
> HKCU\Software\Wine\Drivers\Theme will be read. This is a comma-
> separated list such as "gtk3,qt5,mac,msstyles". In the loop all
> drivers will be tried until the working one found. Note the
> suggested order. If winegtk3.drv see the DESKTOP_SESSION
> environment variable is set to KDE, it should return FALSE from the
> entry point, so wineqt5.drv will be tried. This is a bug founded by
> Ruslan Kabatsayev last year [4]. If nothing found, the last one
> (winemsstyles.drv) should be used.
> - Work on the activation context. This is a complex step I need to
> describe separately...
> - Implement Buffered Paint API [5].
> - Add double buffering support to comctl32 (I hate flipping!!!)
> - Add support for animated transitions like Windows Vista does.
> - Fix other problems in comctl32 that I hate...
> - Move the existing code from uxthemegtk [6] to winegtk3.drv.
> - Improve winegt3.drv until the deadline ;-)
>
> [1] https://github.com/wine-mirror/wine/blob/master/dlls/gdi32/gdiobj.c
> [2] https://github.com/wine-mirror/wine/blob/master/dlls/winhttp/handle.c
> [3] https://github.com/wine-mirror/wine/blob/master/server/handle.c
> [4] https://www.winehq.org/pipermail/wine-devel/2015-July/108232.html
> [5]
> https://msdn.microsoft.com/en-us/library/windows/desktop/bb773257%28v=vs.85%...
> [6] https://github.com/akulinchev/uxthemegtk