Qt 5.15: what's next?

[vlagged]

I wonder what the sailmates think?

Mate here.

I think we need to aim for a better world for all mobile phone users, so they can use FOSS components as much as they like
As @rinigus says, SFOS is daily driver material, even though it is partly closed-source.
Having this Qt5.15 layer makes it more attractive than before with new apps available and developers potentially jumping on the opportunity - but not for FOSS hardcore enthusiasts… (On the other hand, all hybris ports for that matter have dozen of closed source droid binaries…)
Going to the full-FOSS thing but alienating the existing community is not a wise move to make abruptly.

So yes, there is much to debate about what’s next.
I personally like the approach of styling the kirigami apps to be more closer to the theme.

But in all fairness, an association like Sailmates should probably help with the resources/hosting/services/etc in case e.g. community OBS is not enough, rather than opinions and decisions.

[ApB]

Its not a crime. Its just a small percentage of the user base.

Ideally Jolla would adopt presage and we would be able to add every language we need. Everyone would be happy -meaning Jolla would have a complete OS from a localization POV and weird tongue people like me be able to use their languages.

IMO the selection of components SFOS uses needs to be re evaluated in many areas. And TBH i don’t feel like QT was a good idea as the base toolkit. Its been mostly trouble. Anyway.

[poetaster]

@vlagged

But in all fairness, an association like Sailmates should probably help with the resources/hosting/services/etc in case e.g. community OBS is not enough, rather than opinions

Ditto. I Whatever we can do to win dev mindshare and extend the utility of sfos while maintaining infrastructure.

[poetaster]

@ApB

Ideally Jolla would adopt presage and we would be able to add every language we need.

Yes, this. I think Jolla is a bit stuck in legacy land. Presage was, I believe, not an option when they began with SFOS so I can see why.

[ApB]

One of the issues is that for stuff that are not licence bound they don’t move also. And i am not sure they would accept/merge contributions that fix those issues. Ie replace whatever is used with presage.

[tortoisedoc]

But would it be part of mer mw?

[rinigus]

To reply to that, we would have to figure out what to do next

Our work so far has been on open source components and I expect that it will continue along the same lines. Hopefully, it will be useful for Sailfish OS, Nemo Mobile and others OS / environments.

I started looking into compositors and it seems like Lipstick based one would make most sense for us on SFOS. It has integration with many SFOS components already and, on Nemo side, is already ported to Qt 5.15. Started with looking into compositors is to figure out which gestures are available for apps and reserved for compositor. Although, cannot promise at this stage that I will dig deeper and start working on that…

[CarlSchwan]

Hi, maintainer of Kalendar and heavy contributor to kde-pim and plasma mobile ecosystem here. Kalendar goal is to be a full PIM solution. We currently have the calendar and address book part mostly done, and we are in the progress of adding email functionality (currently hidden with a config flag). Most of our work involve making the pim libraries for handling calendar, contact, and email also more easy to use directly from QML (with Kirigami but this should also work with Silica or any qml toolkit). We will have three GSoC projects this summer, which hopefully will bring us nearer to our goal.

Recently we also started to decrease the memory usage of akonadi and to make the sqlite backend a lot more stable (I have some experimental branches reducing memory usage by 40% and I think I can reduce it even more). See for example, our blog post from yesterday March/April in KDE PIM - Kontact Suite

Generally I’m happy to collaborate on things as long as my bandwidth allows it

[tortoisedoc]

Yes; I would think it would be more “natural” to add eventual missing wayland extensions to lipstick rather than the other way around
Im thinking mostly subsurfaces yes!

[rinigus]

@CarlSchwan, great to hear it! Good luck with this important work and I hope that the folks working on SFOS PIM stack can help as well.

[CarlSchwan]

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.

Note that KWin can be flexible depending on the use case and in my experience, upstream is happy to accept external contributions outside of plasma (it’s currently used as Wayland compositor in Mercedes cars). The hwcompositor backend was dropped because nobody was maintaining it, and it was blocking changes in the other backends. If someone wants to take over the maintenance of it, I think it could be brought back. The advantage of Kwin is that it is one of the most maintained KDE project and support most wayland extensions.

[rinigus]

Re KWin: I have the same impression - it is well maintained project and surely flexible. Will have to look into it as well. As for hwcompositor, patches should be available from Droidian folks, I think.

[olf]

@CarlSchwan, thank you very much for your pleasant reply!

[dcaliste]

Hello @CarlSchwan, it’s great to see you here. Indeed, the PIM suite developped by KDE and the one used on SailfishOS share common libraries. It’s definitely a happy example of common benefit from open source. Libraries can be co-developped and different UI front-ends can be based on these foundations (and thanks to @rinigus and @piggz initiative, also being able to run different front-ends on the same platform).

The recent cleaning of KCalendarCore is a good motivation for better convergence. As a first patch, mKCal is going to adopt the notebook handling deprecated from KCalendarCore, but I’m now actively working on redesigning mKCal itself not to rely on notebook support in KCalendarCore::Calendar (actually decorrelating SQLite in/out of all mKCal::ExtendedCalendar and mKCal::ExtendedStorage stuff, making it only deals with KCalendarCore::Incidence::List and KCalendarCore::Calendar). If successful, this will provide a (hopefully) well debug and well tested SQLite backend for KCalendarCore::Incidence and their friends. We can discuss it in a KDE issue if this can be of interest as a backend for Akonadi. I would be interested in looking into it. It would also help to have another user of the mKCal library to see if API are robust and well-designed.

About using KCalendarCore QML directly, this is a long term convergence work for SailfishOS that relies heavily on nemo-qml-plugin-calendar which are QML bindings for KCalendarCore::Incidence coming from an era when KCalendarCore were not providing any. Sadly, the two API are really different. Hopefully, the mKCal rewrite (started thanks to your deprecation on notebook support !) will also help in the direction of bringing more KCalendarCore stuff into nemo-qml-plugin-calendar.

[David]

Hopefully, Jolla have seen this thread and are considering their response.

I have thought about this before and I rather suspect that the best move is for Jolla to let select, trusted developers work on the closed code under an NDA.

[simonschmeisser]

That’s already a possibility as discussed in one of the last community meetings

[piggz]

Im not sure a response from Jolla is necessary. This is just a project to experiment and expand the Sailfish eco system, and doesnt have to align with Jollas priorities. If there is some discussion/contribution then great, but currently, this is a few devs scratching an itch to see whats possible.

[tortoisedoc]

Noob question and asking out of the pit of my ignorance; isnt sfos a drm-based os?

[aerique]

I just installed Angelfish and to comment on some responses in this thread: Just looking at Angelfish’s looks and performance I’d rather fall back on a KDE / Plasma app than on an Android app if there’s no native SFOS app available.

[poetaster]

Ditto. It’s got warts, too, but often, if the native browser won’t do, angelfish will.