Tuesday, 2023-06-06

dcalisteGood morning pvuorela, how are you ?07:00
pvuoreladcaliste: hey, i'm good. how are you?07:01
dcalisteI'm fine thank you. I'm grateful for the time you take for the review of instanceId PR.07:03
pvuorelai'm happy you're doing that stuff :)07:03
dcalisteHopefully this will end up in an API that is robust and allows us to change internal implementation without touching it yet another time.07:06
pvuorelaoverall starts to look quite nice. for the one thing i was left pondering is that earlier the uid could be used to refer to the whole series while now from instanceId that's only possible by fetching the event and checking if it has a parent etc.07:06
dcalisteIndeed, but as far as I know, passing the uid for the whole series was done only in two cases:07:07
dcaliste- removeAll(), and here the name of the function is quite explicit,07:08
dcaliste- and convertEventToICalendar(), but this case is less clear.07:08
dcalisteFor the later, as you mentioned in the PR comments, the intent is not clear to me.07:09
dcalisteThe current implementation (before the PR), only export the parent, without exceptions.07:09
dcalisteBut I guess the right thing would be to export the full series ?07:10
dcalisteAs you know, I chose for simplicity in the current PR to export the xception alone instead.07:10
dcalisteSo, indeed, this case must be sorted out before PR acceptance.07:11
pvuorelajust commented on the pr. at least it's better to export the exception than just the parent. whether it should be everything or just the specific instance, it could be a grey area.07:11
dcalisteIndeed, for instance, Google is sending only exception by emails for instance.07:11
pvuorelaif they are doing just that, it can't be much wrong :)07:12
dcalisteI will change the comment there to reflect this possibility and the choice done.07:13
pvuorelayea. guess it could be all fine.07:13
dcalisteAbout Google, it's in the case of a cancel inivitation for a recurring meeting. When you cancel one occurrence, it is sending an email with the cancellation notice and attached you have ICS data containing the exception occurrence only.07:14
dcalisteMy CalDAV provider, based on OpenMX, when you select an exception and export it, it is also generating ICS data for the exception only.07:16
dcalisteBut I don't know if it's a good reference: when selecting a normal occurrence and exporting it, it is exporting the parent incidence, without the exceptions…07:17
pvuorelamaybe it's just too much of a corner case to have gotten attention.07:18
dcalisteSo, the current PR implementation will do exactly this. Not sure it's the best thing, but it would be the same than some other implementations.07:18
dcalisteOk, so I've just updated the comment in this function.07:21
pvuorelalooking good07:22
dcalisteGreat. When the PR will be in, I'll rework and publish in a new PR the switch to use MultiCalendarStorage instead of ExtendedStorage, based on mkcal#61. If the instanceId goes well, it should not impact any public function.07:24
dcalisteAnd it will be possible to address the notebook switch and all related signal handlers (onUidChanged and firends).07:25
dcalisteAnother topic, you may have notice https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/2407:31
dcalisteIt's about getting and storing the information related to calendar allowed content.07:31
dcalisteSome calendars are made exclusively for VTODO for instance (OpenMX and Nextcloud are creating such calendar by default).07:32
dcalisteAt the moment, it is possible to add events to such calendars through the UI, but then, the sync is always failing for such events (of course, rejected by the server).07:32
pvuorelaseems good to me.07:33
dcalisteThe idea is to get such information and adjust the UI possibilities accordingly.07:33
dcalisteIn https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/57, I'm completely hiding such calendars. Which is in my opinion, the best solution. But this means that people who added events to such calendars will have their events to disappear.07:34
dcalisteThe other solution would be to make such calendar listed, but made read-only.07:34
dcalisteWhat do you think ?07:35
pvuorelaif the notebooks aren't really supporting events, then better to not show them.07:35
pvuorelaif someone added events on such, they've already failed to sync and all07:35
dcalisteIndeed, I just wanted to be sure we agree, then the PR is fine as it is, I guess.07:36
pvuorelai'd assume so. on the surface looked good already.07:36
dcalisteWhat to do with the setting account page ? I've a PR to hide non-event calendars there also, but I didn't publish it because I think this page is a bit different: it is listing (and enabling) which calendar to sync via the CalDAV Buteo plugin.07:38
dcalisteSo in theory, even non event calendar could be synced or not.07:38
dcalisteBut I'm not sure the difference between this list and the manage calendar list in the calendar application, is easy to grasp for a user point of view.07:39
dcalisteYou create a new account, you see the Tasks calendar in the account page, it is enabled (selected), but then in the calendar, it is not there…07:39
pvuorelaat least "Tasks" hints a bit that it's not about events.07:40
dcalisteYes, I'm in favour of leaving it as it is, so the account page is really a "what should be synced" list. And thus in the future, syncing the todo calendar can be decided from here also.07:42
dcalisteActually, all this comes also from this proposition I made on the forum : https://forum.sailfishos.org/t/apps-by-ichthyosaurus/15753/2107:43
dcalisteWhich means, being able to use the Buteo sync plugin (or a library based on its code) to sync the todo calendar as used in a user application.07:44
dcalisteAt the moment, it's just wild ideas, but I'm looking what changes it would mean to the Buteo plugin and how such calendars are declared in the system.07:45
pvuorelanot sure if i'm too thrilled to have big adjustments for running the buteo code in some applications :D07:47
dcalisteHehe, that's the whole point : can we do this with minimal and logical modification to the plugin. Interesting chalenge.07:47
dcalisteOk, so thanks for the discussion, I think that's all from my side today. We can restart discussing mkcal#60 and mkcal#61 after the instanceId PR has been accepted and I've implementation to show with the new MultiCalendarStorage.07:54
dcalisteBy the way, I've added static method to get default implementation based on SQLite as you suggested and as it existed before in ExtendedCalendar.07:54
pvuorelaok, nice.07:56
pvuoreladcaliste: i'll need to go away from the computer for a moment now. suppose we are more or less done anyway. thanks for everything again!08:00
dcalisteSure, enjoy your day. Thanks again.08:00
pvuorelacheers :)08:00
poetasterpiggz[m], rinigus I wanted to ask if we should migrate to the knew naming in chum meta? Or stick to the original terms for now?17:36
malwhat naming change are you talking about?17:41
piggz[m]poetaster: wdym?18:51
poetasterpiggz[m], mal PackageName: Limit becomes Title: Limit?21:02
poetasterPackagerName vs. PackagedBy ?21:03

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!