XWayland 21.1 Release Candidate Offers Split From The X.Org Server

[oiaohm]

True. However in flatpak, apps can coexist that depend on different versions of libraries... I am not sure to what degree that extends to themes but I still have to find incorrect rendering cases.

Flatpak has more than 1 copy of a lot of themes and in different versions of the same theme for different libraries so depending on what flatpak runtime application users depends on what themes the applications sees. I have had a few cases where 1 application was using the same host and another was dropping back to Adwaita both were using different KDE runtimes with flatpak and only one version of the KDE installed runtimes had the matching theme to my host installed. Even so this does not result in unable to be used application.

What flatpak does avoids the worst. The worst being you cannot use X application because the theme you have choosen has caused key buttons/interface bits to pull the disappearing act. This is disappearing act is a high risk with setting a theme in home directory then using homed to move that home directory between systems. Current Qt/Gtk theme systems are not library neutral. There is a need going forwards for a library neutral theme system..

[mppix]

There is more than 1 version of adwaita. New versions of adwaita with old versions of Qt can end up with some incorrect rendering and the reverse is also true. Adwaita with flatpak is bundled with the Qt versions.

Theme issues are in your common themes as well as the exotics.

True. However in flatpak, apps can coexist that depend on different versions of libraries... I am not sure to what degree that extends to themes but I still have to find incorrect rendering cases.

[mppix]

Linked article*

Themes are distributed and managed by wrapping then into Flatpak extensions but they are still the same old themes as before. As I've been trying to say all the time, GTK will only understand its own theming language and Qt will only understand its own theming language, and Flatpak cannot change that.

GTK will therefore ever only consume standard GTK themes and Qt will ever only consume standard Qt themes. Well, in factuality there seems to be no such thing as "Qt theme" in the Flatpak world as the article said that they are in fact KDE styles that are kind of an extended version of a plain Qt style.

.. so what?
Are you suggesting that Qt, GTK, ... apps cannot be styled to be compatible with other styles or different versions of themselves?

[oiaohm]

Yes, this is usually not a problem for common themes, e.g. adwaita, but I'd imagine that can be problematic for exotic themes (did not try).

There is more than 1 version of adwaita. New versions of adwaita with old versions of Qt can end up with some incorrect rendering and the reverse is also true. Adwaita with flatpak is bundled with the Qt versions.

Theme issues are in your common themes as well as the exotics.

[ssokolow]

Well I don't know whether this is limited to Flatpak or if it's something distinct. However, I'm aware that certain apps such as Chromium (?) have the ability to use native filepickers even when they're packaged using classic means.

Chromium does it by checking if it's running under KDE and invoking something like this command:

kdialog --getsavefilename ~ *.html

I turned that off with export NO_CHROME_KDE_FILE_DIALOG=1 because invoking it as a subprocess rather than as a D-Bus call to a persistent dialog host introduces a noticeable latency I didn't like.

[curfew]

Please read the link carefully. Theming is done with flatpak extensions, which is different than theming in native apps.
My testing suggests that this is more consistent than native themes, at least as far as dark/light theming goes. Of course, flatpak does not rewrite apps in a different toolkit...

Linked article*

Themes are distributed and managed by wrapping then into Flatpak extensions but they are still the same old themes as before. As I've been trying to say all the time, GTK will only understand its own theming language and Qt will only understand its own theming language, and Flatpak cannot change that.

GTK will therefore ever only consume standard GTK themes and Qt will ever only consume standard Qt themes. Well, in factuality there seems to be no such thing as "Qt theme" in the Flatpak world as the article said that they are in fact KDE styles that are kind of an extended version of a plain Qt style.

[mppix]

There is something mega horrible but also required, Flatpak is not using the host themes. Instead you install themes from flatpak repository that are close to the host theme.

This is (also) needed because flatpak intentionally does not expose /usr to apps (sandbox).

Yes it would be good to add per application theming with flatpak but that does not change that flatpak intentionally don't use the host theming that could be modified in ways that could break applications.

From link: "The solution to this was to package themes as Flatpaks, as relying upon the host to have the correct version for every flatpak defeats the portability benefits it provides."
In short, native apps and flatpak use distinct theming. Both can fall back to defaults if needed. However, flatpak seems to be more consistent about installing and using the proper themes without extra configuration (at least on debian).

The current GTK, Qt.... themes have to match the libraries we don't have proper generic theming.

Yes, this is usually not a problem for common themes, e.g. adwaita, but I'd imagine that can be problematic for exotic themes (did not try).

[mppix]

What you said here is impossible. The apps are programmed using Qt or GTK or something else and the packacing format cannot change that.

Flatpatk cannot do anything more than what is possible via regular "global filesystem" in a traditional distro installation. Flatpak can only introduce additional restrictions which make unifying the look-and-feel of different toolkits even more complex. This is what I was referring to in my earlier post.

The optimal scenario for Flatpak would be that it doesn't break anything; it also cannot fix anything. (Aside maybe per-app themeability but the docs you linked mention that this is not possible.)

Please read the link carefully. Theming is done with flatpak extensions, which is different than theming in native apps.
My testing suggests that this is more consistent than native themes, at least as far as dark/light theming goes. Of course, flatpak does not rewrite apps in a different toolkit...

[curfew]

It did invent and drive the introduction of the XDG Portals system.

Well I don't know whether this is limited to Flatpak or if it's something distinct. However, I'm aware that certain apps such as Chromium (?) have the ability to use native filepickers even when they're packaged using classic means.

[curfew]

You need to read over the flatpak link again. There is something mega horrible but also required, Flatpak is not using the host themes. Instead you install themes from flatpak repository that are close to the host theme.

Yes it would be good to add per application theming with flatpak but that does not change that flatpak intentionally don't use the host theming that could be modified in ways that could break applications.

I know all this already, but the themes are still exactly the same themes we can install globally in any classic distro. Only packaged in a Flatpak-compatible way.