Ubuntu

Wine uses Windows colors instead of Ubuntu colors

Reported by Pascal de Bruijn on 2007-04-29
78
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Wine
Confirmed
Wishlist
gnome-themes-ubuntu (Ubuntu)
Undecided
Unassigned
human-theme (Ubuntu)
Undecided
Unassigned
wine (Baltix)
Undecided
Unassigned
wine (Ubuntu)
Medium
Unassigned

Bug Description

Wine needs direction from the system theme in order to color itself, as attempting to guess colors by probing the theme is complicated and doesn't always work right, especially when the theme engine completely redoes the drawing of widgets.

As such, for Wine to look consistent, we should provide hints for Wine inside each system theme package that Wine can then look to for coloring itself. There are some suggestions about how to create a uxtheme template that Wine can use here: http://wiki.winehq.org/XPThemes

Original report:
Wine by default uses the Windows grey color for it's main window color, which is ugly by itself. But when combined with the Ubuntu desktop it gets even uglier. It would be nice to have wine pre-configured with the following color scheme (which is adapted to Ubuntu colors):

[Control Panel\\Colors] 1177865204
"ActiveBorder"="192 192 192"
"ActiveTitle"="0 0 128"
"AppWorkSpace"="128 128 128"
"Background"="0 128 128"
"ButtonAlternateFace"="180 180 180"
"ButtonDkShadow"="0 0 0"
"ButtonFace"="192 192 192"
"ButtonHilight"="255 255 255"
"ButtonLight"="224 224 224"
"ButtonShadow"="128 128 128"
"ButtonText"="0 0 0"
"GradientActiveTitle"="16 132 208"
"GradientInactiveTitle"="181 181 181"
"GrayText"="128 128 128"
"Hilight"="0 0 128"
"HilightText"="255 255 255"
"HotTrackingColor"="0 0 255"
"InactiveBorder"="192 192 192"
"InactiveTitle"="128 128 128"
"InactiveTitleText"="192 192 192"
"InfoText"="0 0 0"
"InfoWindow"="255 255 225"
"Menu"="192 192 192"
"MenuBar"="192 192 192"
"MenuHilight"="0 0 0"
"MenuText"="0 0 0"
"Scrollbar"="192 192 192"
"TitleText"="255 255 255"
"Window"="255 255 255"
"WindowFrame"="0 0 0"
"WindowText"="0 0 0"

Scott Ritchie (scottritchie) wrote :

Agreed, however the ultimate solution is to have Wine's theming support read the system theme - I believe there's a Summer of Code project to this very effect.

Regardless, if that doesn't get done in time, I'll try changing the default colors for Gutsy.

Changed in wine:
assignee: nobody → scottritchie
status: Unconfirmed → Confirmed
Pascal de Bruijn (pmjdebruijn) wrote :

A good, of course a Clearlooks theme for wine would be better, but I assumed that would be a lot of work... so having the colors synced seemed like a good compromise for the time being...

Stephan Adig (sadig) on 2007-05-25
Changed in wine:
importance: Undecided → Wishlist
Stephan Adig (sadig) on 2007-05-28
Changed in wine:
assignee: scottritchie → ubuntu-wine
beerfan (beerfan) wrote :

There are Clearlooks-alike themes for Windows. The problem is that using non-classic themes in Wine causes a huge performance hit. Even using a Microsoft provided theme like Royale (the MCE theme) slows my Wine to unusable levels.

Simply implementing a friendlier color scheme would be a huge improvement.

beerfan (beerfan) wrote :

By the way, the color scheme give above doesn't look right to me. It looks like the default windows (gray) colors.

The color scheme given at https://help.ubuntu.com/community/Wine#head-80549bd5796be9095a66ba1d30b531dc4ae9be5a represents fairly accurately the Human colors.

[Control Panel\\Colors] 1176981676
"ActiveBorder"="239 235 231"
"ActiveTitle"="239 235 231"
"AppWorkSpace"="198 198 191"
"Background"="93 77 52"
"ButtonAlternativeFace"="200 0 0"
"ButtonDkShadow"="85 85 82"
"ButtonFace"="239 235 231"
"ButtonHilight"="255 255 255"
"ButtonLight"="255 255 255"
"ButtonShadow"="198 198 191"
"ButtonText"="0 0 0"
"GradientActiveTitle"="239 235 231"
"GradientInactiveTitle"="239 235 231"
"GrayText"="198 198 191"
"Hilight"="246 200 129"
"HilightText"="0 0 0"
"InactiveBorder"="239 235 231"
"InactiveTitle"="239 235 231"
"InactiveTitleText"="255 255 255"
"InfoText"="0 0 0"
"InfoWindow"="255 255 166"
"Menu"="239 235 231"
"MenuBar"="0 0 0"
"MenuHilight"="246 200 129"
"MenuText"="0 0 0"
"Scrollbar"="239 235 231"
"TitleText"="255 255 255"
"Window"="255 255 255"
"WindowFrame"="0 0 0"
"WindowText"="0 0 0"

Loye Young (loyeyoung) wrote :

The problem with hardcoding the color scheme is that not everyone will want or be using the Ubuntu default color scheme. In fact, as Beryl and other graphical improvements come online, there will be less and less uniformity of color schemes over time. Remember, the Wine that runs under Gnome is the same wine that runs under XFCE (Xbuntu) and KDE (Kubuntu), not to mention the variations of Ichthux, Ubuntu Studio, Ebuntu, Fluxbuntu, etc. etc. The "Right Thing To Do (TM)" is for Wine to use by default the colors from the user's environment.

I'm running Kubuntu, which is of course Ubuntu with the KDE Desktop Environment. When I configure Wine via Kubuntu's normal System Settings (K Menu --> System Settings --> Advanced --> Windows Applications --> Appearance), the Color Scheme setting allows me to select "Get KDE Colors". That is what should be the default, and what Ubuntu's Gnome desktop should do as well.

What's so different about Gnome that it can't be done already? Seems like the same or similar code from Kubuntu's System Settings could be used to read Gnome's environment settings.

Loye Young

Pascal de Bruijn (pmjdebruijn) wrote :

Well yes, that's true.

However, it currently does not look good in any of the environments.

I'd rather have it look good in one, then in none.

Also please remember that Ubuntu is a GNOMEish distribution primarily.

Besides I think the default XFCE and GNOME color schemes are reasonably similar.

Loye Young (loyeyoung) wrote :

"I'd rather have it look good in one, then in none. . . . Besides I think the default XFCE and GNOME color schemes are reasonably similar."
A reasonable argument.

"Also please remember that Ubuntu is a GNOMEish distribution primarily."
I disagree. Ubuntu, Kubuntu, and Xbuntu are all official Canonical-sponsored projects, sharing the same codebase for all three. Linus Torvalds, Mark Shuttleworth, Michael Dell, and many others use the KDE environment (i.e., Kubuntu). The default is Gnome, because it's the one most likely to appeal to home users and computer novices, which seems to be a reasonable approach.

Best practice would be to make wine and other Ubuntu-distributed packages desktop environment neutral, to the greatest extent possible. In this case, I'm arguing that we should make the default to integrate with _whatever_ desktop color scheme they have, but leave the fallback colors alone. My reasoning is that folks like you and me want it to look like their desktop. Those who don't probably want a Window-ish look and feel (which is, IMHO, ugly).

Is there not already an option for Gnome users to pull the colors from the desktop environment, like KDE users can in System Settings (which is from the kde-system-settings package)? If not, what would that require? I can't image it would be much harder for Gnome than for KDE.

But if I'm wrong, and something about the Gnome configurations make it terribly time consuming, then perhaps the install script should decide on the default color scheme depending on which desktop environment is installed. For KDE, it would be "Get KDE Colors", for Gnome, it would be the {perhaps hard coded for now) "Default Ubuntu Colors".

Loye Young

beerfan (beerfan) wrote :

I'm going to step out on a limb here with some opinion.

The theme that Linus, or even Mark Shuttleworth, is irrelevant. So is discussion about Kubuntu or any other *derivative* distribution.

The default theme in Ubuntu is "Human" and apps that do not support metacity/gnome themes (like Wine and Qt) should have some similar themes added to at least make an effort to integrate well with the default theme. Requests to support native themes with Wine are likely to be much more difficult to solve leaving us with no interim solution. Those requests should be placed in another (upstream) bug.

"The default theme in Ubuntu is "Human"."
Ubuntu isn't the only install that the wine package must support. We must also
support Kubuntu, Xbuntu, and Edubuntu, all of which are standard Ubuntu
installs. The default color scheme for each of those are much different.

There's nothing about wine that suggests its user interface should have the
Gnome desktop settings hard-coded into it. In point of fact, the current
defaults look better with Kubuntu than would the Human orange, red, and
brown.

"Requests to support native themes with Wine are likely to be much
more difficult to solve leaving us with no interim solution. Those
requests should be placed in another (upstream) bug."

We _already_ support native color schemes. The problem is that apparently it
doesn't work for the Gnome desktop, or we wouldn't be having this discussion.

I'll take a stab tonight at figuring out why it works for Kubuntu but not
Gnome. I'll get back with you before the week is out.

"Is there not already an option for Gnome users to pull the colors from the desktop environment, like KDE users can in System Settings (which is from the kde-system-settings package)? If not, what would that require? I can't image it would be much harder for Gnome than for KDE."

It would require a GTK/gnome port of the wineconfig utility that you are referring to.

Loye Young (loyeyoung) wrote :

I apologize for not getting this done.

I have dug through the code and Yuriy is exactly correct, a gtk/gnome port of the wineconfig (or creating a similar application from scratch) is the Right Thing To Do. (He is the authority because he wrote wineconfig, which is a very fine tool.) At the UbuntuLive conference last week, the Ubuntu team said that they are working on better integration of wine and the Ubuntu desktop for the Gutsy release.

I continue to think that this "bug" is better solved outside of the wine package received from upstream. Instead, it should be handled by the desktop environment of the user.

For both of these reasons, I am abandoning my effort on this bug, and I would vote to either close this bug and reassign it to a different package.

Having said that, the solution suggested by beerfan above (perhaps with a summary of this thread) would make an excellent addition to the wiki so that users at large would have accessible and cogent documentation on tuning their Wine colors.

Loye Young

Scott Ritchie (scottritchie) wrote :

It looks like theming hasn't improved enough in Wine to have proper theming support in Gutsy.

Maybe by Wine 1.0... (and maybe by Hardy...)

Michael Rooney (mrooney) wrote :

Would anyone mind explaining exactly where those options go? I assume in a config file somewhere but I am not sure which one. I will eagerly await better Wine and Ubuntu integration but until then, this is much better than nothing I suspect. Thanks!

Yuriy Kozlov (yuriy-kozlov) wrote :

The color options mentioned above are in a key in the windows/wine registry. You can edit it manually using regedit or using wineconfig (part of the kde-guidance package).

A theme (widget style) can be enabled through winecfg or wineconfig, but as mentioned, theming support is buggy.

hroo772 (hroo772) wrote :

In the new release of wine 0.9.50, these commits were made and are apart of the .50 release:

user32: Fix colours to match exactly with Windows 2000.
http://source.winehq.org/git/wine.git/?a=commit;h=91d2b609c3d13ee7a2fcdf5529a8c0ea9d6f7266

user32: Change the desktop colour and pattern to match win2k.
http://source.winehq.org/git/wine.git/?a=commit;h=113f573b25f136674bfd7324b54ad7109d01142b

user32, wine.inf: Enable title bar gradients and match colours with win2k.
http://source.winehq.org/git/wine.git/?a=commit;h=1aff3528cf0a7760758274766c1d4021b7ffa0c1

user32: Change to modern Windows colours.
http://source.winehq.org/git/wine.git/?a=commit;h=1f8ba9612880582b8db827cae4b6f2c4504c602e

Since all of these changes were made in the new release, once Ubuntu can update the version in apt, there should be no need for messy/registry fixes.

beerfan (beerfan) wrote :

@hroo772, how are these changes relevant? I don't see any new or changed options in winecfg for 0.9.50 and the wine theme is unchanged.

Scott Ritchie (scottritchie) wrote :

Wine has a new colorscheme in 0.9.50...but it's still the WINDOWS color scheme and theming support is still broken. Still, 0.9.50 is better than 0.9.49 and will be uploaded to Hardy soon.

I still say that the "Right Way to Do It" would be to port Yuriy's
wineconfig application to Gnome/GTK and keep it as a separate
application so that we don't booger up wine and have to keep messing
with it every time wine gets updated.

But I don't much have a dog in the race.

Loye

On Dec 3, 2007 3:10 PM, Scott Ritchie <email address hidden> wrote:
> Wine has a new colorscheme in 0.9.50...but it's still the WINDOWS color
> scheme and theming support is still broken. Still, 0.9.50 is better
> than 0.9.49 and will be uploaded to Hardy soon.
>
>
> --
> Wine use Windows colors instead of Ubuntu colors
> https://bugs.launchpad.net/bugs/111061
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
(956) 857-1172
<email address hidden>

Hey Scott, you mentioned changing the default colors for Gutsy but I don't think that made it in. Does anyone know if there is any progress relating to this on Hardy? Is this the main bug regarding better wine integration with Ubuntu?

Endolith (endolith) wrote :

Since theming doesn't work, couldn't a script at least be written that sets the COLORS to match the desktop you are using? There's only 31 colors in that config file, and it's just plain text. Surely the Gnome color scheme is stored in an equally-transparent file somewhere, and a simple translator could be written.

Scott Ritchie (scottritchie) wrote :

Intrepid would be a good target for this to finally get done. We'll need a Windows version of the new theme, and then we can peel out the parts that make Wine really slow.

Changed in wine:
importance: Wishlist → Medium
Endolith (endolith) wrote :

I tried to write a script to update the colors based on Gnome, but I give up. I can't figure out how to read them from various places, or when I do read them, they don't match the actual colors. It works somewhat for some themes. See http://ubuntuforums.org/showthread.php?p=5506889#post5506889

Changed in wine:
status: Unknown → New

Endolith,

We've been learning a thing or three about the subject lately, and here's
what we've found.

/usr/share/gconf/defaults/ is where the original defaults come from. It gets
copied to the users' home directories when the users log in the first time.

The gnome-color-chooser application creates a separate file which overrides
the particular user's default settings. Making some changes with
gnome-color-chooser and then reading the resulting file should be
instructive on finding which key/variable pairs you need to read.

The gconf-editor package is a graphical interface to gconf, and it may also
be of assistance.

python-gconf contains the bindings that allow you to work with gconf in
python. (KDE's wine configuration tool is written in python, if my memory
serves me correctly. )

Happy trails,

Loye Young

On Fri, Aug 1, 2008 at 9:37 PM, Endolith <email address hidden> wrote:

> I tried to write a script to update the colors based on Gnome, but I
> give up. I can't figure out how to read them from various places, or
> when I do read them, they don't match the actual colors. It works
> somewhat for some themes. See
> http://ubuntuforums.org/showthread.php?p=5506889#post5506889
>
> --
> Wine use Windows colors instead of Ubuntu colors
> https://bugs.launchpad.net/bugs/111061
> You received this bug notification because you are a member of Ubuntu
> Wine Team, which is a bug assignee.
>

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
<email address hidden>
956.857.1172

> The gnome-color-chooser application creates a separate file which overrides
> the particular user's default settings. Making some changes with
> gnome-color-chooser and then reading the resulting file should be
> instructive on finding which key/variable pairs you need to read.

> The gconf-editor package is a graphical interface to gconf, and it may also
> be of assistance.

Hmm.. I should be reading the colors from gconf instead of directly from gtk? I noticed that some colors were in gconf, but I thought the location varied with the gtk engine you are using.

> python-gconf contains the bindings that allow you to work with gconf in
> python.

I've already got gconf in the script to read the Gnome Desktop background color.

http://bazaar.launchpad.net/~endolith/%2Bjunk/wine-color-scraper/files

> (KDE's wine configuration tool is written in python, if my memory
> serves me correctly. )

What's the name of the KDE tool?

>Hmm.. I should be reading the colors from gconf instead of directly from
>gtk? I noticed that some colors were in gconf, but I thought the
>location varied with the gtk engine you are using.

You might be right. The way that ubuntu/gnome/gtk handle branding and
theming pretty much sucks, so I do feel your pain. We've had to wade through
a lot of undocumented packages to get it right. Even so, my guess is that
gconf is the missing piece of the puzzle you are looking for.

We at IYCC use gconf for our branding, and it works. Take a look at the
first six screenshots here: http://www.iycc.net/screenshots. You, however,
have a slightly different problem because you are working the other
direction, i.e., you are trying to follow the settings, not overwrite them.

>What's the name of the KDE tool?
wineconfig. Yuriy, one of the posters in this thread, is the author.

I actually took a stab at this project in the past, but decided that the
problem should be fixed in separate package, the way Yuriy did it. I
documented my reasoning, so take a look at the earlier postings in the
thread.

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

> You might be right. The way that ubuntu/gnome/gtk handle branding and
> theming pretty much sucks, so I do feel your pain. We've had to wade through
> a lot of undocumented packages to get it right. Even so, my guess is that
> gconf is the missing piece of the puzzle you are looking for.

Well, our color scraper script works fine as far as configuring Wine to follow the Gnome colors through a registry edit. It's just a matter of discovering how to get certain colors out of GTK. I've found many that seem correct, but others that don't. I've asked around in many places but find it hard to get any response:

http://<email address hidden>/msg12076.html

> wineconfig. Yuriy, one of the posters in this thread, is the author.

Oh, nice! I wasn't able to find anything remotely similar. Got it from http://www.simonzone.com/software/guidance/guidance-0.8.0.tar.bz2

Looks like he uses the same method for updating the registry by creating a file and importing it with regedit. Probably some things that could be improved on our end, though. :)

But to scrape the colors, he just reads from kdesktoprc. If there is anything similar to this in Gnome, I haven't been able to find it.

 Here's a pretty good description of the current state of things:
http://live.gnome.org/GnomeArt/Tutorials/GtkThemes. From that article:
<quote>Everything you want to change is being changed in so called "styles".
Within these styles you have two kinds of properties. On the one hand there
is a limited set of predefined style-properties of the GTK+ theming system,
which define things like the width of the scrollbar. On the other hand there
are the theming possibilities the engines define. These engine styles are,
where most of the theming options are possible. The interesting part about
the GTK theming system is that different styles are merged to create the
final one. So what you usually will do is to define a base style with all
common options in it, and then change colors for a specific widget. </quote>

It would be possible to code around each theme engine, at least if we have a
list of them, but that would require more patience than I have. Perhaps the
Right Way to Do It (tm) would be to standardize the color settings for GTK.

Another option would be to scrape a couple or three of the most common
engines and grab the rest from gconf.

This leads me back to the conclusion I came to a while back: the solution
should be done as a separate project and not as part of the WINE package. If
done in a standardized way, the project could be useful in contexts other
than WINE.

Loye

At Wineconf, the Wine developers agreed on an alternative solution that seems optimal for Wine:

Bundling specially-crafted Windows themes alongside system themes. When I switch to the Human theme in Ubuntu, or the Ubuntu-Studio theme, they should both have an included Windows .theme file that is essentially ignored by the system. Wine can then read that .theme and use it.

One nice advantage of doing this is that we can make Wine applications look slightly different from GTK ones when it's necessary. By customizing the Windows theme, we can also avoid the slow parts that Wine doesn't quite handle right, and actually take advantage of the (mostly) working parts of Wine's theming engine.

@Scott

Is that already implemented? Is the syntax of .theme documented anywhere?

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

No, not yet implemented, it was just a discussion.

BTW Picasa tried theme color scraping, it was spectacularly ugly, so we stopped.
The Wineconf "tracking themes" proposal mentioned by Scott is much more promising.

It's good to learn from others' mistakes. :-)

Okay, so why don't we start by creating a Default.theme (using the default
wine Window-ish colors) and Human.theme that is in the same format as the
reg files, and have wineconf read that? If memory serves correctly, the
settings are saved to ~/.wine/user.reg.

A separate package with the themes ("wine-themes"?) seems prudent as it
would modularize the implementation better, IMHO. Other desktops can submit
themes to the theming package, or create their own packages based on
wine-themes (e.g., "wine-themes-ubuntu-studio", "wine-themes-iycc", etc.).

Endolith, can you use that script of yours to scrape the gnome settings from
gconf, gtkrc, and perhaps other obvious places and save a .theme file, at
least as a "wag and a poke" themer?

BTW, seems like it would be pretty simple to create a Wine Color Chooser
similar to Gnome Color Chooser that creates the Wine theme file. Maybe we
could even add a checkbox to Gnome Color Chooser to make the wine theme. But
writing a new program we should probably leave to another day. :-)

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
<email address hidden>
956.857.1172

> It would be possible to code around each theme engine, at least if we have a
> list of them, but that would require more patience than I have. Perhaps the
> Right Way to Do It (tm) would be to standardize the color settings for GTK.

Yeah. I talked to Havoc Pennington today (http://ometer.com/gtk-colors.html), and he said it's basically impossible to do what I'm trying to do, since every GTK engine has its own painting code, and can use the colors however it wants. Most seem to use the colors in the same way, so the script gives decent results, but not for all cases. If we needed to, we could probably make it work by writing separate mappings for each engine, though I don't really want to do it. :) It could at least be considered a Clearlooks scraper, as is. I posted screenshots of some of the results:

http://www.endolith.com/wordpress/2008/08/03/wine-colors/#toc-screenshots

> Bundling specially-crafted Windows themes alongside system themes. ...
> and actually take advantage of the (mostly) working parts of
> Wine's theming engine.

So this will be actual themes (msstyle files), and not just colors? That sounds like a great halfway solution until real theming works (although requiring more manual labor). Also it wouldn't handle user-customized colors, so we might merge these two efforts somehow.

> Endolith, can you use that script of yours to scrape the gnome settings from
> gconf, gtkrc, and perhaps other obvious places and save a .theme file, at
> least as a "wag and a poke" themer?

All it does is copy the colors from actual GTK elements. It won't copy other aspects of the GTK theme that would be useful in an msstyle file.

Note that we should make the fonts the same, too, and I'm not sure how to set those except for the ones included in the winecfg utility Desktop Integration tab.

> BTW, seems like it would be pretty simple to create a Wine Color Chooser
> similar to Gnome Color Chooser that creates the Wine theme file. Maybe we
> could even add a checkbox to Gnome Color Chooser to make the wine theme. But
> writing a new program we should probably leave to another day. :-)

All of the wine colors are already settable in winecfg. Do you mean something else?

Dan Kegel (dank) wrote :

> So this will be actual themes (msstyle files), and not just colors?
> That sounds like a great halfway solution until real theming works
> (although requiring more manual labor).

Yes, real msstyle files.

> Also it wouldn't handle user-
> customized colors, so we might merge these two efforts somehow.

How about including a tool to let users easily customize the msstyle files
and/or partially populate an msstyle file from a native theme?
- Dan

Endolith (endolith) wrote :

> Yes, real msstyle files.

Ah. And we know how to "avoid the slow parts that Wine doesn't quite handle right"?

> How about including a tool to let users easily customize the msstyle files
> and/or partially populate an msstyle file from a native theme?

Should we then be talking about msstyles for each GTK *engine*, not for each theme? Some of these already exist:

http://schmoove.deviantart.com/art/ClearLooks-for-Windows-XP-18591720?offset=30

Then using a script to color and size them? Does winecfg's Desktop Integration color changer affect msstyles themes?

On Thu, Oct 23, 2008 at 7:01 AM, Endolith <email address hidden> wrote:
>> Yes, real msstyle files.
>
> Ah. And we know how to "avoid the slow parts that Wine doesn't quite
> handle right"?

I don't, but either a) people can avoid them by trial and error
and/or b) wine can improve.

>> How about including a tool to let users easily customize the msstyle files
>> and/or partially populate an msstyle file from a native theme?
>
> Should we then be talking about msstyles for each GTK *engine*, not for
> each theme? Some of these already exist:
>
> http://schmoove.deviantart.com/art/ClearLooks-for-Windows-
> XP-18591720?offset=30

Hey, that sounds like the way to go...
has anybody tried these in Wine yet?

> Then using a script to color and size them?

Mumble. I'm no GUI guy. Sounds good to me.

> Does winecfg's Desktop Integration color changer affect msstyles themes?

I think they're two different ways of jamming the
same info in. I haven't looked to see if that's
true or which one wins if you try both.
- Dan

Changed in wine:
status: New → Confirmed
Changed in wine:
status: Confirmed → Fix Released

> Hey, that sounds like the way to go...
> has anybody tried these in Wine yet?

I tried it and it didn't have any effect on buttons, window borders, etc. Tabs were different, but that was the only noticeable change besides colors.

> I think they're two different ways of jamming the
> same info in. I haven't looked to see if that's
> true or which one wins if you try both.

I think the msstyles file sets colors in the registry, but you can then change them with winecfg. The tab colors could not be changed, presumably because they are images, and there was a blue and orange theme built into the one file. Try one and you'll see how it works.

Reece H. Dunn (msclrhd-gmail) wrote :

Hi,

Wine has had support for loading colour-based .theme files correctly for a while now (see https://wiki.ubuntu.com/WineHumanTheme for a human.theme file).

Winecfg will load a theme's colour profile into the registry, and allow you to change that in the appearance section (item, color, size and font elements), as well as loading any msstyle data. The msstyle data takes precedence (if you are not in 'classic' mode in Windows; there is not currently an equivalent feature in Wine/winecfg). At the moment, the push buttons, radio buttons and check boxes (and possibly some other controls in user32.dll) are not properly themed, so will use the themes colour profile.

I also have some ideas (http://www.winehq.org/pipermail/wine-devel/2008-October/069583.html) on improving winecfg, some of which I have sent patches for. Owen Rudge (http://www.winehq.org/pipermail/wine-devel/2008-October/069593.html) also has more ideas on this as well.

With Windows Vista, Microsoft have changed the msstyle theme data format. As such, it should be possible to make the theme engine (uxtheme.dll) in Wine interact with the Gtk, Qt and Cocoa/Carbon theme APIs to render elements correctly.

Any application that modifies the msstyle theme will need to inform the wineserver to send out a WM_THEMECHANGED notification to all top-level windows so that they can update properly; likewise any colour profile changes, the application will need to inform the wineserver that it needs to send out a WM_SYSCOLORCHANGED notification.

Mephisto (ferrylandzaat) wrote :

Can someone enlighten me on something? Why is all the talk about adapting color schemes, when a much cleaner solution would be to just have GTK draw the wine windows, like mono, java and other languages do? What makes wine so special that it cant implement something like Qt does with QGtkStyle (making qt look like gtk)?

Reece H. Dunn (msclrhd-gmail) wrote :

> Why is all the talk about adapting color schemes, when a much cleaner solution would be to just
> have GTK draw the wine windows, like mono, java and other languages do? What makes wine
>so special that it cant implement something like Qt does with QGtkStyle (making qt look like gtk)?

Qt has its own theming API, so that calls to the Qt engine can be mapped to the Gtk engine.

Windows did not support a theming engine before XP (and then you have to call the correct APIs and mark your application to be theming aware). Applications can get the system colours and interrogate some of the metric information (such as the width of a scrollbar). An application will (if it is written correctly) get those system colours to render different parts of the application. If it is a text editor, it will select the window background and text colour to use, for example.

For applications that support theming the situation is better, but there you are limited to what is available in the XP, Vista and soon to be Windows 7 APIs.

Note that because Wine is multi-platform it will need to work with Gtk, Gt, Cocoa/Carbon and also in the absence of these (e.g. if you are running on OpenSolaris).

In addition to this, the Wine theming support is not yet to the point where it will render an XP theme (like the Zune theme) perfectly and efficiently.

Providing a colour scheme profile will make any Windows compliant application look better and stand out less. Having an XP-style theme that matches the Gtk theme will give a more natural look. Providing hooks into the native theming engines will give the best look and feel, but will need to be done right in order to get it accepted upstream.

It's all about ordering the tasks by how easy they are. The colour profile stuff already works, so is the easiest to do. Full blown integration is the hardest.

Mephisto (ferrylandzaat) wrote :

Well, your point of windows lacking a theme engine in the old days is valid, but software that has been updated in the last 8 years or so usually supports theming, cause no windows developer would want their app to look bad on XP.
Sure, wine theming support is nowhere near complete, but that should be irrelevant, cause rendering through GTK should bypass that theme engine, as its not needed.
And yes, wine should work regardless of the user having GTK, Qt or whatever installed, but i don't see why this would be an issue. Wine can just try to open the GTK/Qt/etc library that it wants to use, and if it's not available, fall back to the old rendering engine. No one said the old way has to be deleted ;)

Dan Kegel (dank) wrote :

Although using GTK themeing sounds nice, it's impractical;
wine is going to use windows themes. See
http://www.winehq.org/pipermail/wine-devel/2008-November/070338.html

But the color scheme of Ubuntu Human should really be applied to WINE by default.

At Launchpad: https://bugs.edge.launchpad.net/ubuntu/+source/gnome-themes-ubuntu/+bug/111061
Relevant wiki page: http://wiki.winehq.org/XPThemes

The general idea is that we should have system themes that provide hints to Wine about how to color itself in the form of a Wine-specific uxtheme file. Once we write these theme files for each system theme, Wine needs to learn to probe for them in a standardized way at startup. It could be as simple as just throwing "winehints.theme" somewhere into the file, or it could be more involved.

description: updated

The upstream Wine bug is for defining a standardized way of embedding these hints.

Changed in wine:
status: Fix Released → Unknown

Didn't mean to change the version...

Changed in wine:
status: Unknown → Confirmed
Endolith (endolith) on 2009-05-20
summary: - Wine use Windows colors instead of Ubuntu colors
+ Wine uses Windows colors instead of Ubuntu colors
Endolith (endolith) wrote :

Hints in the package separate from the theme would be nice. A list of colors ain't enough, though, since users can change the system colors and the theme may or may not change components' colors accordingly.

Gecko/Firefox/Mozilla tries to guess these colors, too (nsLookAndFeel.cpp), and doesn't do a very good job, either. There are probably other places they are used.

Since themes can do whatever they want with GTK's colors, what would be best, I think, is if there were a standard interface built into the theme engines(?) themselves that would output these lists of colors, as they are currently configured, when asked. The CSS2 standard includes a few extra "ThreeD" colors, but is otherwise pretty much the same list of colors as Windows/Wine. (http://www.endolith.com/wordpress/2008/08/03/wine-colors/)

Even with a real Wine theming engine made to match the widgets and decorations of the GTK theme, do you still need to get the color information separately?

Scott Ritchie (scottritchie) wrote :

A Wine theme engine can't match the widgets and decorations of a GTK theme, as Windows programs make different assumptions about their widgets. So, yes, Wine will need separate color information.

Endolith (endolith) wrote :

Yeah, they use colors differently, but you still need up-to-date information from the GTK theme itself to know which colors it's currently using. A static list of colors won't work, since the theme can be changed by the user.

Since each theme engine can use the GTK colors however it wants, you need a separate set of mappings for each engine, so you know which colors it's using for elements that are *similar* to the elements in the Windows theme.

Scott Ritchie (scottritchie) wrote :

Perhaps that means the uxtheme hints file needs to be dynamically generated by the theme (or at least updated by the color chooser)

Seems like a wishlist. Should be marked as such.

Changed in wine:
importance: Unknown → Wishlist
Alin Andrei (nilarimogard) wrote :

There is a script which can do this [1], but it still needs a bit of work. The script is actively developed so maybe someone here could help...

[1] http://www.webupd8.org/2010/06/make-wine-applications-look-like-your.html

Endolith (endolith) wrote :

Yes, I started the script because of this bug report, as discussed above. :D http://www.endolith.com/wordpress/2008/08/03/wine-colors/

Alin Andrei (nilarimogard) wrote :

Oh, sorry for not reading all the comments. So then, any official word on this or some other "fix" being included in Ubuntu?

tags: added: color theme wine
Dylan McCall (dylanmccall) wrote :

I'm wondering if this is a sane thing to do. LOTS of Windows applications make assumptions about the colour scheme, so this could end up looking like a mishmash in those cases, and just broken in others. I'm especially concerned about text here.

Besides, using the Ubuntu colours won't change that the widgets are Windows widgets, drawn in the basic Windows style.

I think changing these defaults will need _a lot_ of careful regression testing.

Fred (eldmannen+launchpad) wrote :

Well if not change default, Ubuntu could still ship an optional theme.
Also with themes, the widgets could be themed to look more like the theme from Ubuntu.

I seem to remember shipping a default theme has been discussed before but there seem to be trouble with the licensing since it's apparently not possible to create a theme using only open source tools (can anyone find this discussion?).

Maybe we could ship with _links_ to a few common themes?

*** Bug 24769 has been marked as a duplicate of this bug. ***

Changed in wine (Ubuntu):
status: Confirmed → In Progress
Changed in wine (Ubuntu):
status: In Progress → Confirmed
status: Confirmed → In Progress
Changed in wine (Ubuntu):
assignee: Ubuntu Wine Team (ubuntu-wine) → nobody
status: In Progress → Triaged
Changed in human-theme (Ubuntu):
status: New → Won't Fix
Changed in gnome-themes-ubuntu (Ubuntu):
status: New → Won't Fix

Scott: As of your launchpad bug url there won't ever be hints for us in the system themes, right?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.