KIO + Sandboxed Apps: Making a design
Summary
Notes
- route all access through kio-fuse. kio-fuse could listen to stats. if a stat comes in for what is a url it opens a worker and pronto we have a local file path to a remote resource. this also works through the permissions portal
- mid term the paths of kio-fuse and gvfs should be made to overlap so gnome apps on plasma use kio and kde apps on gnome use gvfs
- long term all access should run through fuse instead of kio directly (possibly even replace kio with gvfs?)
- how to deal with blocking calls? io-uring?
- kio-fuse needs changes to use a stable path
- solid in kio is going to be a problem (kfileplacesmodel, trash and others)
- we need to impl trash portal
- api review
Things that don't make sense in a sandbox
- KIO::RestoreJob (or requires edits)
- KIO::ApplicationLauncher
- would need a portal push
- KMountPoint
- would need to be host backed. This is how gvfs works via a DBus hole
- KProtocolInfo
- would need to be host backed.
- KRecentDocument
- would need portal changes
- KTerminalLauncherJob (same as app launcher)
- KIO::OpenUrlJob (works via QDesktopServices)
- KIO::PreviewJob
- it works... but it's a bit crap. external previewers don't work, and it's harder to sandbox them further from within a sandbox.
- Maybe check GTK.
- KBuildSycoca
- we should kill it
- becomes a plasma problem
- KF7
- KOpenWithDialog
- apps would call OpenUri
- this is a host problem
- KFilePlacesModel
- won't work in sandboxes