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

[curfew]

Flatpak has desktop integration and decides what application toolkit (Electron, GTK, Qt) to use
https://docs.flatpak.org/en/latest/d...tegration.html

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

[ssokolow]

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

It did invent and drive the introduction of the XDG Portals system (Can't remember if that was back when it was called xdg-app or if it came about after the name change), which allows anything using QFileDialog without the non-default DontUseNativeDialog flag or GtkNativeFileChooser to seamlessly pick up your desktop's preferred Open/Save dialogs. (Though, when running outside Flatpak or snappy, GTK requires you to manually set the GTK_USE_PORTALS environment variable.)

[oiaohm]

It did invent and drive the introduction of the XDG Portals system (Can't remember if that was back when it was called xdg-app or if it came about after the name change), which allows anything using QFileDialog without the non-default DontUseNativeDialog flag or GtkNativeFileChooser to seamlessly pick up your desktop's preferred Open/Save dialogs. (Though, when running outside Flatpak or snappy, GTK requires you to manually set the GTK_USE_PORTALS environment variable.)

XDG Portals starts when flatpak was called xdg-app. That kind of why its XDG portals not flatpak portals. If you check the history in the flatpak repository you will see xdg portals files is first commit dated before flatpak as the name for the project exists as well.

[oiaohm]

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.

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.

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

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

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

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

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

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