28 May
2006
28 May
'06
3:44 a.m.
This is similar to what MS did in XP. They made the
GDI depend on another DLL
for all interface drawing. IIRC, this interface isn't detailed anywhere on
MS's site, but the last time I looked was late 2001 so that could have
changed.
In simple terms, what uxtheme and the theme APIs do is as follows:
For non-client area themeing (i.e. window borders and the other stuff thats
applied to all windows), there is an undocumented API in user32
(RegisterUserAPIHooks) which is used by uxtheme to hook certain user32 APIs
to do the non client area drawing etc.
Client area drawing is done via a manifest that selected comctl32 version
6.0 which basicly replaces the system classes for things like buttons, list
boxes and so on with new versions that are properly themed.
There is also a Themes service, how that fits into it I dont know.
For ReactOS, the key things we need are:
1.A unxtheme.dll that implements all the same published APIs microsofts
does (ideally including support for .msstyles files)
2.Proper support for SxS, activation contexts, manifests and such to
correctly load the right dlls for client-area themeing.
3.Some kind of implementation of themed controls that works the same way as
microsofts (which means we need a comctl32.dll that overrides the standard
controls with themed versions)
and 4.Some way to do non-client area themeing.
One option is to do what MS did and have our uxtheme call an API exposed
from user32 to allow it to override certain user32 APIs.
The other option is to simply have user32 always read the theme data and
always draw some kind of "themed" non-client area (even if the "theme"
is
just the default windows look)
Which option is right for ReactOS I dont know.