4 ms·
Flatpak in theory vs flatpak in practice are different things, as you highlight yourself ("...does not use standard file choosers, file APIs, etc."). Suddenly,
by necovek 6y ago
Flatpak in theory vs flatpak in practice are different things, as you highlight yourself ("...does not use standard file choosers, file APIs, etc.").
Suddenly, it's now on app developer to support the packaging system and not the other way around.
- Spivak 6y agoI mean what do you want to have happen? ptrace every application, stop on every openAt(2) call and pop up a permissions dialog? macOS can get away with solutions like this because they control the kernel and userspace but on Linux it’s a much tougher problem.
- orra 6y agoTBF you could put support into the two common GUI toolkits, to defer to a Flatpak portal.
- Spivak 6y agoBut that’s exactly what GTK and QT have! It’s what to do with apps that don’t use some abstraction that supports portals that’s the issue.
- orra 6y agoWell, there’ll always be a long tail. But if you start with the popular apps and frameworks first, you get the most bang for your buck. It wouldn't surprise me however if sandboxing is only a good model for GUI not console app. IIRC the Windows 10X approach will be to put all non-sandboxed apps in the exact same environment.
- AshamedCaptain 6y agoAs mentioned above, Flatpak is already doing the two most popular toolkits. Programs just don't use toolkits to open files. So there is not a lot of "buck" here, and the tail is rather long.
- GekkePrutser 6y agoAnd also because macOS has only one desktop environment :)