gsoc theming

[Nikolay Sivov]

On 4/4/2011 16:45, Reece Dunn wrote:
> On 4 April 2011 13:08, Andrew Green<greeniekin at gmail.com>  wrote:
>> Hi,
>> I hate to message you on this email. I have messaged the mailing
>> lists. Though I became more confused than anything.
> Can you please keep the discussions on the mailing list? Thanks.
>
>> I would like to propose a project where comctl32 is implement
>> correctly in windows for google summer of code.
>> As far as i know windows uses SxS to load version 6 of comctl allowing
>> theming.
> This is correct -- an application needs to add a manifest file to tell
> it to load version 6 of the comctl32 DLL in order to get theming
> support on Windows.
>
>> It also uses windows class redirection to hijack controls
>> from user32 to be themed(I don't know if it somehow uses subclassing).
> This is how it is implemented in wine.
Native doesn't subclass, it has its own copy of so called builtin 
controls in comctl32.
First evidence for that is a special class registration call from 
comctl32 v6 to register themed classes.
Second evidence is that new Button functionality for example is 
available only in comctl32 v6, not in latest user32 module,
I doubt they customize existing behaviour, I think it's more likely some 
message handlers are reused (compiled in both modules) and some are 
present in comctl32 only.



>> The confusing thing on the mailing list i was told not to make a
>> separate version of comctl32. Which is understandable from a code
>> maintenance point of view. Though contradicts what the gsoc ideas page
>> says
>>   "control is overridden by a themed drawing version by subclassing.
>> This is not the way it is implemented on Windows and this causes
>> drawing issues and other nasty issues."
>> As someone who is to be a mentor of this section. What is the goal?
>> and if subclassing is the option, how is this meant to work?
> There isn't a contradition.
>
> AFAICS, the subclassing works -- the subclassed window procedure gets
> called correctly.
>
> The drawing issues can be seen clearly on the button controls -- if
> the button changes state (enabled<->  disabled, pressed, etc.) then it
> gets drawn without theming. This is because the button control in Wine
> does not call WM_PAINT to do the drawing, which the themed button
> overrides.
Subclass may work fine of course, but could cause problems. For example 
it's possible that application clears
all subclass slots (if we're talking about comctl32 mechanism with 
procedure stack). When you create button with v6 on windows you don't 
get sublcassed control (stack is empty), that may be important.

Anyway if you subclass let's say a Button you need to override lot of 
handlers potentially, cause for example new window styles could be 
rejected by modern user32 but accepted in comctl32 logic. That could 
cause a mess when different code works with not necessary valid control 
data. This needs some testing.

Another question is to determine if we need to use controls from 
comctl32 in a first place. If you have active theme it doesn't mean that 
developer wanted to use it if he doesn't specify manifest to load version 6.

So to summarize, the way I see this to be properly done step by step:

1) add class redirect detection for activation context code 
(ntdll/kernel32). Returned structures are undocumented, but if you dump 
data you'll see something (I did);
2) (hard part, for me at least) figure out when to invoke class 
registration call from comctl32 to move registration to comctl32.
3) add tests for user32 to see how builtin classes respond to new 
version 6 styles/messages;
4) figure out what code could be reused between user32 and comctl32 and 
reuse as much handlers from user32 as possible. This will need some 
build tweaks probably, I'm not sure, to share files between dlls.

What also bothers me is that I'm not sure comctl32 versions of controls 
(in windows) use A/W magic for procedures that user32 uses.
> Therefore, you will need to either:
>    1/  convince Alexandre through tests that these tests do call
> WM_PAINT [*] and update the non-themed control accordingly; or
>    2/  implement the state tracking/logic in the themed button and have
> it call WM_PAINT [*].
>
> [*] or the correct custom drawing messages.
>
> HTH,
> - Reece
>
>
>