Improve Flatpak version
Closed, ResolvedPublic

Description

There is a somewhat working Flatpak build, but there are a number of issues.

Flatpak was likely not designed with complex, multi-process things like KDE Connect in mind, so this can be challenging.

  • The indicator does not seem to show up. Do we need to whitelist some DBus path for this? There is some discussion about a StatusNotifier portal (https://github.com/flatpak/xdg-desktop-portal/issues/266), but it seems stuck.
  • Should we launch kdeconnect-app instead of kdeconnect-indicator by default?
  • receiving files doesn't work. I guess we need to whitelist the downloads folder?
  • Sharing via Purpose doesn't work. It can't find the QML plugin to get the devices list. What we can do is use KApplicationTrader to look for org.kde.kdeconnect.telhandler, check whether that's provided by flatpak and use ApplicationLauncherJob to run that. Advantage of that is that it will magically get the file into the sandbox. It will give the handler device selection instead of the purpose device selection, but better then nothing.
  • Media controls don't seem to work
  • Run command doesn't work and I don't see how that could work since running arbitrary commands defies the sandboxing. Should we just hide it?
apol added a subscriber: apol.Apr 26 2020, 11:51 PM

It could also make sense to use the BackgroundService portal:
https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.Background

Should we launch kdeconnect-app instead of kdeconnect-indicator by default?

I'd say we probably want both? one to integrate with the service and the other to launch the app. We don't want the app running all the time.

Media controls don't seem to work

Should be a matter of exporting mpris.

Run command doesn't work and I don't see how that could work since running arbitrary commands defies the sandboxing. Should we just hide it?

You can use flatpak-spawn --host $COMMAND as long as you're enabling --talk-name=org.freedesktop.Flatpak. Then any command will be ran in the host system.

It's something that we don't generally do but it's exactly what the Run Command wants.

justinzobel closed this task as Resolved.Feb 8 2024, 12:24 AM
justinzobel claimed this task.
justinzobel added a subscriber: justinzobel.

Moved to GitLab issue https://invent.kde.org/teams/flathub/issues/-/issues/23 as it's more visible than an old Phabricator issue.