Wednesday, 2021-08-18

dcalisteGood morning flypig !07:05
flypigGood morning!07:05
flypigThanks for meeting again this week.07:05
flypigSo, I was thinking we could include a paragraph or two about your recent contributions. In the past you've written the section, and you'd be welcome to do that again, but if you prefer we can discuss them here and I can write a summary.07:08
dcalisteI planned to write an overview of the Buteo sync framework last time and include recent changes. What is the schedule for it ?07:13
flypigIt depends, particularly on how long you'd like it to be. The next newsletter will go out 26.08 (draft deadline this Sunday). But I have a decent amount of material for this already. A couple of paragraphs would go nicely still, but if it's longer like last time (which would also be great) I'd suggest aiming for the 09.09 newsletter.07:18
flypig(just in case it's useful, the general rule is: newsletter every fortnight, draft deadline the Sunday before).07:19
dcalisteWhat do you think about a quick follow-up from the changes discussed in the previous newsletter for the letter to come and a longer article about Buteo in general a fortnight later ?07:21
dcalisteThe follow-up could be about :07:22
flypigI think it's more work for you. But from my perspective that would be really nice.07:22
dcaliste- the recent merge of the Qt6 changes in QMF,07:22
dcaliste- the recent usage of OccurrenceIterator in nemo-qml-plugin-calendar, making a long divergence between upstream and mKCal about EXDATE not necessary anymore,07:23
dcaliste- addition of a new table in the database to fully support attachment from RFC (UI and nemo-qml-plugin-calendar still pending),07:26
flypigCovering those three topics would make a great follow-up. If you're confident about the Buteo text, we could trail that too.07:27
dcalisteYes, I will have time to prepare a longer text for Buteo if we move the deadline for it to Sunday September 5th.07:28
flypigSeptember 5th will be fine, yes. Okay, should we go through the other three items in a bit more detail to create a summary now then?07:31
dcalisteYes, let's go :07:33
dcaliste- from newsletter of April 22th, QMF was ported upstream to support Qt6. Changes were made to remove deprecated code. Every changes that is compatible with Qt5.6 have been kept and those requirering more modern version were reverted : see
dcalisteSo the SailfishOS repo is again in sync with upstream. It allowed to remove some patches that were moved upstream.07:38
dcalisteThe main difference that still remains between upstream and the version used in SailfishOS is the patch bringing support to the account framework.07:40
dcalisteThis patch is not upstreamable though, because QMF has already a support for account internally and the patch is replacing it with the libaccount one.07:40
dcalisteQMF should be reworked in the sense of introducing a generic account interface and plugin to implement it, providing a default one with its current implementation.07:41
dcalisteFlypig, do you need more information on this topic ?07:42
flypigThis is great. I'm just transferring it into a separate document (trying to find something I can use to share it with you).07:44
flypigOkay, here we are. You should be able to make edits too:07:46
flypigI'll remove the # headings in the final version, and also (probably it's clear, but just to be sure), lines prefixed with > will be formatted as quotes.07:50
dcalisteThanks for the framapad. I've added the link for the libaccounts. It's the upstream one. I guess it's fine, you may prefer the mirror one from Sailfish repo, or not.07:51
flypigI think that's great, thank you.07:51
flypigRather than quoting you, if you prefer, it can be an article written by you instead (i.e. no quotes).07:51
flypigPersonally I think that's sufficient for the first topic. Could we do the same for the second (your OccurrenceIterator changes)?07:53
dcalisteYeh, sorry, I've been away a moment. Indeed, I like the quoting as a reader, it makes the article more lively.07:57
dcalisteLet's move to the second topic :07:57
dcalisteInherited from the early days of KCalc (see newsletter from July 1st, is it this one actually ?), mKCal was providing a method to get the events of a given period, duplicating the recurring ones accordingly to their rules.08:00
dcalisteThis method was obviously taking into account the exceptions, when the occurrence of a recurring series of events is modified, like for instance a recurring meeting that is shifting one hour later at a given date.08:01
flypigYes, you wrote about MKcal in the 1st July newsletter:
dcalisteThe implementation of exceptions was done in a smart way not to duplicate code by automatically adding the exceptions as EXDATEs to the recurring rule of the parent event.08:03
dcaliste(RFC: EXDATE is a list of dates for recurring events when there is *no* event, for instance, the regular daily meeting at the coffee machine is obviously cancelled the January 1st).08:04
dcalisteThis was a smart move because the expanding code from KCalendarCore then automatically remove the "normal" occurrence thanks to the additional EXDATE and the exception occurrence was present at its peculiar date and time.08:06
dcalisteBut this smart idea has a main drawback, it is not RFC compliant, which means that recurring events coming from servers does not follow this rule of additional EXDATE and when we send the event to server we must conform to an RFC compliant definition.08:07
dcalisteIn every synchronisation plugin there is code thus to add (and remove) EXDATEs for exceptions on download (upload respectively).08:08
dcalisteSince our recent move to upstream KCalendarCore, we can use a new method that has been added there by KDE developpers to tackle this problem.08:09
dcaliste: the KCalendarCore::OccurrenceIterator class.08:09
dcalisteThis class is internally taking into account exceptions without the need to put them in the EXDATE list.08:10
dcalisteThe QML plugin for calendar is [now using this upstream method](
dcalisteIt allowed to remove the code from synchronisation plugins to convert between RFC and mKCal convention, see and
dcalisteAnd the specific code from mKCal has also been removed :
flypigWe can tidy it up fully later, but I think that's looking good so far. Are you happy with the article working along these lines?08:23
dcalisteYes, I've seen your editorial changes, they looked nice. I've just amended the introduction. The expansion routine is mainly used for display purpose actually.08:24
flypigThanks for that. I just threw something in, so I'm glad you've corrected it.08:25
dcalisteDo you prefer I actually write the text for the third topic directly ? It would save you some copy-pasting !08:26
dcalisteYou asked also about the release time for these changes : they will be included in the next branching, so from a user point of view in a release > 4.2.0, the next next one.08:26
flypigDo feel free to write it directly if you prefer to do it that way. You're right, it would remove one step of indirection!08:28
dcalisteflypig, in the introduction paragraph, I'm not sure that we should mention "bringing attachment support for invitation" actually this is still a work in progress as far as I can tell, and work that may even not land depending on internal decisions we don't know anything about.08:45
dcalisteMy point was just to mention the huge work done by them (and yourself as far as I remember) about the invitation mechanism in general.08:45
flypigAh, okay, I see. Sorry, I misunderstood.08:46
flypigI'll make changes. Would you mind if we skipped that entirely? It's a nice thing to write, but maybe it complicates things?08:46
flypigI.e. make it more neutral: "Changes continue to be made to the calendar capabilities..."08:47
flypigAnd I would change the last two paragraphs into quote from you if that's okay?08:48
dcalisteSure, you're the editor ! If you think it's less confusing without the mention of invitation in general, no problem to remove.08:48
dcalisteI'm ok with quoting the last two paragraphs.08:49
flypigDoes something like that look okay?08:50
dcalisteYes, it's fine like that.08:51
flypigYou don't have to accept my edits of course :)08:51
flypigIt's surprising how much material there is, but it's a really nice collection of info.08:52
flypigBut, because it's quite long, I now feel a bit bad not attributing the entire article to you. Would that be better (we can just remove the quote indents in that case, and I'll add a sentence at the top to introduce it).08:53
dcalisteYour editing looks great. No problem to keep it like that with the quoting.08:54
flypigOkay, then it'll be a really nice addition to the newsletter. Thank you! Is there anything else to add? It'll have to go through more internal editing I'm afraid.08:55
dcalisteI think that's it for the content. No problem for additional edition and proof reading of course.08:55
flypigYes, I'll carefully go through it again for grammer, spelling etc.08:56
flypigIn that case, I'll move it internally now. Feel free to take a copy (I'll clear the public pad later today), and I can send you a "final" copy to check later if you think you'd have time?08:57
dcalisteOk, send me the material for reading when it's ready. I'll send it back to you quickly lqter.08:58
*** karry_ is now known as karry08:59
flypigThank you! Thanks so much for this, it's really great. I know it's effort on top of all your other contributions, but I know other people will also appreciate it.08:59
dcalisteProviding information on what is done is also part of the open source idea, or let say open development. That's important. Thank you also for all the editorial work of gathering, layouting and writing for these community letters.09:01
flypigYes, I agree entirely!09:05
dcalisteI'm going to have a meeting in some minutes with colleagues. I thank you for the joined work today, flypig. I'm waiting for your email for one last proof reading later this week. Have a nice day.09:09
flypigThank you, that's perfect for me. Have a nice day yourself!09:11

Generated by 2.17.1 by Marius Gedminas - find it at!