[Bug 59739] New: Ability to set theme for all prefixes easily
http://bugs.winehq.org/show_bug.cgi?id=59739 Bug ID: 59739 Summary: Ability to set theme for all prefixes easily Product: Wine Version: 11.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: uxtheme Assignee: wine-bugs@list.winehq.org Reporter: fatihbakal7@protonmail.com Distribution: --- Disclaimer: I know there are already similar issues to this. This one is just a proposal for a global setting tho so I thought it deserves it's own issue. It's just way too much of a hassle to set a theme up to each prefix. Currently there's 3 ways of theming wine that I'm aware of. 1. .reg files 2. .msstyle/.theme files 3. That 1 experimental GTK3 theming patch that's been in staging for ages (broken on most installs) My proposal is that every single prefix uses the same directory to check for `theme.reg/.msstyle/.theme` files in one of these directories; `~/.config/wine` `~/.local/share/wine/` `$HOME/` (would have to be named wine_theme for this to not be confusing) Also does anybody know a way I can contact upstream people quickly? I did think of opening a PR for this but thought I would end up not getting a response like this https://gitlab.winehq.org/wine/wine/-/merge_requests/10543 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #1 from fatihbakal7@protonmail.com --- Edit: found duplicate of this issue https://bugs.winehq.org/show_bug.cgi?id=48506 somebody please let me know on the last part I might look into it if there's interest from upstream people just like the other PR -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 Stefan Dösinger <stefan@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com --- Comment #2 from Stefan Dösinger <stefan@codeweavers.com> --- My 2c is that we don't want to soften the separation between prefixes. Wine Mono, Wine Gecko, etc are static data. The current theme selection is not. The best solution to easily changeable themes would be a default theme that manages to follow the system gtk/qt/macos theme, but as you observed, it isn't easy to do. I tried to go a little step into this direction by cleaning up the color management in light.msstyles, but Windows theming is awful (MR 7590). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #3 from Stian Low <wineryyyyy@gmail.com> --- (In reply to fatihbakal7 from comment #0)
It's just way too much of a hassle to set a theme up to each prefix.
winecfg supports setting version via command line: winecfg /v win10 winecfg also handles setting themes but does not provide a command line option. Would a command line option such as the following resolve hassles? Such as: WINEPREFIX=/bogus/pfx_0 winecfg /t aero WINEPREFIX=/bogus/pfx_1 winecfg /t aero WINEPREFIX=/bogus/pfx_2 winecfg /t aero_dark -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #4 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #3)
WINEPREFIX=/bogus/pfx_0 winecfg /t aero
Typo but /t as theme flag is the relevant part: WINEPREFIX=/bogus/pfx_0 wine winecfg /t aero -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #5 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 80904 --> http://bugs.winehq.org/attachment.cgi?id=80904 Screenshot of winecfg proof of concept Attached is a screen shot of a winecfg proof of concept. Previous proposed /t theme option solves easily setting but not sharing across prefixes: WINEPREFIX=/bogus/pfx_0 wine winecfg /t aero The screenshot replaces /bogus/pfg_0/drive_c/windows/resources/themes with a symlink to arbitrary shared path ~/.local/share/wine_bug_59739_test/themes/. With that done, winecfg Theme dropdown lists path that may be shared across all prefixes. If winecfg were extended with command line options to either replace `resources/themes` with a symlink or alternatively just use the shared path as basis for the search path for the Themes list and to-be-added /t theme option, then this combination of added features may be sufficiently convenient to resolve whatever hassles you may be encountering. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #6 from fatihbakal7@protonmail.com --- (In reply to Stian Low from comment #3)
(In reply to fatihbakal7 from comment #0)
It's just way too much of a hassle to set a theme up to each prefix.
winecfg supports setting version via command line: winecfg /v win10
winecfg also handles setting themes but does not provide a command line option.
Would a command line option such as the following resolve hassles?
Such as: WINEPREFIX=/bogus/pfx_0 winecfg /t aero WINEPREFIX=/bogus/pfx_1 winecfg /t aero WINEPREFIX=/bogus/pfx_2 winecfg /t aero_dark
I'd still have to run it for each prefix. Most people including me have their games in seperate prefixes (All should use the same theme somehow either by reading the theme file from somewhere or via an env var e.g. WINETHEME=/path/to/.msstyles/.reg/.theme/file -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #7 from Stian Low <wineryyyyy@gmail.com> --- (In reply to fatihbakal7 from comment #6)
I'd still have to run it for each prefix. Most people including me have their games in seperate prefixes (All should use the same theme somehow either by reading the theme file from somewhere or via an env var e.g. WINETHEME=/path/to/.msstyles/.reg/.theme/file
winecfg may be called prior to launching games to set version, themes, etc such as for example done for notepad via: WINEPREFIX=~/.wine_pfx_0 wine winecfg /v win10 ; WINEPREFIX=~/.wine_pfx_0 wine notepad winecfg is suggested because it already handles themes just without command line conveniences which could be added. Would this be insufficiently less inconvenient? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #8 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #7)
(In reply to fatihbakal7 from comment #6) WINEPREFIX=~/.wine_pfx_0 wine winecfg /v win10 ; WINEPREFIX=~/.wine_pfx_0 wine notepad
Running with semi-colon after winecfg behaves from user convenience perspective as if just another env var such as WINETHEME. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #9 from Stian Low <wineryyyyy@gmail.com> --- Without WINEPREFIX redundancy: { export WINEPREFIX=~/.wine_pfx_0 ; wine winecfg /v win10; wine notepad; } winecfg could be added for every wine game call since the time it takes to execute is so negligible. Otherwise it only needs to be run once per prefix. Once the registry is updated, wine does not need to be aware of what would be set for WINETHEME each time because the registry would be updated to the direct path. WINETHEME would only be needed when actually changing the theme. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #10 from fatihbakal7@protonmail.com --- (In reply to Stian Low from comment #9)
Without WINEPREFIX redundancy:
{ export WINEPREFIX=~/.wine_pfx_0 ; wine winecfg /v win10; wine notepad; }
winecfg could be added for every wine game call since the time it takes to execute is so negligible. Otherwise it only needs to be run once per prefix.
TLDR; As long as its consistent/same across all prefixes without user needing to manually do stuff (just like any native application) I don't think anybody cares how it's done considering the current state is just hell -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #11 from fatihbakal7@protonmail.com --- Could somebody involved with the project (merge access) give opinion on the way they'd like for this to be done? (as I said I'm in favor of the ~/.config/wine/.msstyle/reg./.theme . I'd really like to work on this) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #12 from Stian Low <wineryyyyy@gmail.com> --- (In reply to fatihbakal7 from comment #11)
I'm in favor of the ~/.config/wine/.msstyle/reg./.theme . I'd really like to work on this)
Regarding changing default paths, you're likely to get the same answer for: https://gitlab.winehq.org/wine/wine/-/merge_requests/10543 "Given the backwards compatibility issues, it doesn't seem worth the trouble." I have an unpushed branch that extends winecfg with command line theme flags to allow setting arbitrary paths such as: wine winecfg /t "~/.config/wine/.msstyle/reg./.theme" It works but additional theme flags for supporting theme variants such as Color and Size need to be added. If this is considered a better solution I'm willing to finish it or provide the source if you'd like to implement instead. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #13 from Stefan Dösinger <stefan@codeweavers.com> --- Ultimately only Alexandre can make the decision, but I think an extra command line argument to set the theme is a good choice: It allows reusing the winecfg code that sets the registry key and avoids duplicating logic. One thing worth contemplating is what other settings might be useful to expose in a similar way. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #14 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stefan Dösinger from comment #13)
One thing worth contemplating is what other settings might be useful to expose in a similar way.
Agreed. So far my patch only considers extending to support theme settings via command line. Besides additional theme path option, other options for choosing index of theme, color and size variants need to be supported as a minimal solution based on: /programs/winecfg/theme.c: static void do_apply_theme (HWND dialog, int themeIndex, int colorIndex, int sizeIndex) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #15 from fatihbakal7@protonmail.com --- (In reply to Stian Low from comment #12)
(In reply to fatihbakal7 from comment #11)
I'm in favor of the ~/.config/wine/.msstyle/reg./.theme . I'd really like to work on this)
Regarding changing default paths, you're likely to get the same answer for: https://gitlab.winehq.org/wine/wine/-/merge_requests/10543
"Given the backwards compatibility issues, it doesn't seem worth the trouble."
I don't think you realize that he meant that about the xdg PR. We were word on a theme PR by upstream people. The xdg and that theme prs are completely seperate so just keep that in mind. I hope we get some feedback on the theme stuff soon -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #16 from fatihbakal7@protonmail.com --- (In reply to Stian Low from comment #14)
(In reply to Stefan Dösinger from comment #13)
One thing worth contemplating is what other settings might be useful to expose in a similar way.
Agreed. So far my patch only considers extending to support theme settings via command line.
This paired with something like WINEGLOBALTHEME=1 (makes it use the global theme from .config/ would be the way to go imo. Time will tell what Alexandre or other maintainers will be willing to merge. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #17 from Nikolay Sivov <bunglehead@gmail.com> --- I don't think we'll get more variables for such comparatively minor configuration option. Configured theme path is stored in the registry, if you need to resolve unix to windows path we have winepath program for that. So to me it looks like we have everything to script such changes. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #18 from Stian Low <wineryyyyy@gmail.com> --- (In reply to fatihbakal7 from comment #15)
I don't think you realize that he meant that about the xdg PR. We were word on a theme PR by upstream people. The xdg and that theme prs are completely seperate so just keep that in mind. I hope we get some feedback on the theme stuff soon
I realize @julliard's response was for XDG PR but consider it likely to apply regarding hard-coded path changes suggested here. Motive and value of XDG MR was not clarified and path changes suggested here seemed related so I extrapolated based on conclusions there. As @dösinger mentioned, theme handling involves multiple options that are probably better handled via existing winecfg logic extended with additional theme command options vs environment variables to handle various options that may need to be supported. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #19 from fatihbakal7@protonmail.com ---
hard-coded path changes
I said .local/share I meant XDG_DATA_HOME. Isn't by that logic ~/.cache/wine also hardcoded?
Motive and value of XDG MR was not clarified
I think they knew the goal with that clearly so there was no need to explain anything. There's no way they don't know what xdg does/is considering there's already xdg related stuff for Downloads/Documents etc.. so I don't think it would've made any differnece
As @dösinger mentioned, theme handling involves multiple options that are probably better handled via existing winecfg logic extended with additional theme command options vs environment variables to handle various options that may need to be supported.
The command approach will hit the same thing as it is right now. Right now you can just do; WINEPREFIX=/path/to/pfx wine/umu-run regedit /path/to/theme.reg and with that winecfg command pr merged it'd just be WINEPREFIX=/path/to/pfx winecfg /t /path/to/theme.reg/.msstyle/.style The deal is that you'd have to run something once per prefix in both cases. Which most users + launcher (heroic/lutris) developers won't be willing to do. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #20 from Stian Low <wineryyyyy@gmail.com> --- (In reply to fatihbakal7 from comment #19)
I said .local/share I meant XDG_DATA_HOME. Isn't by that logic ~/.cache/wine also hardcoded?
The command approach will hit the same thing as it is right now.
The deal is that you'd have to run something once per prefix in both cases. Which most users + launcher (heroic/lutris) developers won't be willing to do.
Thanks for clarifying the problem assumes users + launcher won't be willing to run extra theme setting commands while launching games. This explains what you consider "too much of a hassle."
I think they knew the goal with that clearly so there was no need to explain anything. There's no way they don't know what xdg does/is considering there's already xdg related stuff for Downloads/Documents etc.. so I don't think it would've made any differnece
As @dösinger mentioned for XDG PR, it wasn't clear what problem you were trying to actually solve other than conform to XDG: And to add an unspoken concern: What exact problem are you solving, and are you sure you are not just replacing it with different issues. As with @sivov recommendation, if devs/users aren't willing to script extra commands considered "too much of a hassle" for convenience then perhaps a proposal to reuse existing ~/.cache may be valid. Although the problem hardly seems that major to not be solved easily via existing available solutions. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #21 from Stian Low <wineryyyyy@gmail.com> --- (In reply to fatihbakal7 from comment #19)
is that you'd have to run something once per prefix in both cases. Which most users + launcher (heroic/lutris) developers won't be willing to do.
Some games run differently depending on the windows versions set as described here: https://bugs.winehq.org/show_bug.cgi?id=44675#c15 Currently I test these version variations by always prefixing game launching command with `winecfg /v win10;` Do users & devs already have to change versions for some game prefixes to run as expected? If so then having to run something extra to set themes per prefix seems the same. Many games work for default win10 but plenty are buggy for win10 and require win8 or earlier to be set which requires changing the version. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #22 from fatihbakal7@protonmail.com ---
Some games run differently depending on the windows versions set as described here: https://bugs.winehq.org/show_bug.cgi?id=44675#c15
I've been gaming on linux for about 6 years now and this is the first time hearing about this. I've played countless of games and sometimes I had to install components like dotnet and what not but even that was pretty rare. (Umu wasn't a thing for most of the those 6 years) That being said there's stuff like umu-fixes which apply changes like these automatically. I know umu is for proton and when a game required a specific fix (e.g. version change or installing a dependency) wine users would have to run it themselves anyways (I don't think there's something like umu-protonfixes (https://github.com/Open-Wine-Components/umu-protonfixes) that auto apply fixes for games for plain wine so I don't think I'm wrong on this. A theme isn't exactly a fix so both users of wine & proton would have to run that manually per prefix. Which I believe is enough to justify this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #23 from Stian Low <wineryyyyy@gmail.com> --- (In reply to fatihbakal7 from comment #22)
Some games run differently depending on the windows versions set as described here: https://bugs.winehq.org/show_bug.cgi?id=44675#c15
I've been gaming on linux for about 6 years now and this is the first time hearing about this. I've played countless of games and sometimes I had to install components like dotnet and what not but even that was pretty rare. (Umu wasn't a thing for most of the those 6 years)
That being said there's stuff like umu-fixes which apply changes like these automatically. I know umu is for proton and when a game required a specific fix (e.g. version change or installing a dependency) wine users would have to run it themselves anyways (I don't think there's something like umu-protonfixes (https://github.com/Open-Wine-Components/umu-protonfixes) that auto apply fixes for games for plain wine so I don't think I'm wrong on this.
A theme isn't exactly a fix so both users of wine & proton would have to run that manually per prefix. Which I believe is enough to justify this.
Thanks for more background on your gaming experience. Does this mean you typically use Steam app to manage and launch games? My experience is oriented around dev/testing vs player with plain vanilla wine always the primary target platform. I use GE-Proton without Steam for testing Steam-like behavior when necessary but run via command line like vanilla wine. Therefore if users are dependent upon launchers for managing themes then indeed it may be less convenient for them to have to set for every game if a global theme setting is not offered by their tools. In that case a shared path such as ~/.cache may provide a valid solution. Unclear if global theme override would conflict with any game prefix specific settings such as if similar support was added for global version override that conflicts with game specific version and how that should be resolved. I'm not aware of Proton setting any specific themes per game prefix so maybe other's have more insight into whether that might be an issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #24 from fatihbakal7@protonmail.com ---
Does this mean you typically use Steam app to manage and launch games?
Sorta? I use heroic games launcher most of the time and sometimes steam.
My experience is oriented around dev/testing vs player with plain vanilla wine always the primary target platform. I use GE-Proton without Steam for testing Steam-like behavior when necessary but run via command line like vanilla wine.
I use ge-proton with heroic games launcher
Therefore if users are dependent upon launchers for managing themes then indeed it may be less convenient for them to have to set for every game if a global theme setting is not offered by their tools. In that case a shared path such as ~/.cache may provide a valid solution.
Everything you say makes sense here until the last part. Who ever stored themes in .cache??
Unclear if global theme override would conflict with any game prefix specific settings such as if similar support was added for global version override that conflicts with game specific version and how that should be resolved.
I mean it'd just be a .reg/.msstyle/.theme file that will be imported and I don't think that can break things. Even if it did it wouldn't be groundbreaking.
I'm not aware of Proton setting any specific themes per game prefix so maybe other's have more insight into whether that might be an issue.
They all use the default theme just like wine. And just like wine you gotta set it yourself to each prefix. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #25 from Stian Low <wineryyyyy@gmail.com> --- (In reply to fatihbakal7 from comment #24)
Everything you say makes sense here until the last part. Who ever stored themes in .cache??
~/.cache meant as arbitrary example based on existing directory where wine may dump files and not meant to suggest it as an actual path to be used: /home/any/.cache/wine: -rw-rw-r-- 1 any any 53M May 12 09:05 wine-gecko-2.47.4-x86.msi -rw-rw-r-- 1 any any 82M Oct 14 2025 wine-mono-10.2.0-x86.msi -rw-rw-r-- 1 any any 82M Nov 4 2025 wine-mono-10.3.0-x86.msi -rw-rw-r-- 1 any any 82M Dec 4 05:15 wine-mono-10.4.0-x86.msi -rw-rw-r-- 1 any any 83M Mar 13 05:33 wine-mono-11.0.0-x86.msi -rw-rw-r-- 1 any any 80M May 6 15:57 wine-mono-11.1.0-x86.msi -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #26 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stefan Dösinger from comment #2)
The best solution to easily changeable themes would be a default theme that manages to follow the system gtk/qt/macos theme, but as you observed, it isn't easy to do. I tried to go a little step into this direction by cleaning up the color management in light.msstyles, but Windows theming is awful (MR 7590).
Partly based on @dösinger response: Is replacing default .msstyle files considered too difficult for various 3rd party wine wrapper tools/launchers? This seems to be the simplest global backwards-compatible solution. Other than possible file differences across wine wrappers/launchers, it should just be a matter of locating the default .msstyles files and replacing them with whatever you prefer as the global basis to be copied each time a new prefix created. For example for GE-Proton10-32, replace these files: ./GE-Proton10-32/files/lib/wine/i386-windows/light.msstyles ./GE-Proton10-32/files/lib/wine/x86_64-windows/light.msstyles For wine 11.8, I built with Aero theme enabled which seems default so I had to replace these files: ./wine-11.8-install/lib/wine/i386-windows/aero.msstyles ./wine-11.8-install/lib/wine/x86_64-windows/aero.msstyles This is already supported and does not require any of those launchers to be rebuilt to support this method of global theme setting. So far it seems to be a simple file search and replace solution to the install paths. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59739 --- Comment #27 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #26)
Is replacing default .msstyle files considered too difficult for various 3rd party wine wrapper tools/launchers?
Downside would be potentially having to replace these files each time for versions change/upgrades. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla