As far as I know we explicitly don't support "Breeze" style, only "Fusion", so that part of the report is kind of "expected behavior".

But about the color theme I'm not very sure. Krita has its own themes. The user can choose the one works best for him/her. What exactly is the problem?

(In reply to Dmitry Kazakov from comment #1)
> As far as I know we explicitly don't support "Breeze" style, only "Fusion",
> so that part of the report is kind of "expected behavior".

Then consider this a request to change that, because it should support any theme like any other Qt application does. However, if that is best suited to a separate issue, I'm willing to file that.

> But about the color theme I'm not very sure. Krita has its own themes. The
> user can choose the one works best for him/her. What exactly is the problem?

That it neither supports any colour scheme that isn't in the predefined list (an issue similar to the aforementioned) nor supports switching between the *supported* themes based upon whether they have been chosen system-wise. For instance, if I install Krita whilst using Breeze Dark, although it may initially appear to be following the system-wide colour scheme, it does not, for if I subsequently switch my system theme to Breeze Light, it does not switch.

This is expected when a specific theme has been explicitly set in Krita by the user, but modern versions of Krita distributed outside Steam provide the ability (at the top of the theme context menu) to adhere to the systemwide preference instead of making the user manually switch between them. This is not present for whatever unknown reason in the version distributed via Steam.

Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.

Hi, Roke!

> Then consider this a request to change that, because it should support any theme like any other Qt application does

As far as I remember there used to be bugs if Breeze that caused severe issues with rendering Krita's layers docker and color labels menu. I don't know if anything changed since then... We might check  if something has changed, but I cannot promise.

> but modern versions of Krita distributed outside Steam provide the ability

As far as I know the only means of distribution that supports Breeze (and its themes) is Krita packaged by Linux distributions is a form or 'rpm' or 'deb'. This way of distributing Krita is not officially supported by Krita team, since we need a set of patches for Qt to make painting work properly.

(In reply to Dmitry Kazakov from comment #4)
> As far as I know the only means of distribution that supports Breeze (and
> its themes) is Krita packaged by Linux distributions is a form or 'rpm' or
> 'deb'. This way of distributing Krita is not officially supported by Krita
> team, since we need a set of patches for Qt to make painting work properly.

I wasn't aware of that. Indeed, those are the typed I refer to. However, it appears mighty weird that Linux-first software wouldn't support native package management distribution. Which types are officially supported? And does a separate issue exist for getting official support for such formats?

Hi, Roke!

The Steam package uses the official binary supported by the Krita team, you reported it correctly. Though we don't build breeze support due to bugs we had with breeze some time ago. I'm not sure if these bugs are still present. Perhaps we should reevaluate and/or retest that in the future, though I'm not sure how priority it is.

Created attachment 168997 [details]
https://kojipkgs.fedoraproject.org//packages/krita/5.2.2/7.fc40/x86_64/krita-5.2.2-7.fc40.x86_64.rpm

(In reply to Dmitry Kazakov from comment #6)
Using https://kojipkgs.fedoraproject.org//packages/krita/5.2.2/7.fc40/x86_64/krita-5.2.2-7.fc40.x86_64.rpm, it does appear that you have Breeze support (and, as https://bugs.kde.org/attachment.cgi?id=161857&action=edit demonstrates, dynamic support for installed system themes) in the native package, yet I see no option to automatically switch to the current system theme, like Kate and KDevelop have - the "Default" option.

Created attachment 177947 [details]
Colour Scheme Enumeration in M:8300849784599135186

(In reply to Roke Julian Lockhart Beedell from comment #0)

It's been a long time since I filed this, and it wasn't very well done. I'm going to replace it undermentioned, unless the triage owner would rather I refile it entirely:

SUMMARY
------

In the Steam version of Krita, application styles and colour schemes available in their respective KCMs are not enumerated. This means that platform defaults are not adhered to, even in an entirely first-party environment. In comparison, the native packages achieve this.

STEPS TO REPRODUCE
------------------

1.	Install ≤ [`M:8300849784599135186`][2]:

	~~~sh
	#!/usr/bin/env sh
	steam "steam://install/280680"
	~~~

2.	*When complete*, invoke it:

	~~~sh
	#!/usr/bin/env sh
	steam "steam://rungameid/280680"
	~~~

3.	In the menu bar, select "Settings", then:

	- "Themes"
	- "Styles"

4.	Do the same in `krita-5.2.6-2.fc41.x86_64`, to compare.

EXPECTED RESULT
---------------

The Steam version should enumerate the colour schemes and application styles installed system-wide (available via `kcm_colors` and `kcm_style`).

OBSERVED RESULT
---------------

The Steam version does not enumerate the installed colour schemes nor application styles, thus defaulting to Fusion, despite the DE-wide (and, in fact, KDE-wide, amongst alternative OSes, like Windows) default being Breeze.

1. https://krita-artists.org/uploads/default/original/3X/8/a/8a9deef88c466526cd440fc60139a9612b77b267.png
2. https://krita-artists.org/uploads/default/original/3X/c/c/cc3921a4f2d4429af55dc31c2329b2afa2fd4ec9.png

It *does* act as expected in the Fedora 41 RPM:

1. https://krita-artists.org/uploads/default/original/3X/7/1/71fe433dfb4f585e02c23e020ee560c102e0207f.png
2. https://krita-artists.org/uploads/default/original/3X/c/c/cc3921a4f2d4429af55dc31c2329b2afa2fd4ec9.png

I shall attach these images when this has been posted.

SOFTWARE/OS VERSIONS
--------------------

1.	~~~sh
	#!/usr/bin/env sh
	kinfo
	~~~

2.	> ~~~YAML
	> Operating System: Fedora Linux 41
	> KDE Plasma Version: 6.2.5
	> KDE Frameworks Version: 6.10.0
	> Qt Version: 6.8.1
	> Kernel Version: 6.12.11-200.fc41.x86_64 (64-bit)
	> Graphics Platform: Wayland
	> ~~~

ADDITIONAL INFORMATION
----------------------

Most, if not more, of the information provided here is also available at [`krita-artists.org/t/74681/1`][1].

[1]: https://krita-artists.org/t/why-doesn-t-krita-on-steam-adhere-to-the-kcm-colors-colour-scheme/74681/1?u=rokejulianlockhart
[2]: https://steamdb.info/depot/280682/history/?changeid=M:8300849784599135186

Created attachment 177948 [details]
Application Style Enumeration in M:8300849784599135186

Created attachment 177949 [details]
Colour Scheme Enumeration in 5.2.6-2.fc41.x86_64

Created attachment 177950 [details]
Application Style Enumeration in 5.2.6-2.fc41.x86_64

Appimage version also doesn't seem to show default theme option and breeze.

Are you able to provide a screenshot and version?

Created attachment 186257 [details]
Colour Scheme Enumeration In 5.2.13 (Git 6d3651a)

Comment on attachment 186257 [details]
Colour Scheme Enumeration In 5.2.13 (Git 6d3651a)

That appears to demonstrate that it works. Is that from the AppImage?

(In reply to Roke Julian Lockhart Beedell from comment #15)
> Comment on attachment 186257 [details]
> Colour Scheme Enumeration In 5.2.13 (Git 6d3651a)
> 
> That appears to demonstrate that it works. Is that from the AppImage?

Yes, that is appimage. But that bug was about not appearing windows color scheme default which match with already set system theme. Something like in Kate

Created attachment 186261 [details]
Working default color scheme in Kate which set theme identical to that in system.

(In reply to Marek Mariusz Marecki from comment #16)

> Yes, that is appimage. But that bug was about not appearing windows color
> scheme default which match with already set system theme. Something like in
> Kate

Thanks; indeed. In retrospect, I may have conflated the two issues:

1. It doesn't provide a “Default” option, as its unsandboxed counterparts do.

2. It doesn't enumerate non-statically-linked alternatives.

I've updated the title to reflect this, but this should be two, separate issues...

We do allow breeze to be selected:

KisApplication.cpp

#if (QT_VERSION < QT_VERSION_CHECK(6, 0, 0))
        QStringList styles = QStringList() << "haiku" << "macintosh" << "breeze" << "fusion";
#else
        QStringList styles = QStringList() << "haiku" << "macos" << "breeze" << "fusion";
#endif


However, the appimage version of krita cannot load system-wide Qt plugins. This is a technical limitation that cannot be worked around: Qt plugins need to be built with the version of Qt that is being used for the binary, and the version of Qt in the appimage is guaranteed not to be the exact same as the system version of Qt.

Breeze needs these dependencies:

        CoreAddons
        ColorScheme
        Config
        GuiAddons
        I18n
        IconThemes
        WindowSystem

We currently build and package

        Config
        WidgetsAddons
        Completion
        CoreAddons
        GuiAddons
        I18n
        ItemModels
        ItemViews
        WindowSystem

So we'd also have to package IconThemes and ColorScheme. I haven't looked into what those two needs. But adding the breeze qstyle plugin is not going to be all that trivial.

Does Steam's runtime sandbox suffer from the same deficiencies?

The Steam linux package _is_ the appimage. And it's not a deficiency, it's a technical limitation. You cannot load plugins that link to a different version of a library than the one your application links to. The only solution is to package the plugins, but we're already building and packaging more things than is maintainable.

Perhaps, I'd be better off requesting that the Steam version not be an AppImage, then?

No, that's impossible. For Steam we still need to package all needed libraries because there is no base we can build against.

Arch repo version doesn't work also.

We're not repsonsible for that... I think we'll have to close this request, it's simply technically impossible to have two different versions of the same library loaded in a single process.

Could you at least list these caveats at the relevant listings' descriptions? I don't submitting a documentation MR if someone can point me to where the Steam package gets its description from. (I didn't expect to pay for a crippled version of it, even if I did primarily donate to assist development.)

(In reply to Marek Mariusz Marecki from comment #24)

> Arch repo version doesn't work also.

If you file a downstream bug (you should), please link it here.

(In reply to Roke Julian Lockhart Beedell from comment #27)
> (In reply to Marek Mariusz Marecki from comment #24)
> 
> > Arch repo version doesn't work also.
> 
> If you file a downstream bug (you should), please link it here.
Do you mean link to package in repo?
https://archlinux.org/packages/?sort=&q=krita&maintainer=&flagged=

(In reply to Marek Mariusz Marecki from comment #28)
> (In reply to Roke Julian Lockhart Beedell from comment #27)
> > (In reply to Marek Mariusz Marecki from comment #24)
> > 
> > > Arch repo version doesn't work also.
> > 
> > If you file a downstream bug (you should), please link it here.
> Do you mean link to package in repo?
> https://archlinux.org/packages/?sort=&q=krita&maintainer=&flagged=

Bug report webpage is such slowed down that i can't register and report anything.

(In reply to Marek Mariusz Marecki from comment #28)

> Do you mean link to package in repo?

I'm referring to what https://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&oldid=848884#Where_to_open_the_bug:~:text=pkgctl%20repo%20web%20pkgname describes. You should report it to wherever on GitLab Arch now receives such reports. I don't utilise Arch...