compatibility layer between UT and other OSes
-
P.S.: Here is an example of a Plasma-Mobile app running via flatpack on SailfishOS:
https://youtu.be/N7LFPw9Z2aMSomething like that really isn't too different from doing it on UT, at least in theory
Edit: And Angelfish on UT would also be nice. IMHO as nice as Morph is, joining efforts with Angelfish would be better.
-
I think it's very possible to have normal linux apps on UT with a few caveat. As mentioned, upgrading Qt version would make KDE apps generally work. Completing the transition to wayland/xwyaland would make most linux apps work and rebasing to 20.04 would make the compatibility with latest versions of apps a lot better. However, the way of installing may be challenging. Using libertine would be the simplest way but obviously it has limitations since it's just a container. An ideal way would be to repackage them as click. However, using UT-specific APIs such as media hub and content hub will of course be something that has to intentionally implemented in the apps. There are many unconfined apps in the store anyway so as long as they are tagged as such then I don't see problems with traditional apps being unconfined on UT.
But of course, the best would be to support flatpaks/snaps.
-
Maybe as a start some developers could convert their unused Nexus5 to PostmarketOS with Flatpack and Plasma Mobile?
Both seem to work reasonably well on the Nexus5 and could make a good test ground:
https://wiki.postmarketos.org/wiki/Google_Nexus_5_(lg-hammerhead)
(I think I'll convert my Nexus5 in the coming days, as I can still run UT on one of my other devices). But I am sadly not a OS developer. But if anyone needs some testing of cross compatible apps etc., let me know
-
@poVoq
I don't see what is the problem with another "libertine" or "anbox"...our problem with them is the lack of develop in supporting these systems but, if developed, they could result in lightweight systems able to support apps (integrated with the OS) without have to emulate an entire OS.
For what I understand from the Q&A answers, having the same mediahub/content hub on other OSes is exactly what is nearly impossible until great changes in those distros. The other way around is also near impossible due to access and read/write policy restrictions on UT (and this will not change) and the same mediahub/content hub problem.
As said by the UBPTeam in the Q&A the adoption of an "Universal" packaging system like Snap or Flatpak can solve some of the main problems but you will obtain usually only an executable application unable to work because of the different media/content hubs access policy etc.it is not necessarily to create another compatibility layer on UT, in fact in my opinion it is better a layer on other OSes to allow them to use UT apps; this because the UT apps are already more "confined" (no write access on the system image). Also, at the moment, this option would be the only win-win solution: UT obtains more interest from developers (support a single system to support many others) and the other systems obtain the access to the currently more extended linux app ecosystem for smartphone. MyTwoCents
-
Well, flatpak will just work at some point in the future. Other things may or may not. Heck, you can already theoretically use flatpak or appimages on some devices today. It's just there isn't a trivial and integrated way to do it in the system, because it's not a priority.
-
@kugiigi said in compatibility layer between UT and other OSes:
However, using UT-specific APIs such as media hub and content hub will of course be something that has to intentionally implemented in the apps.
Not necessarily. With media-hub for example, I think anything using QtMultimedia goes through it. With content-hub, we'll likely need to do something with xdg-portals for flatpaks to be able to use it. (We also need to change how some things work anyway, so they will work properly on Wayland, as the don't currently.)
-
@dobey given what was said in the Q&A87 (from 41:06, and precisely at 44:13) the flatpak or snap or appimages adoption will solve many problems but not all of them.
so how can what you say be reconciled with what they said? are you talking about of different (ie) flatpak integrations (so a flatpack "manager" for UT, another adapted to plasmamobile another for postmarket etc) so to "translate" generic flatpak app's content hub and resources calls in order to adhere to the specific OSes policies?
Imho, if possible, this would be an even better solution. -
@poVoq said in compatibility layer between UT and other OSes:
Last but not least Open-Store could be expanded to other system, as currently there isn't really a Playstore like 3rd party app distribution model on those. At least for Plasma Mobile it should be easy to get the open-store app running.
this sounds like an interesting idea. and maybe this wouldn't be too hard. the open-store is basically a service where packaged apps are distributed.
Developers can create an account, upload an app, specify which OS it's for (15.04, 16.04, armhf, arm64), describe it, do changelog and updates and get some installation stats. I think it also has a rating system for users since a little while.
Mobile OS' can inquire the list of apps compatible with itself are in the store and updates for installed apps and download and install stuff.
I don't even think that too much of this infrastructure is UT or click specific. Some pieces are of course, like the app submission to the store does a click review and for apps in the store it shows some apparmor click permissions, etc. Also the graphical design on the open-store website is UT specific. But it feels like this is the sugar on top of the machine that makes open-store.
Maybe it wouldn't be too hard to add another OS like plasma mobile to the list and then someone has to teach plasma to get app packages from there. Whatever format pm uses ... debs? or flatpak? If Open-Store learns flatpak that way, this might also be a nice option for UT at some point in the future.
Then you have One store where mobile linux app developers mingle with their apps. Initially it would be separate camps who only develop their apps for this OS or that OS, but it gives the devs exposure to each other. Some apps have already been ported to multiple OS' .... some navigation app ... the name escapes me. If the devs then are all mingling in the same pond, they might learn tricks about porting from one OS to another.
It would still bring a multiplication of work and complexity to the open-store code/infrastructure/team, so that would weigh against it, but I find it an interesting idea! At least the name Open-Store itself would definitely still work, so no branding problem
-
I think the biggest hassle in the short run is neither packaging nor the store, but the QML framework and System Integration. It is not too hard to have different packaging configurations in your repo and deploy to different stores.
Pure Maps by @rinigus is a great example on how platform independent mobile linux apps can be done. The most interesting part is the platform abstraction in QML, in my opinion. The app assumes some QML files in a folder called platform, which is just an imaginary interface to Elements like a Button, a Dialog, Clipboard or file chooser (aka Content Hub in UT). Adding support to another platform means to create a new platform folder and implement the interface using the specific platform frameworks stuff. The packager then just links the desired platform folder to platform and builds the app.
Now you may wonder whether it is necessary for each and every app developer to implement each platform support over and over again. And of course it is not. That could be done in one place shared by all apps. Someone has already started that meta-framework-project as a spin-off from Pure Maps, which just needs to be explored and picked up by app developers.
Sure, this won't solve all problems like (push) notification and background services. But it should help a majority of all apps to become available on many platforms.
-
@Aury88 Right. We need to get some more features implemented so that things work better on Wayland in general, and so we can bridge things like permissions prompts and content hub to work appropriately when flatpak apps request things. There will likely still be plenty of sticking points though.
