I currently need feedback as to how to implement a theming improvement to wine. My recommendation is that all prefixes use $HOME/.config/wine.msstyle/.theme if possible. I was told this is the place to ask for feedback. Please see https://gitlab.winehq.org/wine/wine/-/merge_requests/10920
Having read the linked <a href="https://bugs.winehq.org/show_bug.cgi?id=59739">bug #59739</a>, the initial issue seems to be that wine isn't looking for themes outside of it's own prefix, and thus increasing the amount of space each prefix uses due to needing to copy the *same* custom theme data into each newly made prefix. This part is something I'd support fixing, as the prefixes are already too large to begin with. However, the issue seems to slowly suffer from scope creep and become a complaint that custom theming is not automatic across all prefixes. This is something that really should be left alone for a number of reasons. The most obvious being that there is an entire class of UI bugs that break apps as a direct result of the Windows theme being used and various wine-inaccuracies when handing Windows themes. Another reason against automatic custom theming for all prefixes, is that this is something that most 3rd party wrappers / launchers should be able to handle on their own. My own manager could do this with one additional line of code. (A few more if I want to be nice and allow proper checks.) For users that don't configure Wine themselves, (Steam / Proton users, PlayOnLinux, etc.), they aren't configuring this stuff directly anyway. Sure, the 3rd party wrappers may like a simple command line arg / environment variable to change it during prefix creation, and Wine could look into providing a standard way to indicate a choice, (which could be useful for other things like disabling winemenubuilder, enabling the start menu in Virtual Desktop mode, etc.), but we'd still need to have some sort of "safe-mode" that disables it for debugging / bug-reporting / testing / app workaround / etc. purposes. As for vanilla wine users, they'd be better served by having wine's control panel made more visible, better organized, and more feature complete. Maybe have a button that lets them import various "personalized" settings from another prefix? Currently the only easy way to duplicate a prefix config out side of a manager app, is to manually copy an existing prefix warts and all, then strip out what isn't desired. It would be better if Wine had some global settings that could be handled by KDE's System Settings / GNOME's Control Center apps, along with a clear "safe-mode" button that would disable it and that the wiki could refer users to when submitting bug reports / troubleshooting Wine. On 5/15/26 8:08 PM, Fatih Bakal via Wine-Devel wrote:
I currently need feedback as to how to implement a theming improvement to wine. My recommendation is that all prefixes use $HOME/.config/wine.msstyle/.theme if possible. I was told this is the place to ask for feedback.
Please see https://gitlab.winehq.org/wine/wine/-/merge_requests/10920
What I have in mind is for it to behave exactly as is. But if user has put a theme file to $HOME/.config/ it would use that thus making it optional and not breaking anything.
I know some people get crazy when this topic comes up and start going into feature creep, wanting support for different window decorations and having adwaita or other, but just basic dark/light mode automation on the big DE's would go a long way. On Fri, May 15, 2026 at 11:05 PM Fatih Bakal via Wine-Devel < wine-devel@list.winehq.org> wrote:
What I have in mind is for it to behave exactly as is. But if user has put a theme file to $HOME/.config/ it would use that thus making it optional and not breaking anything.
As mentioned in the linked issue, making something default (other than the dark theme setting thats just a boolean) won't probably happen because there is a chance actual theming would cause a bit of breakage across uis of different applications thus should be optional. Also that being said the boolean option alone doesn't make wine built in stuff (explorer control taskmgr..) not go dark theme
If space and duplicated themes is your issue (which is understandable), why not just create a symlink to the theme (directory) yourself in each prefix?
Space isn't my issue at all but would be cool if they all used the same file anyways. My actual issue is that having to do it manually to each prefix. I have around 60 prefixes on just 1 computer (I play a lot of games). And it's really annoying
Am Sonntag, 17. Mai 2026, 15:56:11 Ostafrikanische Zeit schrieb Fatih Bakal via Wine-Devel:
Space isn't my issue at all but would be cool if they all used the same file anyways. My actual issue is that having to do it manually to each prefix. I have around 60 prefixes on just 1 computer (I play a lot of games). And it's really annoying
My concern with anything theme related in Wine is that Wine's theming still needs a lot of love/work. Thanks to the hard work Zhiyi we no longer look like Windows 95, but once you go beyond the default theme things still break a lot. Adding an extra configuration option feels like it makes things even more difficult to maintain. Changing the theme is difficult (try to introduce a different highlight color and you'll see), Applications can break (although some break on Windows too). I don't know how well third party Windows themes work - I haven't tried in ages. Having a Wine prefix wide dark mode would be really nice to have, but is mission impossible at the moment (In part because Microsoft decided to make it difficult for Win32 Common Control based things and de facto requires new WinUI for it) I think third party wine managers are less of an issue for themes than for the merge request to change the default Wine prefix location. Two unrelated things got conflated there.
Considering there's still white ui's in windows 11 and last wine theming related work seems to be ages ago according to what you said i really think there's no point in waiting anymore. That being said I still need a greenlight/approval on the implementation from somebody from upstream (e.g. Alexandre) If an application breaks with a theme the user can open winecfg and make that prefix not use the optional global theme located at $HOME/.config so not that big of a deal. Something like dll overrides where u can override the theme via the .exe name could be done but seems overkill to me (if there's demand for it i'll do it tho)
Typo. I meant to say "Considering there's still white ui's in windows 11 even when dark theme is enabled (e.g. the properties menu lf a file)
Bumping as it's been a week. I'm still waiting on feedback from upstream to start working on this.
For shared themes, you can already achieve your goal by scripting things, e.g., by regedit to set the default theme. However, Wine's builtin aero.msstyles is really the only theme that is good enough. You might use XP themes. However, they sort of break here and there. So I don't see a point maintaining a shared theme mechanism for aero.msstyles only unless we have more working themes, which can be done via adding support for parsing Win7/10 era themes for example. On 5/26/26 04:43, Fatih Bakal via Wine-Devel wrote:
Bumping as it's been a week. I'm still waiting on feedback from upstream to start working on this.
For shared themes, you can already achieve your goal by scripting things, e.g., by regedit to set the default theme.
Again defeats the whole point (idk how id even script it tbh) launchers usually create a new prefix whenever you add in a new game. Most launchers (Heroic & lutris which are the most used ones) seem to be against adding this auto theme change thing. I could make something that's listening for new prefixes 7/24 to apply themes but that's just overkill.
However, they sort of break here and there.
I have a prefix which I have set the theme manually and everything I use (explorer, cheat engine, taskmgr, regedit..) works and looks good.
unless we have more working themes
There is a chance people will start doing more themes focused for wine (https://github.com/listumps/wine_themes) if some sort of global theme option is added. (I sure will)
which can be done via adding support for parsing Win7/10 era themes for example.
Can be done afterwards in my opinion as even when support for that is added the same having to apply it manually issue will still be a thing.
Again defeats the whole point (idk how id even script it tbh) launchers usually create a new prefix whenever you add in a new game. Most launchers (Heroic & lutris which are the most used ones) seem to be against adding this auto theme change thing. I could make something that's listening for new prefixes 7/24 to apply themes but that's just overkill.
If scripting is considered too inconvenient then replacing default (aero) theme for wine/launcher install directory is easier: https://bugs.winehq.org/show_bug.cgi?id=59739#c26 Downside is it only copies themes for new prefixes so old prefixes would still need to be manually replaced, same as for wine/installer. Having to replace wine/installer theme each time between upgrades may also be considered another one-time inconvenience. All recommendations so far seem to require time or skill level considered too inconvenient for end users. Emacs makes file search/replace of themes as trivial as scripting but both are less common among end users. Therefore it seems the level of ease sought is for game launchers to be started with some WINE_THEME_ENVVAR to be applied to each wine call they make to launch games. ENVVAR option has the goal of avoiding having to make changes for each game manually within the launcher which is considered as inconvenient as performing file replacements of themes per existing wine prefixes. Therefore adding an ENVVAR seems to be the clearest option to achieve such a level of ease. If so, is the level of effort worth it compared to existing (maybe less convenient) solutions? I do not know. I need to familiarize myself with launchers because I only use vanilla wine to test games and only involve launchers when bugs are created for them. ENVVAR does seem to offer a universal solution so that each launcher would not require their own custom theme setting conveniences to relieve end users of whatever burden is considered too much.
is the level of effort worth it compared to existing (maybe less convenient) solutions?
Regarding level-of-effort vs time-worthiness: How common/edge-case are Windows themes for games? Many games I've tested do not even show a UI that reflects themes but seem more common for older games. GOG The Witcher for example is fairly old but handles its own rendering even for its launcher. Do you have examples of some games where the theme matters more?
If scripting is considered too inconvenient then replacing default (aero) theme for wine/launcher install directory is easier
I have multiple wine/proton builds for games (latest ge-proton, older ge-proton,default proton, wine). Not to mention whenever launchers update said builds the modification would be lost. Heroic games launcer/lutris/protonplus/protonup-qt all update to latest versions as they should (this is still a hassle as to there will be cases where the wine/proton build will update and the theme file you replaced will be overwritten meaning you gotta do it again)
Do you have examples of some games where the theme matters more?
All wine applications (explorer, taskmgr, regedit) cheat engine, some adobe apps, the file import/export dialogs, all qt apps (the boolean switch for dark theme) What about making it so that it uses whatever is theme inside `~/$USER/.config/wine/` if there is something there. And also an env var WINE_IGNORE_GLOBAL_THEME that can be set to 1 to ignore the theme in `~/$USER/.config/wine/` ? This seems like a reasonable approach to me. I'll start working on it if you guys think it's reasonable as well
I think the approach of referencing a file in ~/$USER/.config may work, with added functionality for ignoring the global being an absolute must, in the event it breaks something for that game/software. perhaps a file added to the prefix that wine checks if exists, and if so then ignores the users .config settings, or an envvar that ignores the users .config settings? frankly, having both options to opt-out of the global theming would be better for compatibility of management tools(launchers/scripts). Adding an envvar to every prefix to opt-in seems time consuming and tedious, at that point you almost might as well change the theme per prefix. common practice is definitely a prefix per software/game. keeps things santised, separated, not conflicting, allows different runners or dependencies to be used for compatibility. A lot of launchers like lutris make a new prefix per game. Other times you end up with small projects(like one of mine) for odd games that really don't like to run right, where we create a prefix via script and have wine versions modularly plugged into the prefix. The latter is definitely a bit dirty, but is fantastic for rapid testing and portability. Certainly it could be changed such that launchers/installer scripts set envvars or files placed in the prefix, but that would leave users at the mercy of their launcher or install method to support it. On Wed, May 27, 2026 at 4:53 AM Stian Low via Wine-Devel < wine-devel@list.winehq.org> wrote:
Again defeats the whole point (idk how id even script it tbh) launchers usually create a new prefix whenever you add in a new game. Most launchers (Heroic & lutris which are the most used ones) seem to be against adding this auto theme change thing. I could make something that's listening for new prefixes 7/24 to apply themes but that's just overkill.
If scripting is considered too inconvenient then replacing default (aero) theme for wine/launcher install directory is easier: https://bugs.winehq.org/show_bug.cgi?id=59739#c26
Downside is it only copies themes for new prefixes so old prefixes would still need to be manually replaced, same as for wine/installer.
Having to replace wine/installer theme each time between upgrades may also be considered another one-time inconvenience.
All recommendations so far seem to require time or skill level considered too inconvenient for end users.
Emacs makes file search/replace of themes as trivial as scripting but both are less common among end users.
Therefore it seems the level of ease sought is for game launchers to be started with some WINE_THEME_ENVVAR to be applied to each wine call they make to launch games. ENVVAR option has the goal of avoiding having to make changes for each game manually within the launcher which is considered as inconvenient as performing file replacements of themes per existing wine prefixes.
Therefore adding an ENVVAR seems to be the clearest option to achieve such a level of ease. If so, is the level of effort worth it compared to existing (maybe less convenient) solutions? I do not know.
I need to familiarize myself with launchers because I only use vanilla wine to test games and only involve launchers when bugs are created for them. ENVVAR does seem to offer a universal solution so that each launcher would not require their own custom theme setting conveniences to relieve end users of whatever burden is considered too much.
participants (7)
-
fatihbakal7＠protonmail.com -
Gabriel Ivăncescu -
Patrick Hibbs -
Stefan Dösinger -
Stian Low -
Ty -
Zhiyi Zhang