That red box is regarding map labels selection, not really locale as of GUI. Note that you could set some better Qt style which will show these items in dropboxes (no idea why default sucks so much)
- if you have KDE platform with Qt 5.12 installed in home (--user)
- all apps using this platform will share Qt libs and all libs in the platform
- the libs bundled with the apps (like some ones required for specific action by that app) will not be shared between apps
In this respect, it the same for us now. All libs bundled with the apps don't share RAM even if they are the same.
So, we get an overhead of loading platform libs to RAM, but we can minimize it by using the same runtime as much as we can.
However, the discussion in that linked issue is interesting for getting info on Flatpak internals.
So, we get an overhead of loading platform libs to RAM, but we can minimize it by using the same runtime as much as we can.
I can get some background about what I have found so far about the on-disk space using of Flatpaks to complement the data about RAM usage.
For that it's important to note, how Flatpaks & runtimes are actually stored - in a single shared OSTree repo. OSTree provides some key benefits for flatpaks:
git like per app & per runtime repo
differential updates (only changes from previous version are transferred on update)
automatic deduplication of everything in the repo
Especially the last point is pretty important and should be stressed. Thanks to this, you can have say 5 versions of the KDE (or any other) installed, but it will not consume much less than 5 full copies (basically size of all the shared bits + all the individual differences).
The same thing is true for applications - everything is automatically deduplicated against everything else. So if two apps bundle the same thing, say libfoo built the same way, resulting in the same binaries or say some bitmap files - there will always be just a single copy stored for all the apps.
To summarize - thanks to its innovative storage layout even with the need for runtimes when compared to "normal" packages, Flatpak is pretty efficient in both storage of runtimes and apps as well as for runtime and app updates.
Many of these things are simply not possible or pretty hard to do just with regular RPM (easy parallel installation & automatic deduplication).
Also - HUGE thanks to rinigus for working on this - you are really a hero!
I was secretly hoping Jolla would pick this up as the main native app distribution mechanism given that it fixes many many of the problems of the current platform and store (such as the App version and system version of Qt being the same, turning Qt updates into a tricky and ornerous process). But this is also a way.
Fingers crossed that this time they they will give priority to any changes needed in the regular Sailfish OS for full Flatpak support, so that Sailfish OS users on as many devices as possible can use it.
@MartinK: thanks a lot for the background. I am sure we will be able to get it working on all devices or at least on the updated ones. Right now I am focusing on getting the keyboard working, then would have to polish different aspects and when its end-user usable, get it supported on wide range of devices.
If done well, I am sure Jolla will see the benefit in it. But we don't have to rely on them and let it out as much as we could through community.
very promising at all! i am not able to run the plasma browser, may be i forgot something?
Probably.
Its not ready yet for general use. Making good progress with the keyboard (can already trigger SFOS one from Flatpak app), but need to polish keyboard-app communication further. When ready, will have to see how to properly incorporate that into the platform.
I have just released new flatpak runner with Sailfish keyboard support. The keyboard required
Having DBus service running in P2P mode for communication of Sailfish application rotation and activity state
Modified Maliit Qt plugin inside Flatpak container to trigger keyboard and rotate it
It could still have some issues with the keyboard, but those could be resolved later. I presume it should also work with the hardware keyboard device as it should be configured on Maliit server side (residing on SFOS).
So, right now we can use QML/Qt apps with the keyboard. Keyboard follows application screen orientation, hides when you switch away from it, can be used to enter chars.
