https://bugs.kde.org/show_bug.cgi?id=431223
--- Comment #14 from Christoph Cullmann <cullm...@kde.org> --- (In reply to Aleix Pol from comment #13) > As far as I understand, there's the possibility of providing those as > extensions. Depending on the Sdk as the runtime rather than just the > Platform will give us access to a bigger set of tools. That is ok for many things but will not help Kate. E.g. the build plugin wants to run exactly the cmake/compiler the user has in its path, not the flatpak sdk compiler, that will just break your local compiles. Same for LSP, we need access to the user environment, not some other variants. The integrated terminal and external tools only make sense with proper shell access to the user & system environment, too. > > Regarding executing, there is also the possibility of requesting the > execution of processes outside. This could be explored if you want to > support tools like that. By-passing the sandboxing isn't ideal though. If somebody does that, perfect, but at the moment I think the only reasonable solution is to only package e.g. kwrite but not kate for flatpak. If somebody provides maintainable patches to get this all working, one can still package it again. -- You are receiving this mail because: You are watching all bug changes.
