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

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

[curfew]

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.

Obviously we cannot read each others minds. Only the text that we (you) write. So take more care in writing out your exact thoughts and don't use vague language.

I think the "differences" mentioned in the article referred to problems arising from the app using library version A and themes being designed for version B. This usually happens when a feature is added in a later version, the theme is then designed for this version and feature, but the app is bundling an older version and the feature doesn't exist. Someone actually already pointed out this problem in this thread earlier.

Another example might be dynamically generated theming, which is AFAIK what KDE does in order to adapt GTK apps. Change some color setting in KDE and it will regenerate the GTK stylesheets etc. This might not be possible on Flatpak. I already pointed out myself that Flatpak can only break things, it cannot fix things.

[dragon321]

Because not all developers come from the same place. I actually prefer CSD, but I don't have the power to control other people's mind (yet).

I don't care if it's optional or not, this looks like sh*t and unless you intentionally plan to develop a desktop that looks like sh*t it is a big blocker ↓

I'm not saying that everybody should implement CSD. It should stay optional for every toolkit. What I was saying is that there is another way to solve this problem than simply implementing SSD everywhere. libdecoration sounds like good solution and with additional plugins it should match rest of ecosystem pretty well. There is already work in progress to implement it for SDL2.

Also unless you plan to use only applications that uses only one toolkit you're gonna hit integration issues sooner or later. There are more issues than simply not matching titlebar.