Community meeting on 3rd October 2024

Announcements
#1

Schedule: Thursday 2024-10-03T07:00:00Z   :world_map: :date:

Topic proposals for the meeting:

  • Add your name/nick using the template below to suggest a topic.
  • Indicate how much time you’ll need so we can time-box the meeting accordingly.
  • Please be as thorough as you can with your question/topic.
  • If you can’t make the meeting please ask and name a substitute.

It is expected that you show up and present your topic, or name a substitute and make sure they attend in your absence. These IRC meetings are for real time participation and live discussions, otherwise you can post the topic on here and get responses that way.

We need you to be present to clarify details in the topic, and to ensure the discussion is leading to the answers you are looking for! If you do not participate or your question/topic isn’t clear enough it will be postponed. Also: always ask for more time than you anticipate your topic needs!

Please have your topics ready at least 3 days before the meeting so we can prepare good answers. Topics announced afterwards will be postponed to the next meeting.

Template for topic proposal: (post your topic proposals as comments to this forum topic).

  • Name/IRC nick:
  • Topic:
  • Some details about the topic:
  • Approx. time needed:
  • Substitute (optional):

Open Pull Requests:
If you have, or know of, a pull request that’s been open for at least 3 weeks, but which you think deserves attention, please add a comment using the template below and we’ll consider it during the next meeting.

  • Name/IRC nick:
  • Open PR URL:
1 Like
Sailfish Community News, 26th September 2024 - Sailathon
#2

Name/IRC nick: dcaliste

Topic: rewriting of QtMobility plugin providing an engine for QtOrganizer based on mKCal

Some details about the topic: like QtContacts used in Sailifsh OS, QtPim (long heir of QtMobility) provides a module to deal with events and todos : QtOrganizer. It provides an API and QML bindings to handle calendar items. It can use several backends for storage. Old sources from QtMobility dated from Qt4.x era still have a plugin based on mKCal (the SQLite backend for calendar event used in Sailfish OS). But these sources are really out-dated, both mKCal and QtOrganizer have largely changed API since Qt4.x era. I’ve decided to rewrite the plugin, so current (or future) code using QtPim/QtOrganizer can have a well debugged SQLite backend, or even share data with an application based on nemo-qml-plugin-calendar
(like the calendar application). The new implementation can be found in this git repository. The main point of this topic is to announce the existence of this new possibility to handle calendar events and todos. While I’m still preferring to base new developments on the couple KCalendarCore/mKCal, the community meeting may be the place to discuss the pros and cons of this new possibility based on QtPim.

Approx. time needed: 5 to 15 minutes, depending if there is interest to discuss the topic, or if the announcement is just enough.

Substitute (optional): I’ll try to do my best to be present.

2 Likes
#3

Minutes: #sailfishos-meeting: Sailfish OS, open source, collaboration -- 3rd October 2024
Minutes (text): https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2024/sailfishos-meeting.2024-10-03-07.00.txt
Log: #sailfishos-meeting log

#4

Thanks for the further elaboration of the context. I had not been aware how far QtMobility was away from KCaldendar. But, if I understand correctly, the QtMobility sqlite backend could ‘merge’ towards mKCal ?

3 Likes
#5

I had not been aware how far QtMobility was away from KCaldendar.

As far as I know, QtMobility has never been based or using KCalendarCore (formerly KCal). There was an official plugin based on mKCal (itself a child of KCal division) though, but the KCalendarCore API are not exposed, just used internally to the plugin. Actually, QtOrganizer (from QtMobility) and KCalendarCore (from KCal) are equivalent projects, allowing to represent in memory, calendar data (event, todos and journals), mostly conforming to the iCal RFC2554.

Besides, QtMobility has been abandonned. It didn’t reach Qt5 era and stayed with Qt4 APIs. With KDateTime in QtOrganizer for instance because at that time Qt was not handling well time zones in QDateTime.

The elements of QtMobility have been separated into smaller pieces. For instance QtFeedback is now a standalone Qt module. QtContacts and QtOrganizer (with some other modules) have been put into a new module named QtPim. And QtPim has been upgraded up to Qt6.

The engine plugin for QtOrganizer based on mKCal from QtMobility has also been abandonned with QtMobility and didn’t go into QtPim (there is no QtOrganizer engine in QtPim besides the memory one). The APIs in mKCal and in QtOrganizer have changed much, that’s why I decided to rewrite a plugin from scratch instead of adapting the existing one from QtMobility and the Qt4 era.

the QtMobility sqlite backend could ‘merge’ towards mKCal ?

What do you mean ? The old mKCal plugin from QtMobility sources can be upgraded to adjust for API changes, but the solution I propose, was to rewrite it.

2 Likes
#6

Ok, that’s essentially what I meant. I just can’t keep track of what KCal is doing but assuming that the sqlite backend is mKCal then your rewrite will arrive at something like parity with what KCal is doing …?

#7

Ah, ok I see. If I’m correct, KCal was historically the solution KDE developed to handle calendar stuff. It has nothing to do with QtOrganizer, QtMobility and QtPim. It’s a different implementation. KCal contained a memory representation of iCal objects described in RFC 2554. It also provided on-disk storage for off-line usage, with different backends: an SQLite one and one based on files (just storing the ical representations on disk for the various events). That’s the two I’m aware of. Maybe there were other backends as well at that time.

At one point the backends and some other APIs used by Nokia (the Notebook for instance) were pushed out of KCal and became mKCal, while KCal concentrated on being just a memory representation of RFC 2554 incidences. KDE developped a new backend based on Akonadi in a separated repo.

At the same time, (under Nokia influence I guess), Qt was working on QtMobility and developped a completely different API to handle RFC 2554 incidences : it’s QtOrganizer. I guess it was convenient to write an engine plugin for this different API using mKCal as an SQlite backend.

So to be short:

  • formerly KCal, now KCalendarCore + mKCal = a complete solution to handle and store off-line RFC 2554 incidences,
  • QtOrganizer + mKCal engine plugin = a complete solution to handle and store off-line RFC 2554 incidences.

Since they are using the same off-line storage, they can interact : you can read incidences with a QtOrganizer-based UI, incidences that are created by the Buteo CalDAV plugin using KCalendarCore + mKCal. And vice et versa.

4 Likes
#8

Thanks for clarifying. That’s exactly what I was hoping for!

1 Like