Qt 5.15: what's next?

[rinigus]

With Qt5.15/KF5 project, we are progressing fast in terms of packaging new libraries. Based on the progress so far, we can conclude that, what started as a proof-of-concept, works and it is possible to have Qt 5.15 on our devices. Thus, it is natural to ask what to do next with this.

From SFOS point of view, we are kept behind by proprietary packages. So, one way of approaching this is to replace all proprietary code with the open source alternatives. This includes Silica, SFOS compositor components, email client, accounts handling, keyboard components to name few. This is surely not a small task, but we don’t have to fix it immediately either. Silica apps can run on newer Qt Wayland based compositors as well - not perfect in terms of app background, but possible. So, it is possible to start replacing components one by one if we go for a full revamp.

Another approach would be to bring apps over and try to integrate them better with SFOS. This could include styling in terms of themes (QT_QPA_PLATFORMTHEME) and Kirigami.

The both approaches (revamp and integration) could easily coexists and its up to us, developers, to choose what we prefer to spend our time on.

Coming back to full revamp, if we go for it, we should target full compatibility with Plasma apps. So, we could basically take Plasma app and run it unchanged on SFOS. Same goes for SFOS apps on Plasma. To preserve or to evolve based on SFOS designs, we should style apps accordingly. However, if we compare interactions of Kirigami (used by Plasma) to Silica, it is clear that Kirigami has larger number of them and we would have to make some choices regarding what to map and what to keep as it is. Use Kirigami Gallery demo app at Chum to see what is available. In particular, menus on the left (global) and right (context) have frequently more items that would make sense to add to pulley menus (leaving page actions for them pulley menus?). On the other side, if menus stay as they are, left and right swipe gestures are taken by them an compositor would have avoid using them.

In case of full revamp, compositor is surely something that has to be addressed. Not knowing much about Lipstick (is it simple to port to Qt5.15/Qt6) and Plasma’s KWin, it is hard to choose. Ideally, we should try to reuse as much software where we can share the load with others. So, maybe KWin styling can be considered. KWin has dropped hwcompositor, but patches exist to bring it back.

On Plasma Mobile side, as far as we know, the major gaps are in email and possibly calendar software - something that we have used to have in a rather good quality. As far as I know, we have parts that are open-source and proprietary. So, it maybe of interest for Plasma folks and maybe we can work together on some mix of the solutions.

While working on a strategy, it is important to figure out Jolla’s expectations and plans. We rely on Jolla’s infrastructure and great relations with their developers. Something, that we want to keep and rely upon. How could Jolla benefit from it? What would be the ways for them to ensure that they can sell their products? Unfortunately, Jolla tends to be rather quiet regarding their plans. So, we can either hope that they would open up a bit or we would have to guess the pathways.

On behalf of myself and @piggz.

[ApB]

One question. How easy it would be to break the OS in two. Meaning have a corporate edition which jollas can sell (limited by all the licensing stuff) and a community edition where the devs can go bonkers with it and jolla pull in the corporate edition things they like.

Both can have a common core or packages.

[olf]

@rinigus

[…]
From SFOS point of view, we are kept behind by proprietary packages. So, one way of approaching this is to replace all proprietary code with the open source alternatives. This includes Silica, SFOS compositor components, email client, accounts handling, keyboard components to name few. This is surely not a small task, […]

These goals seems to align very well with the NemoMobile project (sources@GitHub), specifically the Glacier UX (source@GitHub)! A bit of background and user experience is provided in this review from May 2021.

For a proper mail app, I always regretted that the Kontact Touch aka kdepim-mobile project had no sustainable backing and was ultimately killed by Stephen Elop’s “burning platform” take-over. It was based on Kontact as part of KDE 4 applications (as of 2011), using libkdecore5, kdelibs5-data, kdebase-runtime-data, and ran pretty stable on Maemo5-fremantle@N900. Unfortunately I cannot find the source code online any more, but as I triggered this initiative, I can contact the former developers to republish it, if there is interest. I cannot assess how much effort is needed to forward-port this to recent kdelibs etc., but it was a fully functional Kontact PIM client, i.e., Kmail (with OpenPGP and S/MIME encryption), Kontacts, Kalendar, Notes and Tasks; hence it far superseded the Maemo apps (modest etc.) and the Jolla apps (Mail, Calendar, Contacts) in terms of functionality.

Though I wonder, if the KDE initiative does provide a modern counterpart (Kontact / kde-pim) as part of KDE Plasma mobile and additional apps, but I only see Kalendar advertised.

P.S.: Another viable approach might be to run Plasma Mobile proper as desktop / “launcher”.

[denis.robel]

From my poit of view we are at a fork in the road.
The community is developing the base of the os into a different direction than Jolla likes.
I’m very excited by the new possibilities of this new libs.
But I fear that without coordinating and cooparating the further development the OS will lose its attractivity because silica is one of the key components.
I hope that Jolla registrates which powerfull community is around Sailfish. It seems that is time to make Sailfish open source.

[pansen-jim]

@denis.robel

But I fear that without coordinating and cooparating the further development the OS will lose its attractivity because silica is one of the key components.

From my point of view that is definitely true. The elegance and ease of use is what makes me feel “at home” whenever I had an Android device or Ubuntu Touch device in use and pick up my SFOS-phone. Dropping Silica would mean to me that one of the key selling points would be killed.

[tortoisedoc]

Lipstick as far as I remember at least is a qt-wayland base compositor.
if the wayland protocol version (!) matches the plasma one, it should work? But was there some licensing issue with qt-wayland?

Styles would be an awesome achievement.
Also proper wayland overlays (subsurfaces) would be very much interesting.

[rinigus]

@ApB

How easy it would be to break the OS in two. Meaning have a corporate edition which jollas can sell (limited by all the licensing stuff) and a community edition where the devs can go bonkers with it and jolla pull in the corporate edition things they like.

In some respect, that what is going on with having /opt/qt5 with the “community” extras and what is in Jolla Store compatible being corporate. Another way of looking into it is considering /opt/qt5 as a testbead for new approaches and long delayed Qt update. As we rely on many third-party libs/apps, dual licensing used by Qt is somewhat complicated.

@olf

These goals seems to align very well with the NemoMobile project (sources@GitHub), specifically the Glacier UX

It is in part. Also, similar project is https://cutie-shell.org/ . As far as I know, Nemo is using Lipstick on newer Qt - so we could work with them if we want to go that route. It would make sense to work on Lipstick if Jolla would like to use it in future, for example. Thus we could get larger number of developers interested in it. Similar argument go for KWin used by Plasma Mobile shell. BTW, current Plasma Mobile state can be tested using postmarketOS QEMU image. As you could see, Plasma Mobile shell interactions are different from ours on SFOS and we would probably want to adjust it for SFOS case.

@olf

Though I wonder, if the KDE initiative does provide a modern counterpart (Kontact / kde-pim ) as part of KDE Plasma mobile and additional apps, but I only see Kalendar advertised.

To my understanding they are way behind Jolla’s email. As for KDE4 revival, I would expect that it is too complicated.

@denis.robel

But I fear that without coordinating and cooparating the further development the OS will lose its attractivity because silica is one of the key components.

Hence this discussion. To figure out how to proceed in a way that is beneficial to community and Jolla.

As for open sourcing silica - this is probably not going to happen. It hasn’t happened so far and I don’t see why Jolla would change it. They surely have their reasons for keeping it closed source. However, as was written above, what we can do is to take Kirigami - lib that has similar concepts to Silica - and style it to behave and look similar to Silica.

@tortoisedoc

Lipstick as far as I remember at least is a qt-wayland base compositor.
if the wayland protocol version (!) matches the plasma one, it should work? But was there some licensing issue with qt-wayland?

qt wayland licensing shouldn’t be an issue for open source work. Plasma has some extensions, but I haven’t looked into it.

[ApB]

@rinigus

In some respect, that what is going on with having /opt/qt5 with the “community” extras and what is in Jolla Store compatible being corporate. Another way of looking into it is considering /opt/qt5 as a testbead for new approaches and long delayed Qt update. As we rely on many third-party libs/apps, dual licensing used by Qt is somewhat complicated.

TBH i didn’t have just Qt in mind (which of course it is the big blocker for everything). There are other components and ways we do thing that are old and could be updated/brought up to date.

Ie. systemd and the way we do encryption. Localization is another issue that the main os lacks. Ie i still cant have word suggestions in my native language or be able to set an external keyboard with it.

And IMO the OS should feel a bit more like a normal linux distro. You still cant select a user name for yourself. And probably made other areas that i cant think of at the moment.

[tortoisedoc]

But why take yet another stack (plasma) if there is one closer to sfos (nemomobile)?

Jolla should benefit from the work of the community, not the other way around (just my 2 cents); i guess this means basic (opensource) packages work(updating, replacing);
if silica runs on qt5.15 as it runs on the current installed one, theres no need to think they would not be able to do so.
However. Does this mean the community work would end up in mer?
And, if so, then of course there is then the meritocracy “issue”.

[rinigus]

@ApB

TBH i didn’t have just Qt in mind (which of course it is the big blocker for everything). There are other components and ways we do thing that are old and could be updated/brought up to date.

For many other components it is not that bad. But good points, indeed.

@tortoisedoc

But why take yet another stack (plasma) if there is one closer to sfos (nemomobile)?

It is just due to the sizes of corresponding development community. There are ~2 developers behind Nemo, as far as I know. Plasma, to my understanding, is larger and it makes sense to join forces with the larger mass - assuming that the interests align.

[simonschmeisser]

@rinigus

To my understanding they are way behind Jolla’s email. As for KDE4 revival, I would expect that it is too complicated.

There seem to be some mail support in Kalendar which is based on Akonadi (the backend of Kontact and KMail) and I suspect this would be way ahead of Jollas mail client pretty soon as the backend is quite complete and powerful.

[PeegeeTips]

God speed to you.

i’m a kde user, and happy to see a closer alignment of these QT derived OS’es.

[Valorsoguerriero97]

Indeed it’s cool to see Plasma derived app coming there

[buckie]

I may be missing something important here, but why stick with Sailfish at all when we have Plasma mobile? Who exactly is going to benefit from yet another undermanned project that also happens to be huge and has unresolved corporate ties?

[attah]

Aren’t you comparing apples and pears now?
Sailfish is an OS, whereas Plasma mobile is a desktop environment.

[Seven.of.nine]

The nice thing about Linux has always been that you can choose the graphical UI yourself and that the user software still runs.

[rinigus]

@buckie

I may be missing something important here, but why stick with Sailfish at all when we have Plasma mobile?

Reasonable questions. We can compare SFOS with Plasma Mobile based distributions. Unfortunately, I don’t have experience with PlaMo distributions and someone could chip in regarding its readiness for daily use and comparison with SFOS. SFOS, with all its limitations, can be used as a daily driver and, in this respect, it makes sense to build on this foundation. We are also familiar with it, value interaction with Jolla’s devs and infrastructure made available for us by Jolla.

As for “undermanned project”, we would have to watch out for that - sure.

@Seven.of.nine

The nice thing about Linux has always been that you can choose the graphical UI yourself and that the user software still runs.

If we talk about Lipstick and Plasma Mobile shell, its a bit trickier than swapping between GNOME and KDE on PC. Just looking into Lipstick dependencies tells how many interactions it has with different pieces of OS. In this respect, working with Nemo Lipstick on SFOS may make more sense as it probably fits into the OS provided interfaces well.

[AndyWuest]

Hi,
i installed Elisa (and the Qt Runner) via the Chum GUI App but it does not really work. When i start the app i only get a blank screen. Running the App via the terminal i get the following log output (on my XA2 plus device). I also installed the Kirigami Gallery which is working when i start it. Any ideas why the app is not working?

[kan_ibal]

Use Qt Runner and set Override DPI to value around 240-300.

[poetaster]

My two bits as one who has made some small messy contributions to this effort.

1. I’m way too invested in the silica apps which I’ve become maintainer of to do ‘much’ with /opt
2. I’m fine with apps that don’t match silica like guidelines, since not all things need it (obviously, I hack together webviews). @rinigus has already included ktrip which is great, even if I already support fahrplan and multimodal. Backups.
3. As far as hoping to use much from the KDE stack, nah. If one looks at something as simple as lskat, the card game from KDE games, the library depends are WAY over the top. Integration and shared libraries all well and good, but the more I look at the details, the less I want to go there. That is why I have not gone to ktransport for a fahrplan backend replacement. WAY more code deps to maintain. Maybe @Thaodan has a comment?
4. I think it’s a good opportunity to get into the details (for instance the licenses of plugins) which we might get expert legal advice on (I’d really pay for it) to get some updates into the stack Jolla is using.
5. I don’t want to waste time on the compositor if I don’t have to. But, as @piggz has shown, other shells are doable and that gives us a backup, should anything go terribly wrong with jolla.

I wonder what the sailmates think?