@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
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.
Since I am currently updating to 4.6.0.13, do not need Angelfish and QTrunner and have already uninstalled them, I now need a little help to uninstall all QT5 and also kf5 packages.
I have just uninstalled the qt-sfos-maliit-platforminputcontext. Let’s see what’s left.
There are still a lot of qt5/kf5 packages available. Uninstalling individually does not work because of the dependency between them
Here’s your answer…
2 Likes
Any chance for a proper 486 build of angelfish/qt5.15? 4.5 one caused issues with wifi not being available on the tablet (and boot loops if not connected to power)
1 Like
I’ve installed angelfish in my jolla tablet with sfos 4.6, but angelfish doesn’t work: when I start it a blank page is shown.
If I start angelfish from Terminal I get errors with some Qt5 libraries:
‘/usr/bin/angelfish: /usr/lib/libQt5Core.so.5: version `Qt_5.15’ not found (required by /usr/bin/angelfish)’. Does anyone know how to solve it? @throwaway69, does it happen to you?
Its strange that it looks for libraries in /usr/lib. I would expect that it will be requesting those in /opt/qt5. With this installation, have you seen whether all dependencies from opt- got installed?
1 Like
Yep, I’ve installed from Terminal using zypper, and 53 packages were installed: angelfish, ‘opt-’ libraries,
qqc2-breeze-style and qt-runner. It’s the first time I’ve installed angelfish with qt5.15 in my tablet, previosly I had angelfish and flatpak installed but I removed everything before installing angelfish with qt5.15.
I’ve removed all qt5.15 stuff on tablet as it was causing booting problems (0 success rate to boot without power on, and even with power on wifi would work 0 times out of 20 or so, with all the packages removed it came back to unsuccessful boot 1/3 and so far 0 issues with wifi), get the esr91 packages from @direc85 to improve browsing on the tablet, it works fine, not sure if packaging has been fixed or still needs 2gb install (can just rpmrebuild that rpm on tablet and strip the .so during the rebuild, if you go with rebuild, just restart homescreen after as your swap/tmp will be full and it will look like it’s crashing, should work fine after)
1 Like
Thank you for your answer, so you never started angelfish in your tablet, right?
In my case, installing qt5.15 doesn’t cause booting problems in my tablet, I only have problems to connect it to my wifi but it happens to me since sfos 3, so I think that this problem is not related with installing angelfish-qt5.15.
I haven’t try sailfish-browser (esr91) in my tablet yet, anyway I would like to have two browsers in my tablet, and I prefer to use webapps with angelfish.
1 Like
Yeah it didn’t work, just as in your description, don’t remember exactly but it was throwing some errors about libs from cli
1 Like