correct comctl32 implementation
I have been researching how i could implement the gsoc Theming - Implement Wine theming support. Though I'm a bit confused what is wanted. So is the case that completely separate dll's should be written for different versions and be loaded by side-by-side assembly. So you would end up with "comctl32v5.dll","comctl32v6.dll","comctl32v7.dll"? Would these be 3 different code basses or should they be made to share most of there code?
From what I understand uxtheme already loads XP theme files. So would all the work be isolated to creating different versions of comdlg32 and comctl32?
Also does wine support side by side assembly? I did a very quick google search and i didn't see anything. I hope I'm not asking too much at once and/or too silly questions.
On 3/11/2011 06:22, Andrew Green wrote:
I have been researching how i could implement the gsoc Theming - Implement Wine theming support. Though I'm a bit confused what is wanted. So is the case that completely separate dll's should be written for different versions and be loaded by side-by-side assembly. So you would end up with "comctl32v5.dll","comctl32v6.dll","comctl32v7.dll"? Would these be 3 different code basses or should they be made to share most of there code? Multiple comctl32 should be the last thing to think about, only if there's absolutely no way to implement everything needed in one comctl32.
From what I understand uxtheme already loads XP theme files. So would all the work be isolated to creating different versions of comdlg32 and comctl32? No sure what you mean. uxtheme purpose is to load theme data, draw theme primitives and retrieve theme components data.
Client dll such as comctl32 should only use that public api when drawing controls, that's all. Also comdlg32 was never a question, cause it doesn't provide new controls.
Also does wine support side by side assembly? I did a very quick google search and i didn't see anything. Yes wine does support installation and loading of SxS assemblies, and by assembly I mean native dlls installed in SxS directory and referenced with embedded or external manifest file. Loader supports manifest files, not fully but simple things should work. I hope I'm not asking too much at once and/or too silly questions. No, it's not silly to ask at all. But one of the most important things to be done for that is to implement support of window class redirection. In version 6 all user32 controls are reimplemented with theme support in comctl32, while user32 classes are kept of course. This is done with specific entries in comctl32 manifest, on load comctl32 all builtin classes are re-registered to the ones from comctl32. I definitely want to see some solution for that, having themed comctl32 controls while scrollbars and buttons are drawn with default appearance makes theme support kind of useless.
Thank you for the quick reply. so is it the case is that multiple dll's versions will be generated to be used by SxS(as WinSxS contains multiple comctl32.dll)? I know uxtheme draws primitives. What I meant to ask was will any work have to be done in uxtheme(apart from maybe the occasional bug fix, not a new implementation of it or anything like that)? The last point about window class redirection I'm a bit confused about. I really don't know anything about it. This patch exists so it sounds like it is supported. http://osdir.com/ml/wine-patches/2009-12/msg00871.html So would it just be that case that comctl32(version 6) re-registers the controls that are normally in user32? If anyone could provide me with any information or reading material. I would be very thankful. On Fri, Mar 11, 2011 at 7:28 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
On 3/11/2011 06:22, Andrew Green wrote:
I have been researching how i could implement the gsoc Theming - Implement Wine theming support. Though I'm a bit confused what is wanted. So is the case that completely separate dll's should be written for different versions and be loaded by side-by-side assembly. So you would end up with "comctl32v5.dll","comctl32v6.dll","comctl32v7.dll"? Would these be 3 different code basses or should they be made to share most of there code?
Multiple comctl32 should be the last thing to think about, only if there's absolutely no way to implement everything needed in one comctl32.
From what I understand uxtheme already loads XP theme files. So would all the work be isolated to creating different versions of comdlg32 and comctl32?
No sure what you mean. uxtheme purpose is to load theme data, draw theme primitives and retrieve theme components data.
Client dll such as comctl32 should only use that public api when drawing controls, that's all. Also comdlg32 was never a question, cause it doesn't provide new controls.
Also does wine support side by side assembly? I did a very quick google search and i didn't see anything.
Yes wine does support installation and loading of SxS assemblies, and by assembly I mean native dlls installed in SxS directory and referenced with embedded or external manifest file. Loader supports manifest files, not fully but simple things should work.
I hope I'm not asking too much at once and/or too silly questions.
No, it's not silly to ask at all. But one of the most important things to be done for that is to implement support of window class redirection. In version 6 all user32 controls are reimplemented with theme support in comctl32, while user32 classes are kept of course. This is done with specific entries in comctl32 manifest, on load comctl32 all builtin classes are re-registered to the ones from comctl32. I definitely want to see some solution for that, having themed comctl32 controls while scrollbars and buttons are drawn with default appearance makes theme support kind of useless.
Am 12.03.2011 07:54, schrieb Andrew Green:
Thank you for the quick reply. so is it the case is that multiple dll's versions will be generated to be used by SxS(as WinSxS contains multiple comctl32.dll)?
I know uxtheme draws primitives. What I meant to ask was will any work have to be done in uxtheme(apart from maybe the occasional bug fix, not a new implementation of it or anything like that)?
No, uxtheme is in a pretty good shape. Most stuff will get into comctl32 and user32. That will enable us to have theming features like: http://www.dritimage.de/uploads/bilder/124897763294_dirty-scrollbar-hack.png http://img.dritimage.de/bilder/124922976611_dirty-captionbar-hack.png But these were only really bad hacks just for a showcase.
The last point about window class redirection I'm a bit confused about. I really don't know anything about it. This patch exists so it sounds like it is supported. http://osdir.com/ml/wine-patches/2009-12/msg00871.html
That patch is not in git, mostly likely for that reason: http://www.mail-archive.com/wine-devel(a)winehq.org/msg59786.html
So would it just be that case that comctl32(version 6) re-registers the controls that are normally in user32?
Yes, there is some comctl32 function (not yet implemented) to trigger that.
If anyone could provide me with any information or reading material. I would be very thankful.
I only can point you on a stupid test i once wrote: http://www.winehq.org/pipermail/wine-patches/2009-September/078825.html I would suggest: read over it and then delete it :) -- Best Regards, André Hentschel
On 3/12/2011 09:54, Andrew Green wrote:
Thank you for the quick reply. so is it the case is that multiple dll's versions will be generated to be used by SxS(as WinSxS contains multiple comctl32.dll)? Again, we don't want to keep multiple versions, so we need a way to work with single one. I know uxtheme draws primitives. What I meant to ask was will any work have to be done in uxtheme(apart from maybe the occasional bug fix, not a new implementation of it or anything like that)? Sure, bugs are possible, especially since uxtheme is not widely used. The last point about window class redirection I'm a bit confused about. I really don't know anything about it. This patch exists so it sounds like it is supported. http://osdir.com/ml/wine-patches/2009-12/msg00871.html So would it just be that case that comctl32(version 6) re-registers the controls that are normally in user32? No, it's not supported. As I said here http://www.mail-archive.com/wine-devel(a)winehq.org/msg59786.html we also need some ntdll improvements for activation contexts to support this stuff better. FindActCtxSectionString() shouldn't be hard to improve but you need to figure out closed data structures format, at least some useful fields (without disassembler, wine test suite only).
If anyone could provide me with any information or reading material. I would be very thankful. I don't think it's documented, I mean loading process itself to replace registered classes. You can't try to search for "<windowClass></windowClass>" entry description for SxS manifests.
As I remember I failed to find any explanation for that, so this needs extensive tests in a first place. Also be sure to test only behaviour without looking inside any MS modules.
On 11.03.2011 10:28, Nikolay Sivov wrote:
In version 6 all user32 controls are reimplemented with theme support in comctl32, while user32 classes are kept of course. This is done with specific entries in comctl32 manifest, on load comctl32 all builtin classes are re-registered to the ones from comctl32. I definitely want to see some solution for that, having themed comctl32 controls while scrollbars and buttons are drawn with default appearance makes theme support kind of useless.
Buttons: technically, I don't think you need SxS class redirection for that. The issue with the current “subclassing” is that, well, the button can't really be subclassed for theming - IIRC some state changes don't trigger a “paint” message but only cause internal painting - this can't be caught lass function and breaks theming. What MS supposedly did was to simply copy'n'paste the controls code into comctl32 and add theming. That would certainly allow properly themed buttons. And SxS class redirection... Scroll bars, are, IIRC, a different beast - window scroll bars are not controls but handled/drawn by DefWndProc. No idea how native themes these. Maybe some mojo to override/hook into DefWndProc? -f.r.
On 3/15/2011 05:25, Frank Richter wrote:
On 11.03.2011 10:28, Nikolay Sivov wrote:
In version 6 all user32 controls are reimplemented with theme support in comctl32, while user32 classes are kept of course. This is done with specific entries in comctl32 manifest, on load comctl32 all builtin classes are re-registered to the ones from comctl32. I definitely want to see some solution for that, having themed comctl32 controls while scrollbars and buttons are drawn with default appearance makes theme support kind of useless. Buttons: technically, I don't think you need SxS class redirection for that. The issue with the current “subclassing” is that, well, the button can't really be subclassed for theming - IIRC some state changes don't trigger a “paint” message but only cause internal painting - this can't be caught lass function and breaks theming. What MS supposedly did was to simply copy'n'paste the controls code into comctl32 and add theming. That would certainly allow properly themed buttons. And SxS class redirection... We need a way to make comctl32 controls available, not always but only when it's requested to use version 6. Native does that with class redirection.
I'm not sure it's ok to use comctl32 always for builtin classes.
Scroll bars, are, IIRC, a different beast - window scroll bars are not controls but handled/drawn by DefWndProc. No idea how native themes these. Maybe some mojo to override/hook into DefWndProc? That's not true. Scrollbar could be a normal control too. I have no idea how themes work with window scrollbars though. -f.r.
I'm not sure how it will only use theming for version 6 without sxs. Will the control have to manually check the manifest? I am a bit familiar with how to use the themes to draw controls and that shouldn't be an issue. At the moment i'm more confused with this window class redirect thing. I've been trying to find someone who knows a bit about it. Without much luck. On Mar 15, 2011 9:19 PM, "Nikolay Sivov" <bunglehead(a)gmail.com> wrote:
On 3/15/2011 05:25, Frank Richter wrote:
On 11.03.2011 10:28, Nikolay Sivov wrote:
In version 6 all user32 controls are reimplemented with theme support in comctl32, while user32 classes are kept of course. This is done with specific entries in comctl32 manifest, on load comctl32 all builtin classes are re-registered to the ones from comctl32. I definitely want to see some solution for that, having themed comctl32 controls while scrollbars and buttons are drawn with default appearance makes theme support kind of useless. Buttons: technically, I don't think you need SxS class redirection for that. The issue with the current “subclassing” is that, well, the button can't really be subclassed for theming - IIRC some state changes don't trigger a “paint” message but only cause internal painting - this can't be caught lass function and breaks theming. What MS supposedly did was to simply copy'n'paste the controls code into comctl32 and add theming. That would certainly allow properly themed buttons. And SxS class redirection... We need a way to make comctl32 controls available, not always but only when it's requested to use version 6. Native does that with class redirection.
I'm not sure it's ok to use comctl32 always for builtin classes.
Scroll bars, are, IIRC, a different beast - window scroll bars are not controls but handled/drawn by DefWndProc. No idea how native themes these. Maybe some mojo to override/hook into DefWndProc? That's not true. Scrollbar could be a normal control too. I have no idea how themes work with window scrollbars though. -f.r.
participants (4)
-
Andrew Green -
André Hentschel -
Frank Richter -
Nikolay Sivov