Draft: copy host file to flatpak sandbox
This is a draft for discussion only.
Context
From Kate flatpak application, we cannot open some files if they are in blacklisted folders (/lib
, /lib32
, /lib64
, /bin
, /sbin
, /usr
, /boot
, /root
, /tmp
, /etc
, /app
, /run
, /proc
, /sys
, /dev
, /var
).
It's annoying when using "Go to definition" and others LSP features on system symbols because it opens a blank file instead of the wanted system header.
To reproduce this problem, we can create a minimal hello world C++ app :
#include <iostream>
int main() {
std::cout << "hello world" << std::endl;
return 0;
}
When Ctrl+clicking on std::cout
it should open the header file of the host system (/usr/include/c++/10/iostream
on my system).
Beginnings of a solution
There is an interesting command that is available from the flatpak sandbox : flatpak-spawn
. It allows to execute commands in the host from the flatpak sandbox.
Based on this flatpak-spawn
command, this draft shows a hacky solution, just enough to show that it could work.
To test it :
git clone --branch flatpak_playground git@invent.kde.org:remipch/kate.git
cd kate/flatpak_playground
./build_kate_flatpak.sh
./run_kate_flatpak.sh
Questions
- Is it ok to integrate such a solution ?
- Where is the right place to integrate it ? It could be done in the framework to benefit to all applications.
- What are the other limitations of kate flatpak ?
- Side bug : when I run the flatpak, the menus are not ordered correctly, any ideas ?
TODO (if we go further in this direction)
- Use
kcoreaddons/ksandbox.cpp
instead of callingflatpak-spawn
directly - First try to open the file locally, if it fails and if we're sandboxed, then make a local copy.
- Add a filename cache to avoid making several copies of the same file. Something like a
std::map<QUrl host_url, QUrl local_copy_url>
- Integrate cleanly in the right place.