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

[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.

[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.

[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.

[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?

[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.

[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..

[ssokolow]

There is a need going forwards for a library neutral theme system..

Agreed. It probably wouldn't fix every reason I'm trying to find alternatives to GTK 3.x apps (There are limits to how much of the GNOME HIG can be undone by a theme), but it'd certainly help to restore what Lubuntu achieved in the GTK 2.x era by writing a theme I found acceptably non-GNOME-ish for GTK+ 2.x and then using QGtkStyle to share it with Qt.

[curfew]

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

No, I was responding to your claim that Flatpak versions of GTK and Qt themes somehow aren't same as non-Flatpak versions of GTK and Qt themes.

[mppix]

No, I was responding to your claim that Flatpak versions of GTK and Qt themes somehow aren't same as non-Flatpak versions of GTK and Qt themes.

Not really. I did say that flatpak handles theming somewhat different with link and showing that apps may look different on flatpak vs native.
Sometimes I think that conversations here could gain a lot if we read posts from others with reasonable care.

[mppix]

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..

+1
Not breaking apps and have them reasonably conform is likely the best that can be achieved until some uniform UI tech comes along. I am not too optimistic about the latter.