Thoughts on the Plasma Mobile calendar

Wed Jun 23 16:16:32 BST 2021

On 22/6/21 7:56 μ.μ., Aleix Pol wrote:
> On Mon, Jun 21, 2021 at 8:15 PM Dimitris Kardarakos <dimkard at posteo.net> wrote:
>> On 21/6/21 8:12 μ.μ., Carl Schwan wrote:
>>> Le lundi 21 juin 2021 à 18:41, Dimitris Kardarakos <dimkard at posteo.net> a écrit :
>>>
>>>> Hello everyone,
>>>>
>>>> Back in 2018, the Plasma Mobile ecosystem consisted of just a handful of
>>>> apps. After a short discussion with Bhushan, I stepped forward to work
>>>> on Calindori, the calendar application for Plasma Mobile.
>>>> Calindori is written in QML/C++, it is based on Kirigami and (tries to)
>>>> follow the KDE HIG. As a Kirigami based application, it can also run on
>>>> desktop. In particular, some desktop specific bits have also been added
>>>> to improve the desktop UI/UX. You can find more details here [1]
>>>> During Akademy 2019 in Milan, Nicolas Fella suggested that a plugin
>>>> system is created [2] that would make Calindori (or any other
>>> application that uses KCalendarCore) support various calendar backends.
>>>> So, I have been maintaining Calindori trying to fulfill these requirements:
>>>>
>>>> 1.  Offer a mobile application, and try to leverage Kirigami convergence
>>>>     capabilities to improve the desktop experience
>>>> 2.  Support calendars that follow the iCalendar [3] standard using
>>>>     KCalendarCore [4]
>>>> 3.  Avoid to tightly couple the application with a specific calendar
>>>>     backend (e.g Akonadi, Sink, etc)
>>>> 4.  Adopt the plugin based approach for multiple calendars and online
>>>>     synchronization support [5]
>>>>     Let me now share my thoughts on the the "Plasma Mobile - Calendar" [6]
>>>>     Google SOC project (you can track its progress here [7]).
>>>>     People in the free software ecosystem are free to work on any project
>>>>     they feel like. Certainly, the Google SOC mentor(s) may have a plan that
>>>>     is not compatible with Calindori. However, I started Calindori in order
>>>>     to enhance the Plasma Mobile ecosystem and have been trying hard to
>>>>     maintain it over my limited volunteer contributor time. I am not
>>>>     interested in entering in competition with anyone within the Plasma
>>>>     Mobile team and the KDE community in general.
>>>>     With all this in mind, if the Plasma Mobile team is not happy with the
>>>>     approach of a Plasma Mobile calendar mentioned above and/or my work in
>>>>     general, and they would like to adopt the Google SOC project approach, I
>>>>     can step down as Calindori maintainer. Then, the Google SOC mentor(s)
>>>>     could take over maintenance and merge their work with Calindori or just
>>>>     continue with a separate application.
>>>
>>> Hi Dimitry,
>>>
>>> I'm sorry that you feel hurt. This wasn't my intention. My goal wasn't to
>>> create a competition between Calindori and Kalendar when I started Kalendar
>>> 4 months ago and QuickMail. When I was working on some Kirigami Calendar
>>> components and Plasma Desktop Calendar redesign, I discussed with you the
>>> possibility to redesign Calindori, you weren't very enthusiastic about making
>>> Calindori more complex and for example moving some view from simple ListView
>>> to more complex views with the goal to make Calindori also great on the desktop
>>> and more feature-complete with Korganizer.
>>>
>>> And to be fair, I wasn't very enthusiastic either with the plugin system
>>> My reasoning is that Akonadi is already an abstraction and adding an additional
>>> abstraction on top for viewing events, editing events, adding calendars,
>>> configuring calendars wouldn't be really easy to create and maintain. It doesn't
>>> help that some data like the calendar name or the event colors are stored in
>>> Akonadi/Sink instead of KCalendarCore. I might be wrong though.
>>>
>>> Maybe we should set up a bof during Akademy and discuss this a bit? Merging
>>> our efforts or creating shared calendar components could be a good idea?
>>>
>>> Regards,
>>> Carl
>>>
>>>>
>>>>     [1] https://invent.kde.org/plasma-mobile/calindori
>>>>     [2] https://phabricator.kde.org/D24443
>>>>     [3] https://tools.ietf.org/html/rfc5545
>>>>     [4] https://api.kde.org/frameworks/kcalendarcore/html/index.html
>>>>     [5] https://invent.kde.org/plasma-mobile/calindori/-/merge_requests/37
>>>>     [6] https://community.kde.org/GSoC/2021/Ideas
>>>>     [7] https://claudiocambra.com/2021/06/14/first-week-of-google-summer-of-code-2021/
>>>>
>>>>     All the best,
>>>>
>>>>     --
>>>>
>>>>     Dimitris
>>>>
>>>>     https://dimitris.cc
>>
>> Hello Carl,
>>
>> let me disagree with you on the content of the discussion we had in the
>> past. In particular, we had an one-off short and friendly chat on Matrix
>> where I was pretty open to any kind of UI/UX redesign. With regards to
>> the plugin abstraction, I mentioned (and I still believe) that the
>> Plasma Mobile calendar should not be tightly coupled to a specific
>> backend. But that’s just my technical point of view and I may be wrong
>> on this. Till then, no further discussion on any kind of joint work took
>> place either in public or in private.
>>
>> With all due respect, let me clarify the motive of starting this
>> community discussion. I am mostly interested in discussing the fact
>> that, based on any, minor or major technical details on how a Plasma
>> Mobile calendar should work, a Google SOC project was suggested and
>> kicked off.
>>
>> All the best,
> 
> It sounds clearly to me that there's been some kind of
> miscommunication. Would it be possible to have a BoF on the topic over
> the week? Or maybe we can discuss it on the next Plasma Mobile meeting
> (scheduled for Friday 2nd at 14h UTC).
> 
> Aleix
> 

Sure, Plasma Mobile BBB meetings, matrix channel and invent issues have
been the platforms suitable for the technical aspects of this
discussion. I will do my best to join the team meeting of 02/07.

-- 
Dimitris
https://dimitris.cc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xDD10816BA7DE60CE.asc
Type: application/pgp-keys
Size: 7824 bytes
Desc: OpenPGP public key
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20210623/277d608a/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20210623/277d608a/attachment.sig>