--- Roderick Colenbrander thunderbird2k@gmx.net wrote:
The colors of your gnome/kde desktop don't map that nicely to windows colors. Because of this the end-result won't allways be very nice. In the future we might want something like this. The best way to add something like this is to finish our uxtheme dll and add support for theming to all controls. Then WineLook=win95 (or winxp) will give you the "classic" colors and lets say "uxtheme" will give everything the look and feel of lets say gtk/qt. (this is how windows xp does its theming too)
Roderick
Please reply below the original post.
Yeah, agreed. Your idea is good, and we just have to wait for uxtheme.dll to finish. But in the meantime is it ok for us to change the default colors? Because the Win95 colors are just too... dull. And my "gradient colors for caption bar" patch will make WINE's windows look nice if Win2K/XP colors are applied... _IF_ my gradient-colors-patch will ever get accepted, because until now it's not been applied yet... (but that's for another thread :-P)
__________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
I'm sorry, this was supposed to be sent on 03/11/2004... (the patch was resent on 11/03, but I sent this to my own address instead of winehq.org) So should I resend the patch again?
And also, for the core devel folks, what do you think about this default color change?
Message follows:
No one has other opinions? I still think it's better to use the WinXP (classic) colors as the default, until we finish the uxtheme dll (and add other themes), because it simply looks better (for me, but I believe others also find the new colors more soft to the eye, and comfortable to look at).
I'm resending the patch.
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
Hi,
Now that I have thought about it a while longer perhaps it is the right idea to already start using uxtheme. If I remember correctly uxtheme is already usable the only problem is that we don't use it to actually modify the look of wine widgets. Kevin Koltzau, the original uxtheme author, made the dll able to parse original windows xp themes and further he used it to theme his own app with it (atleast the color part). It might be a good idea to stick to the old wine colors and add a winelook uxtheme option. When the option is enabled we use uxtheme to parse a theme file and it will then adjust the colors. The theme file will be then of the same type as the files used on windows, so you could even use windows themes. After this a gtk/qt backend could be added to uxtheme.
This is just an idea that came up,
Roderick
I'm sorry, this was supposed to be sent on 03/11/2004... (the patch was resent on 11/03, but I sent this to my own address instead of winehq.org) So should I resend the patch again?
And also, for the core devel folks, what do you think about this default color change?
Message follows:
No one has other opinions? I still think it's better to use the WinXP (classic) colors as the default, until we finish the uxtheme dll (and add other themes), because it simply looks better (for me, but I believe others also find the new colors more soft to the eye, and comfortable to look at).
I'm resending the patch.
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
Hi,
On Fri, Nov 05, 2004 at 08:29:56AM -0800, William Poetra Yoga H wrote:
No one has other opinions? I still think it's better to use the WinXP (classic) colors as the default, until we finish the uxtheme dll (and add other themes), because it simply looks better (for me, but I believe others also find the new colors more soft to the eye, and comfortable to look at).
I'm resending the patch.
I also like the new colors more (the "older" W2K design, NOT the horrible Luna one!).
Andreas Mohr
No one has other opinions? I still think it's better to use the WinXP (classic) colors as the default, until we finish the uxtheme dll (and add other themes), because it simply looks better (for me, but I believe others also find the new colors more soft to the eye, and comfortable to look at).
I like it ;-)
Stefan Dösinger
--- Roderick Colenbrander thunderbird2k@gmx.net wrote:
Hi,
Now that I have thought about it a while longer perhaps it is the right idea to already start using uxtheme. If I remember correctly uxtheme is already usable the only problem is that we don't use it to actually modify the look of wine widgets. Kevin Koltzau, the original uxtheme author, made the dll able to parse original windows xp themes and further he used it to theme his own app with it (atleast the color part). It might be a good idea to stick to the old wine colors and add a winelook uxtheme option. When the option is enabled we use uxtheme to parse a theme file and it will then adjust the colors. The theme file will be then of the same type as the files used on windows, so you could even use windows themes. After this a gtk/qt backend could be added to uxtheme.
This is just an idea that came up,
Roderick
--- Andreas Mohr andi@rhlx01.fht-esslingen.de wrote:
Hi,
I also like the new colors more (the "older" W2K design, NOT the horrible Luna one!).
Andreas Mohr
--- Stefan D�singer stefandoesinger@gmx.at wrote:
I like it ;-)
Stefan D�singer
Roderick: Please reply below the original post, not above it (everyone else does it, so not doing it could cause some confusion IMO)
Yeah, I personally like the Classic Theme colors too... :)
I think Roderick's suggestion is good. I'll take a look at uxtheme, and if it's usable I think we should use it; if not I think it's better to change the default colors for now (no addition of code, just change of some constants), and then when uxtheme is ready, we can add more themes. What do you (all) think?
Why I really like the WinXP Classic colors to be implemented: 1. It's nice, soft to the eye (I said this before) 2. It makes gradient caption bars look nice (when I finish the work on gradient caption bars, that is) 3. It has a positive mental effect (see reason #1) 4. It encourages hacking on WINE (see reason #1, #3) 5. It's not difficult to implement 6. It doesn't break compatibility with apps, and provides above-stated advantages
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
Well, as I said before, I would take a look at uxtheme. Now that I have seen it, I think I haven't really understood how it works (even after reading a bit of MSDN).
How does it work, actually? And how to use it? Can anyone give me a simple explanation? Please look at me as a newbie (I think MSDN assumes that its readers are at least experienced :P).
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
Hi,
Some time ago I looked into uxtheme a bit and it roughly works like this. The dll itself is responsible for loading theme files. After a theme is loaded it can for example be used to load a bitmap and draw as for example the background of a window or it can change the color of controls.
Uxtheme can be used in two ways. Useally all theming is done by windows itself. To do the theming microsoft ships a new version of the user and common dialog dlls which use uxtheme to do the theming. In the other case you can call uxtheme yourself and then you can decide yourself what you want to theme.
Not sure if I said it all correctly. Likely Kevin Koltzau knows it a bit better as he is working on uxtheme. Not sure what the current status of the dll is but atleast our controls aren't using it for theming yet.
Roderick
Well, as I said before, I would take a look at uxtheme. Now that I have seen it, I think I haven't really understood how it works (even after reading a bit of MSDN).
How does it work, actually? And how to use it? Can anyone give me a simple explanation? Please look at me as a newbie (I think MSDN assumes that its readers are at least experienced :P).
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
--- Roderick Colenbrander thunderbird2k@gmx.net wrote:
Hi,
Some time ago I looked into uxtheme a bit and it roughly works like this. The dll itself is responsible for loading theme files. After a theme is loaded it can for example be used to load a bitmap and draw as for example the background of a window or it can change the color of controls.
Uxtheme can be used in two ways. Useally all theming is done by windows itself. To do the theming microsoft ships a new version of the user and common dialog dlls which use uxtheme to do the theming. In the other case you can call uxtheme yourself and then you can decide yourself what you want to theme.
Not sure if I said it all correctly. Likely Kevin Koltzau knows it a bit better as he is working on uxtheme. Not sure what the current status of the dll is but atleast our controls aren't using it for theming yet.
Roderick
So, does the app know that it's being themed? What I mean is, for example an app is written for Win 95. In the (unlikely case, so let's change it to Win ME) event that it is compatible with Win XP, will it be skinned (without being recompiled)?
If yes, then I think most of user32.dll would have to change, wouldn't it?
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
On Tue, 16 Nov 2004 07:38:23 -0800, William Poetra Yoga H wrote:
So, does the app know that it's being themed? What I mean is, for example an app is written for Win 95. In the (unlikely case, so let's change it to Win ME) event that it is compatible with Win XP, will it be skinned (without being recompiled)?
No, theming is a breaking change so Windows only applies it to apps that opt-in (very smart move IMHO even if the user experience does suffer somewhat).
If yes, then I think most of user32.dll would have to change, wouldn't it?
Microsoft appear to have done a copy/paste of code from user32 into a new comctl DLL version, unfortunately we can't do the same so we need to figure out how to implement this.
thanks -mike
On Tuesday 16 November 2004 02:20 pm, Mike Hearn wrote:
No, theming is a breaking change so Windows only applies it to apps that opt-in (very smart move IMHO even if the user experience does suffer somewhat).
On that note, I have been toying with possible ways to start theming common controls. My personal preference is to use a kind of user-defined blacklist ala WindowBlinds, and just theme everything not on the list
--- Roderick Colenbrander thunderbird2k@gmx.net wrote:
Hi,
Some time ago I looked into uxtheme a bit and it roughly works like this. The dll itself is responsible for loading theme files. After a theme is loaded it can for example be used to load a bitmap and draw as for example the background of a window or it can change the color of controls.
Uxtheme can be used in two ways. Useally all theming is done by windows itself. To do the theming microsoft ships a new version of the user and common dialog dlls which use uxtheme to do the theming. In the other case you can call uxtheme yourself and then you can decide yourself what you want to theme.
Not sure if I said it all correctly. Likely Kevin Koltzau knows it a bit better as he is working on uxtheme. Not sure what the current status of the dll is but atleast our controls aren't using it for theming yet.
Roderick
So, does the app know that it's being themed? What I mean is, for example an app is written for Win 95. In the (unlikely case, so let's change it to Win ME) event that it is compatible with Win XP, will it be skinned (without being recompiled)?
If yes, then I think most of user32.dll would have to change, wouldn't it?
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
On Tuesday 16 November 2004 10:38 am, William Poetra Yoga H wrote:
So, does the app know that it's being themed? What I mean is, for example an app is written for Win 95. In the (unlikely case, so let's change it to Win ME) event that it is compatible with Win XP, will it be skinned (without being recompiled)?
If yes, then I think most of user32.dll would have to change, wouldn't it?
Under Windows XP, the only way for an application to be themed is if it has a manifest in its resources requesting comctl 6.0. If an app was written for Win95 it will always draw with the old style as it has no manifest. However, the color scheme of the theme will still be applied to all applications
It is possible to add a a manifest for an existing application without modifying the executable by placing a <app>.exe.manifest file in the same directory as the application executables, but your milage may vary on this approach.
A theme-aware application can call the IsThemeActive and IsAppThemed to determine if a theme is active, and if the current application is themed. XP has a user-configurable blacklist to prevent applications from being themed, even if they are theme-aware..hence the two API calls.
--- Mike Hearn mike@navi.cx wrote:
No, theming is a breaking change so Windows only applies it to apps that opt-in (very smart move IMHO even if the user experience does suffer somewhat).
Microsoft appear to have done a copy/paste of code from user32 into a new comctl DLL version, unfortunately we can't do the same so we need to figure out how to implement this.
thanks -mike
--- Ivan Leo Puoti puoti@inwind.it wrote:
I don't see how it could, if you write a hello world app that just creates a window it won't know anything about theming, but xp will still theme it.
Ivan.
--- Kevin Koltzau kevin@plop.org wrote:
Under Windows XP, the only way for an application to be themed is if it has a manifest in its resources requesting comctl 6.0. If an app was written for Win95 it will always draw with the old style as it has no manifest. However, the color scheme of the theme will still be applied to all applications
It is possible to add a a manifest for an existing application without modifying the executable by placing a <app>.exe.manifest file in the same directory as the application executables, but your milage may vary on this approach.
A theme-aware application can call the IsThemeActive and IsAppThemed to determine if a theme is active, and if the current application is themed. XP has a user-configurable blacklist to prevent applications from being themed, even if they are theme-aware..hence the two API calls.
--- Kevin Koltzau kevin@plop.org wrote:
On Tuesday 16 November 2004 02:20 pm, Mike Hearn wrote:
No, theming is a breaking change so Windows only applies it to apps that opt-in (very smart move IMHO even if the user experience does suffer somewhat).
On that note, I have been toying with possible ways to start theming common controls. My personal preference is to use a kind of user-defined blacklist ala WindowBlinds, and just theme everything not on the list
This is getting a bit complicated. So right now for the colors, we can use uxtheme, right? We should just use GetThemeSysColor(), not GetSysColor(). Btw, why does MS have GetThemeColor()? From what I can see in the MSDN, the only difference is its calling convention.
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
On Thursday 18 November 2004 01:04 am, William Poetra Yoga H wrote:
This is getting a bit complicated. So right now for the colors, we can use uxtheme, right? We should just use GetThemeSysColor(), not GetSysColor(). Btw, why does MS have GetThemeColor()? From what I can see in the MSDN, the only difference is its calling convention.
For colors, you don't need to do anything in most cases. Theme colors override the default system colors for all applications.
GetThemeSysColor and GetSysColor are very similar, in most cases just using GetSysColor is the better option. GetThemeSysColor comes in handy when the application may have changed the system colors through a call to SetSysColors and you need to ensure you get the theme color, which is a rare situation.
GetThemeColor allows the system colors to be overridden on a per-control basis based on the part & state. If you are working on the common controls in wine, or are writing an owner-drawn control that you want to look like a common control, this is the function to use to retrieve system colors. It will always fall back on the system colors when a match is not found on the part & state.
In general, a theme-aware application does not need to do anything differently. The two major differences are owner-drawn controls and the addition of a manifest in the resources.
--- Kevin Koltzau kevin@plop.org wrote:
For colors, you don't need to do anything in most cases. Theme colors override the default system colors for all applications.
OK, so I think windows/nonclient.c doesn't need to be changed, we just have to load a theme somewhere at wineserver startup.
GetThemeSysColor and GetSysColor are very similar, in most cases just using GetSysColor is the better option. GetThemeSysColor comes in handy when the application may have changed the system colors through a call to SetSysColors and you need to ensure you get the theme color, which is a rare situation.
But why is GetSysColor() better? If an application can change the system colors, then the GetSysColor() function's return value may be inconsistent (with the current theme color) which is not good. And how do we know that an application has changed the colors? So in this case I think it's better to call GetThemeSysColor() in windows/* code, right?
In general, a theme-aware application does not need to do anything differently. The two major differences are owner-drawn controls and the addition of a manifest in the resources.
But I think wine's dlls need to be altered a bit :)
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
On Friday 19 November 2004 06:17 pm, William Poetra Yoga H wrote:
OK, so I think windows/nonclient.c doesn't need to be changed, we just have to load a theme somewhere at wineserver startup.
This is an area that is somewhat in the air currently. There are 2 methods I am toying with to theme standard window components.
1) Modify all wine widget code to support drawing with themes, in which case nonclient.c would need to be updated. 2) Subclass all controls to do theme drawing when uxtheme.dll is loaded. This would require very few changes, if any, to drawing code in wine, but would be harder to implement and may duplicate a large amount of drawing code.
Windows uses a combination of those two methods, with the addition of a system service to coordinate and cache data, unfortunately this may not be an option as it would probably involve integrating theming into the wineserver which I doubt Alexandre would approve of.
But why is GetSysColor() better? If an application can change the system colors, then the GetSysColor() function's return value may be inconsistent (with the current theme color) which is not good. And how do we know that an application has changed the colors? So in this case I think it's better to call GetThemeSysColor() in windows/* code, right?
GetSysColor is better for the very reason that applications can change the system colors. For example, under XP the user can override the colors of a theme in the display properties. When SetSysColors is called, it broadcasts a WM_SYSCOLORCHANGE message to notify colors have changed.
-
Andreas Mohr -
Kevin Koltzau -
Mike Hearn -
Roderick Colenbrander -
Stefan Dösinger -
William Poetra Yoga H