Update legacy app framework documentation to be Flatpak-friendly
This is not entirely complete, but it's being posted here for initial feedback.
In particular, there were some questions I built up over the course of making these changes, where the answers impact more updating:
- How should "built-in" applications be changed? How these would be handled in the future seems undecided... I can opt for just removing the references, and then if/when this is more concrete, re-add them back. (Or should the different approaches mentioned in the Mattermost be placed here for discussion purposes?)
- Is app installation tracking still a goal?
- The "Permissions concept design" document is all talking about something that was never implemented. However, it does still feature interesting discussion, so I'm planning on just moving things around to make clear that Flatpak's permissions model was chosen. Would this work, or should it be more severely gutted?
- Does the "application manager" concept still exist? It seems like it's largely eclipsed by portals & misc. other components.
- How do "System Extensions" fit into the new model? They seem to be using the application bundle concept to extend the host system, i.e. not other bundles, but this isn't really something that Flatpak can do?
- How does persisting applications across system restarts fit into the new model? Is this still planned at all?
- Same question for "frozen" applications (faster start-up time than a dead application without using the equivalent background resources).
- Is the state-saving convenience API still planned?
- Are
X-Apertis-keys still a thing?
In some places I did err on the side of removing things, simply because the original information is always in the Git history and can be added back.
I do also plan on completely removing:
- The app bundle specification.
- The structure document.
since these are all essentially covered purely by Flatpak, and the current pages have very little to add that could be kept. However, I did want to mention it here first just in case there's debate on that.
https://phabricator.apertis.org/T7987
Signed-off-by: Ryan Gonzalez ryan.gonzalez@collabora.com