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

[ssokolow Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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 Senior Member Find all posts View Profile Close 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.