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

[ssokolow]

The reality is that is not true. All 4(wxGTK,wxQT,wxMotif,wxX11) are packaged for arch and gentoo based Linux distributions. If you have only tested with wxGTK on Linux you really should be using the wxWidget option to force particular back-end so a possible future change on your target distribution cannot get you. There are a handful of applications that are arch packaged that do in fact need wxQT or wxMotif and will not function correctly with wxGTK.

wxWidgets multi backend options brings it own forms of theming headaches and its own particular nasty trap. Yes you would have missed including code so the program errors out if the right wxWidget backend is not present.

Huh. Learn something new every day. I guess it's a good thing Audacity is the only wxWidgets app I have installed and I almost never use it.

[mppix]

This doesn't happen on classic Linux desktops because the libraries are shared. Not sure about those pesky flatpaks and snapchats and whatevers, though.

Flatpak has desktop integration and decides what application toolkit (Electron, GTK, Qt) to use
https://docs.flatpak.org/en/latest/d...tegration.html
In fact, theming of flatpak apps (except proprietary) tends to be pretty good/unified.
However, apps can still use different libraries.

No clue about snap (.. and don't care enough to check ).


Edit: out of curiosity, I installed picard from debian repos and flatpack:
--> flatpack follows system-wide dark theme; the native installed client does not (even with preference set to use system-wide theme)!
I would upload a screenshot but seem to be "not authorized to upload attachments".

Anyhow, this is quite interesting; anyone concerned with theming might want to try installing as many apps from flatpak as possible

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