KDE Support For Flatpak Portals Progressing

[Michael]

So instead of rpm, deb, whatever that is kind of distribution specific, now we get packaging that's DE specific? I gotta read more about this...

No, it's not DE-specific packaging. It's a matter of basically implementing the same APIs for the respective desktop... So when running a Flatpak on KDE, the Qt file chooser will come up rather than opening up a GTK/GNOME file chooser, etc.

[bug77]

No, it's not DE-specific packaging. It's a matter of basically implementing the same APIs for the respective desktop... So when running a Flatpak on KDE, the Qt file chooser will come up rather than opening up a GTK/GNOME file chooser, etc.

Ah, that makes more sense. Gotta read... If I can find the time...

[M@yeulC]

xdg-desktop-portal-gtk and xdg-desktop-portal-kde are backend implementations of the xdg-desktop-portal DBus interfaces - so you will need only one, depending on your DE..

Thanks, this clarifies that. I had trouble completely understanding the aforementioned sentence.

[quikee]

I must say that I don't see why this currently depends on Flatpak (it should be the other way around: Flatpak depending on Portals) - it should work with any container technology (like whatever snaps uses) or even without any containers at all (to not need to code it twice and just use a common API). Or does it depend on Flatpak just because it is distributed that way currently?

[ⲣⲂaggins]

There seem to be three distinct types of sandboxing with varying levels of distro support:

1. Untrusted - a system for bundling untrusted code into a package and running it in isolation - e.g. flatpak, snappy, android apks.
2. Trusted - security profiles to enforce the principle of least privilege in system software - e.g. selinux, apparmor.
3. Ad-hoc - support for creating (possibly nested) environments with a customisable level of isolation - e.g. subuser.

Application sandboxing is currently a major weakness of desktop linux at the moment, with only (2) being in use at all (Fedora, Ubuntu for example, also in chromium). It's good to see (1) and (3) gradually getting there as well, even though proper sandboxing with flatpak is always going to be held back by slow wayland adoption.

Ironically, Arch doesn't allow you to do any of them.

[ssokolow]

It is always nice to see the lesser desktops babystep the road paved by RH/Gnome. Be it Gstreamer, Wayland, Vulkan, Flatpak or packaging.

It is always nice to see the lesser desktops babystep the road paved by KDE. Be it Qt itself (GTK+), DCOP (D-Bus), KIOSlaves (GnomeVFS), KParts (which GNOME botched so badly that they basically gave up), or OpenGL integration (QGraphicsView offered mature support for embedded widgets with input transformation months before GTK+ even had an early proof of concept).

Look, ma. I can do it too!

(Seriously, though, "road paved by" is a very "glass house"-y way to criticize KDE, given that GNOME began as a "with beer and hookers" response to Qt's original non-libre license and has had a long history of having trouble shaking the bugs out of their knock-offs of KDE technologies. It wasn't until around the KDE 4 era that GnomeVFS stopped being crash-happy and D-Bus replaced the CORBA monstrosity they were using to compete with DCOP.)

Now Canonical should just stop making a mess of GTK+ APIs that KDE then has to fix.

FTFY.

Seriously, though. Do you know why so many users force-disable appindicator support in their applications? It's because libindicator forces the context menu to be the primary (left-click) action and most developers don't even realize you can bind "toggle hide/show" as a secondary because Unity maps primary to left and right click, consigning secondary to middle-click.

KStatusNotifierItem fixed it by letting the developer decide and, as a result, people often mistakenly conclude that libindicator is a crippled implementation of an API KDE invented, rather than KStatusNotifierItem coming second and omitting the artificial restriction on what callbacks can be bound to which D-Bus signals.

[Awesomeness]

KStatusNotifierItem fixed it by letting the developer decide and, as a result, people often mistakenly conclude that libindicator is a crippled implementation of an API KDE invented, rather than KStatusNotifierItem coming second and omitting the artificial restriction on what callbacks can be bound to which D-Bus signals.

What the fuck are you talking about? StatusNotifier was invented by KDE and App Indicator came second. Even https://launchpad.net/libappindicator says it right in the description: “Based on KSNI” [KSNI=KStatusNotifierItem]

KDE developer Aurlien Gateau was back then employed by Canonical. He worked on Kubuntu and later the first Qt port of Unity. He was the one who lobbied for SNI adoption in Ubuntu. Because of his role as both KDE developer and Canonical employee, he then connected both teams and there was some cross-pollination on the specifications. IIRC dbusmenu was Canonical's influence.

[ssokolow]

What the fuck are you talking about? StatusNotifier was invented by KDE and App Indicator came second. Even https://launchpad.net/libappindicator says it right in the description: “Based on KSNI” [KSNI=KStatusNotifierItem]

KDE developer Aurlien Gateau was back then employed by Canonical. He worked on Kubuntu and later the first Qt port of Unity. He was the one who lobbied for SNI adoption in Ubuntu. Because of his role as both KDE developer and Canonical employee, he then connected both teams and there was some cross-pollination on the specifications. IIRC dbusmenu was Canonical's influence.

Huh. I stand corrected then. When appindicators first came on the scene, everything I read cast it in a "this is Canonical's creation for Unity" light and then I didn't hear about KStatusNotifierItem until a long time later and, somehow, I never noticed the "based on" part.

...I guess that's one more case of "while I don't like how unapologetically sloppy they get whenever they bump the major version number, KDE continues to innovate in a direction I like."

[TheBlackCat]

It is always nice to see the lesser desktops babystep the road paved by RH/Gnome

It is always nice to see a DE that is willing to work with other DEs rather than re-implementing everything from scratch in their own incompatible way.