Qt 5.15: what's next?

@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.

1 Like

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.

6 Likes

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.

1 Like

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

3 Likes

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.

8 Likes

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.

Thatā€™s already a possibility as discussed in one of the last community meetings

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.

7 Likes

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

2 Likes

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.

7 Likes

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