uxtheme.dll

[Kevin]

I started work porting a windows app using winelib, and hit an issue relating
to the fact that there is currently no implementation of uxtheme.dll (and
more importantly, no headers, of which would be enough to compile the app as
it dynamically loads all the uxtheme dlls as needed, and falls back
gracefully)

Because of this, I've been thinking about beginning an implementation of
uxtheme.dll. I am curious if someone has already taken up this task, or if
anyone any opinions on this topic.

Thanks
Kevin

[Dimitrie O. Paun]

Post by Kevin
Because of this, I've been thinking about beginning an implementation of
uxtheme.dll. I am curious if someone has already taken up this task, or if
anyone any opinions on this topic.

I'm not aware of anyone working on this. This would be a nice contribution
to Wine.

[Sylvain Petreolle]

This isnt a windows system dll. Isnt that another attempt like
cards.dll ?

Post by Kevin

Post by Kevin
Because of this, I've been thinking about beginning an

implementation of

Post by Kevin
uxtheme.dll. I am curious if someone has already taken up this

task, or if

Post by Kevin
anyone any opinions on this topic.

I'm not aware of anyone working on this. This would be a nice
contribution
to Wine.

=====
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
ICQ #170597259
Say NO to software patents
Dites NON aux brevets logiciels

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[Mike Hearn]

Post by Sylvain Petreolle
This isnt a windows system dll. Isnt that another attempt like
cards.dll ?

Sure it is. Apps attempt to LoadLibrary it if they detect it to enhance
their drawing capabilities. It's conceivable that one day apps will not
have this backwards compat code and simply require Windows XP or above,
so it needs to get done.

It's also the Right Way to make Wine not look like ass on our pretty
desktops, because the win32 apps will be theme aware.

[Roderick Colenbrander]

I hope you know what you will begin with. (For the ones that don't know
uxtheme.dll is the dll that takes care of all theming on WinXP and it is the dll
that dlls like comctl32 and all others use for theming)

Some time ago I checked out uxtheme.dll a bit and it seems that it needs
changes all over Wine. As I understand it WinXP ships with two sets of
comctl32.dll and friends. One is the "old" version and one is a new uxtheme aware
version. The uxtheme aware version contains lots of changes and uses uxtheme for
theming. To use uxtheme you need to add uxtheme support to the dlls that need
it which looks like a huge job. Perhaps this is something post Wine-1.0?

Roderick Colenbrander

Post by Kevin
I started work porting a windows app using winelib, and hit an issue relating
to the fact that there is currently no implementation of uxtheme.dll (and
more importantly, no headers, of which would be enough to compile the app as
it dynamically loads all the uxtheme dlls as needed, and falls back
gracefully)
Because of this, I've been thinking about beginning an implementation of
uxtheme.dll. I am curious if someone has already taken up this task, or if
anyone any opinions on this topic.
Thanks
Kevin

[Shachar Shemesh]

Post by Roderick Colenbrander
I hope you know what you will begin with. (For the ones that don't know
uxtheme.dll is the dll that takes care of all theming on WinXP and it is the dll
that dlls like comctl32 and all others use for theming)
Some time ago I checked out uxtheme.dll a bit and it seems that it needs
changes all over Wine. As I understand it WinXP ships with two sets of
comctl32.dll and friends. One is the "old" version and one is a new uxtheme aware
version. The uxtheme aware version contains lots of changes and uses uxtheme for
theming. To use uxtheme you need to add uxtheme support to the dlls that need
it which looks like a huge job.

It does.

Post by Roderick Colenbrander
Perhaps this is something post Wine-1.0?

Why? This seems liks something that can be done incrementally. Kevin is
interested in doing it. Is there any reason to wait? Kevin should be
aware of what he's getting himself into, of course, but otherwise it's
his call. That's what free software development is all about.

Post by Roderick Colenbrander
Roderick Colenbrander

Shachar

[Roderick Colenbrander]

Ofcourse I want uxtheme.dll implemented since it is a very cool new dll but I
think a problem will be that it needs changes in various parts of Wine.
Mainly in the user and common control area. Microsoft releases two sets of
comctl32 dlls. One of them is meant for backwards compatibility. Because of
this I think Wine will need two dlls and it might be needed to maintain two
dlls. :(

Because of all this I said that it might be something for after Wine 1.0. This
dll could later be reused for theming Wine and that atleast was something we
planned to do behind 1.0, right?

Roderick

Post by Shachar Shemesh

Post by Roderick Colenbrander
I hope you know what you will begin with. (For the ones that don't know
uxtheme.dll is the dll that takes care of all theming on WinXP and it is
the dll that dlls like comctl32 and all others use for theming)
Some time ago I checked out uxtheme.dll a bit and it seems that it needs
changes all over Wine. As I understand it WinXP ships with two sets of
comctl32.dll and friends. One is the "old" version and one is a new
uxtheme aware version. The uxtheme aware version contains lots of changes
and uses uxtheme for theming. To use uxtheme you need to add uxtheme
support to the dlls that need it which looks like a huge job.

It does.

Post by Roderick Colenbrander
Perhaps this is something post Wine-1.0?

Why? This seems liks something that can be done incrementally. Kevin is
interested in doing it. Is there any reason to wait? Kevin should be
aware of what he's getting himself into, of course, but otherwise it's
his call. That's what free software development is all about.

Post by Roderick Colenbrander
Roderick Colenbrander

Shachar

[Dimitrie O. Paun]

Post by Roderick Colenbrander
Microsoft releases two sets of
comctl32 dlls. One of them is meant for backwards compatibility.

Do you have any idea why would that be needed?

[Roderick Colenbrander]

The "old" dll that MS ships with WindowsXP is comctl32.dll version 5.x which
is the same as on other Windows versions.

Version 6 is the new version. One of the biggest changes is that this updated
dll handles both the user and common controls. Further all controls now
include some area in which can be drawn for theming.

For more info check out:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/xptheming.asp

Roderick Colenbrander

Post by Dimitrie O. Paun

Post by Roderick Colenbrander
Microsoft releases two sets of
comctl32 dlls. One of them is meant for backwards compatibility.

Do you have any idea why would that be needed?

[Jimmy O'Regan]

Post by Roderick Colenbrander
The "old" dll that MS ships with WindowsXP is comctl32.dll version 5.x which
is the same as on other Windows versions.
Version 6 is the new version. One of the biggest changes is that this updated
dll handles both the user and common controls. Further all controls now
include some area in which can be drawn for theming.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/xptheming.asp
Roderick Colenbrander

Another difference is that the new version comes as an assembly;
multiple versions of the dll can live side by side.

[Kevin Koltzau]

The different versions of comctl32 are part of Microsoft's "assembly" system
which is primarilly an attempt to battle "DLL hell" as well as part of
their .NET strategy, which (correct me if I'm wrong) I don't think afflicts
this part of WINE very much.

Altho one thing to consider in this area is Manifests, which at a minimal case
could be used to simply enable/disable theme support for a particular
application, or could be ignored completely for themes (similar to how
applications like Stardock's WindowBlinds skins every app, regardless of a
Manifest requesting the new comctl32).

Post by Roderick Colenbrander
Ofcourse I want uxtheme.dll implemented since it is a very cool new dll but
I think a problem will be that it needs changes in various parts of Wine.
Mainly in the user and common control area. Microsoft releases two sets of
comctl32 dlls. One of them is meant for backwards compatibility. Because of
this I think Wine will need two dlls and it might be needed to maintain two
dlls. :(
Because of all this I said that it might be something for after Wine 1.0.
This dll could later be reused for theming Wine and that atleast was
something we planned to do behind 1.0, right?
Roderick

[Kevin Koltzau]

I'm aware of the scope of the project. The general design of uxtheme lends
itself well to being done incrementally, eg. controls could be modified as
support for the particular control is implemented, etc.
Also part of the API are a few functions (IsThemeActive & IsAppThemed) which
will allow themes to be disabled in the beginning for theme aware
applications until sufficient support has been built or if themes are
disabled via config/registry.

First order of business tho is the headers

Post by Roderick Colenbrander
I hope you know what you will begin with. (For the ones that don't know
uxtheme.dll is the dll that takes care of all theming on WinXP and it is
the dll that dlls like comctl32 and all others use for theming)
Some time ago I checked out uxtheme.dll a bit and it seems that it needs
changes all over Wine. As I understand it WinXP ships with two sets of
comctl32.dll and friends. One is the "old" version and one is a new uxtheme
aware version. The uxtheme aware version contains lots of changes and uses
uxtheme for theming. To use uxtheme you need to add uxtheme support to the
dlls that need it which looks like a huge job. Perhaps this is something
post Wine-1.0?
Roderick Colenbrander

[James Gregory]

Post by Kevin Koltzau
I'm aware of the scope of the project. The general design of uxtheme lends
itself well to being done incrementally, eg. controls could be modified as
support for the particular control is implemented, etc.
Also part of the API are a few functions (IsThemeActive & IsAppThemed) which
will allow themes to be disabled in the beginning for theme aware
applications until sufficient support has been built or if themes are
disabled via config/registry.

Some time ago I started hacking in support for GTK themes. When I first
suggested this project to the list there was suggestions that doing it
with uxtheme.dll was the way to go. I agreed, but didn't have winxp to
play with, so I kept tinkering on this project with the intent of
learning a bit more about how wine works (which meant learning a lot
about how GDI and X works, though I didn't realise that I'd need to know
that stuff when I started on the project). I actually managed to get
some results which were starting to look promising (though there's no
way I'd submit that code as a patch). Screenshots here (the checkbox
being the only important part):

Loading Image...
Loading Image...
Loading Image...

Anyway, the reason I'm posting is not to suggest that this code be used
(nor the approach I took), but to mention that if theming code is to be
written that I think it's really important to have a way to pass off
rendering of controls etc to a .so that can be dlopened and called with
dlsym. IIRC the existing system uses a function lookup table, so there
shouldn't be much that needs to change for this to occur -- only the
initialisation of this function table and probably some hooks so that
these .sos can detect whether or not they'll work with the current
configuration (as an example the way I was doing gtk theming won't work
with anything that isn't x11drv. I don't like breaking encapsulation
like this, but it sounds like it's practical in this case). I don't know
if I can be of any help, but I'm interested in trying -- please keep me
posted.

James.

Post by Kevin Koltzau

Post by Roderick Colenbrander
I hope you know what you will begin with. (For the ones that don't know
uxtheme.dll is the dll that takes care of all theming on WinXP and it is
the dll that dlls like comctl32 and all others use for theming)
Some time ago I checked out uxtheme.dll a bit and it seems that it needs
changes all over Wine. As I understand it WinXP ships with two sets of
comctl32.dll and friends. One is the "old" version and one is a new uxtheme
aware version. The uxtheme aware version contains lots of changes and uses
uxtheme for theming. To use uxtheme you need to add uxtheme support to the
dlls that need it which looks like a huge job. Perhaps this is something
post Wine-1.0?
Roderick Colenbrander

[Kevin Koltzau]

I'm currently working on implementing support for .msstyles themes (of which
are used by XP) primarily because the format follows the API pretty closely
and will be easier to test my implementation against an XP box.

One nice thing about .msstyles themes is they are basically just a
resource-only DLL, which could of course include exported functions.

Going along that path, one possible way to integrate theme support from your
native window manager is to extend the .msstyles theme format to enable using
exported functions for drawing some controls, which could then make direct
GTK/etc calls.

Another possible method would be to create a conversion tool to create
an .msstyles theme from a GTK theme, or to simply create a totally new method
of defining themes for WINE.

Post by James Gregory
Some time ago I started hacking in support for GTK themes. When I first
suggested this project to the list there was suggestions that doing it
with uxtheme.dll was the way to go. I agreed, but didn't have winxp to
play with, so I kept tinkering on this project with the intent of
learning a bit more about how wine works (which meant learning a lot
about how GDI and X works, though I didn't realise that I'd need to know
that stuff when I started on the project). I actually managed to get
some results which were starting to look promising (though there's no
way I'd submit that code as a patch). Screenshots here (the checkbox
http://james.id.au/wine/wine-ss1.png
http://james.id.au/wine/wine-ss2.png
http://james.id.au/wine/wine-ss3.png
Anyway, the reason I'm posting is not to suggest that this code be used
(nor the approach I took), but to mention that if theming code is to be
written that I think it's really important to have a way to pass off
rendering of controls etc to a .so that can be dlopened and called with
dlsym. IIRC the existing system uses a function lookup table, so there
shouldn't be much that needs to change for this to occur -- only the
initialisation of this function table and probably some hooks so that
these .sos can detect whether or not they'll work with the current
configuration (as an example the way I was doing gtk theming won't work
with anything that isn't x11drv. I don't like breaking encapsulation
like this, but it sounds like it's practical in this case). I don't know
if I can be of any help, but I'm interested in trying -- please keep me
posted.
James.

[Mike Jackson]

I would be glad to be of any assistance I can be in this matter. I think
wine is a great project, and I have been looking for the right project to
immerse my self in. I think I've just found it :-)

Mike Jackson

-----Original Message-----
From: wine-devel-***@winehq.org [mailto:wine-devel-***@winehq.org] On
Behalf Of Shachar Shemesh
Sent: Tuesday, 30 September 2003 6:26 PM
To: Roderick Colenbrander
Cc: Kevin; wine-***@winehq.com
Subject: Re: uxtheme.dll

Post by Roderick Colenbrander
I hope you know what you will begin with. (For the ones that don't know
uxtheme.dll is the dll that takes care of all theming on WinXP and it
is the dll that dlls like comctl32 and all others use for theming)
Some time ago I checked out uxtheme.dll a bit and it seems that it
needs changes all over Wine. As I understand it WinXP ships with two
sets of comctl32.dll and friends. One is the "old" version and one is a
new uxtheme aware version. The uxtheme aware version contains lots of
changes and uses uxtheme for theming. To use uxtheme you need to add
uxtheme support to the dlls that need it which looks like a huge job.

It does.

Post by Roderick Colenbrander
Perhaps this is something post Wine-1.0?

Why? This seems liks something that can be done incrementally. Kevin is
interested in doing it. Is there any reason to wait? Kevin should be aware
of what he's getting himself into, of course, but otherwise it's his call.
That's what free software development is all about.

Post by Roderick Colenbrander
Roderick Colenbrander

Shachar

--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/

[Steven Edwards]

This is very kickass dude. I think this is the right method of
supporting themes for WINE. KDE can already do GTK themes with a little
bit of tweaking so it will support both Linux Desktops and GTK themes
are now supported under Windows with GTK-Win32 so maybe we can even use
this in ReactOS when its ready.

Thanks
Steven

Post by James Gregory
Some time ago I started hacking in support for GTK themes. When I
first
suggested this project to the list there was suggestions that doing
it
with uxtheme.dll was the way to go. I agreed, but didn't have winxp
to
play with, so I kept tinkering on this project with the intent of
learning a bit more about how wine works (which meant learning a lot
about how GDI and X works, though I didn't realise that I'd need to
know
that stuff when I started on the project). I actually managed to get
some results which were starting to look promising (though there's no
way I'd submit that code as a patch). Screenshots here (the checkbox
http://james.id.au/wine/wine-ss1.png
http://james.id.au/wine/wine-ss2.png
http://james.id.au/wine/wine-ss3.png
Anyway, the reason I'm posting is not to suggest that this code be
used
(nor the approach I took), but to mention that if theming code is to
be
written that I think it's really important to have a way to pass off
rendering of controls etc to a .so that can be dlopened and called
with
dlsym. IIRC the existing system uses a function lookup table, so
there
shouldn't be much that needs to change for this to occur -- only the
initialisation of this function table and probably some hooks so that
these .sos can detect whether or not they'll work with the current
configuration (as an example the way I was doing gtk theming won't
work
with anything that isn't x11drv. I don't like breaking encapsulation
like this, but it sounds like it's practical in this case). I don't
know
if I can be of any help, but I'm interested in trying -- please keep
me
posted.
James.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

[Gregory M. Turner]

Post by Steven Edwards
This is very kickass dude.

I concur. I've been fantasizing about looking into this stuff myself,
although so far I've always decided I had more pressing matters to look into.
But some of this stuff is just so cool... and frankly, wine has a case of the
uglies that could use fixing. A little razzle and dazzle can go a long way
towards raising the profile of a project.

Anyone who's ever subscribed to the goodies-pipeline from StarDock knows --
this stuff has the potential to be very, very pretty. In fact, in my
opinion, it made my Windows even prettier than my Linux (although the
performance can be pretty awful). And KDE/gnome themes obviously could do
something that was never really possible for wine before.

So... good luck, I am sure this will be quite difficult, but it's a great
idea, in my opinion.

[Ivan Leo Murray-Smith]

Post by Kevin Koltzau
Going along that path, one possible way to integrate theme support from your
native window manager is to extend the .msstyles theme format to enable using
exported functions for drawing some controls, which could then make direct
GTK/etc calls.

I don't think Alexandre will like the idea of wine having new dependencies, like
GTK.

[Vincent Béron]

Post by Ivan Leo Murray-Smith

Post by Kevin Koltzau
Going along that path, one possible way to integrate theme support from your
native window manager is to extend the .msstyles theme format to enable using
exported functions for drawing some controls, which could then make direct
GTK/etc calls.

I don't think Alexandre will like the idea of wine having new dependencies, like
GTK.

Used for themes, I don't see any problem with it. It's something easily
compiled out by a configure check, and since I think I understood
there'd be a couple backends (GTK, QT, no visual change), it wouldn't
matter much for the core Wine. Packagers will have to look after it,
same thing as proper OpenGL headers, ICU, etc. at the time of
compilation.

I don't think it'll be a problem for Alexandre, uunless there's
something about the code quality (same as every other
system/dll/function in Wine).

Vincent

[Kevin Koltzau]

Post by Ivan Leo Murray-Smith

Post by Kevin Koltzau
Going along that path, one possible way to integrate theme support from
your native window manager is to extend the .msstyles theme format to
enable using exported functions for drawing some controls, which could
then make direct GTK/etc calls.

I don't think Alexandre will like the idea of wine having new dependencies,
like GTK.

I tend to agree, I was simply pointing out some possible options (I am not,
nor plan to, use GTK or any other theming system other then .msstyles from
WinXP at present). Although they would really be dependencies in the same
sense as ARTS or OSS are dependencies. In the GTK case, themes using GTK
would simply not be compiled nor useable if GTK was not available.