KDE Support For Flatpak Portals Progressing

[phoronix]

Phoronix: KDE Support For Flatpak Portals Progressing

While GNOME / Red Hat developers have been leading the Flatpak app sandboxing initiative, KDE developers are making progress too with embracing Flatpak as a more convenient and secure way of securely packaging Linux desktop apps...

http://www.phoronix.com/scan.php?page=news_item&px=KDE-Flatpak-Portals-Progress

[darkbasic]

Now KDE should just stop making a mess of Wayland protocol extensions. They already admitted it will compromise security.

Source please.

[Sesivany]

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

Jan is then RH/KDE because he also works for Red Hat. Red Hat also contributes to Qt/KDE.

[rtfazeberdee]

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

Now KDE should just stop making a mess of Wayland protocol extensions. They already admitted it will compromise security.

I see playschool has finished for the day.

[Awesomeness]

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

“Copyright © 2016 Red Hat, Inc”

https://github.com/grulja/flatpak-platform-plugin/blob/master/src/qflatpakmain.cpp

🤷

[bug77]

How is a desktop environment tied to the packaging of an application?

[Michael]

How is a desktop environment tied to the packaging of an application?

Did you read the article? "Via Flatpak Portals, apps can access the file chooser, app chooser, printers, display notifications, etc. Of course, many of those items are rather desktop-specific if wanting to offer an integrated UI experience, so Grulich has been leading the charge on the KDE support."

[M@yeulC]

Did you read the article? "Via Flatpak Portals, apps can access the file chooser, app chooser, printers, display notifications, etc. Of course, many of those items are rather desktop-specific if wanting to offer an integrated UI experience, so Grulich has been leading the charge on the KDE support."

I would even go further in that this cooperation from the DE (or at least some external component, in theory it could be a command-line one) is required to escape the sandbox. But yeah, that was explained in both the article and the blog post.

What I didn't get in the blog post, however, is that:

For gtk implementation you need xdg-desktop-portal-gtk and for KDE/Qt implementation you need xdg-desktop-portal-kde.

Does it mean that you can use either (and have the related native control), or do you have to install both?
I hope it's the former, and that they use the same d-bus names.

[quikee]

Does it mean that you can use either (and have the related native control), or do you have to install both?
I hope it's the former, and that they use the same d-bus names.

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

[bug77]

Did you read the article? "Via Flatpak Portals, apps can access the file chooser, app chooser, printers, display notifications, etc. Of course, many of those items are rather desktop-specific if wanting to offer an integrated UI experience, so Grulich has been leading the charge on the KDE support."

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