[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Theming widgets
From:       Kevin Koltzau <kevin () plop ! org>
Date:       2004-02-25 14:04:18
Message-ID: 200402250904.19205.kevin () plop ! org
[Download RAW message or body]

On Wednesday 25 February 2004 06:28 am, Mike Hearn wrote:
> 4) Theme all widgets with a hard link to uxtheme but have a "Win98 look"
> theme which replicates the current drawing?

This actually would end up happening in all cases, if theming is disabled the widget \
is responsible for drawing itself, if theming is enabled then uxtheme handles it..so \
basically the current drawing system will be kept in place and an extra path added \
for the themed case

> Well, to be strictly like Windows then I guess we could actually build
> comctl32 twice with #ifdefs etc for the theming code.

Unfortunately in order to make that work properly, we would need to implement quite a \
bit of the Side-by-side Assembly system and the Activation Context API...
Tho it may be possible to do with a hack to just handle loading the alternate comctl \
when there is a manifest indicating that

> > Going with that, I think #3 might be the best option, and extend
> > InitCommonControls to subclass the standard controls if theming is
> > enabled
> 
> That sounds rather complicated and like it might introduce further bugs
> when apps don't expect controls to be already subclassed...

I don't think subclassing a standard control as the class level would be detectable \
to applications.. this is, AFAIK, how Stardoc Windowblinds works


[prev in list] [next in list] [prev in thread] [next in thread]