The original plan for kube background sync and multi-instance support was as follows:

• Support opening an arbitrary number of kube clients, sharing the same resources
• Have a dedicated application for background sync (and possibly notificatiosn) that integrates into e.g. the systray.

This plan is however somewhat conflicting with flatpak and the systray slowly going away (not sure if this is really going to happen but there seems to be a trend: https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/).

So:

• With flatpak we can't have multiple kube instances share the same lmdb database due to the no-longer unique pid
• The model where kube spawns synchronizers that are then shared with other kube instances is a little weird with flatpak (might still work though), because the processes will end up being scattered across different sandboxes.
• The same applies to the background synchronizer, which would again have a different lifetime than the other processes

A different model that could work better with the given constraints could be the following:

• Make Kube a single instance application (either we don't support secondary windows at all, or launch different windows from the same "launcher" process withing the same flatpak).
• Allow kube to go to background by closing it's main window, so it acts as background synchronizer process as well (that seems to be the suggested alternative to the systray, and then just use notifications for interaction with the system).

This approach might also be more in line with what is expected on macos and windows.

This is a solution that assumes that kube is the only client interacting with the system, and goes against the initial plan for 3rd party integrations (e.g. plasma applets etc), for that part we'd still have to find a solution for the flatpak/lmdb pid conflict.