| dcaliste | Good morning pvuorela, how are you ? | 07:00 |
|---|---|---|
| pvuorela | dcaliste: hey, i'm good. how are you? | 07:01 |
| dcaliste | I'm fine thank you. I'm grateful for the time you take for the review of instanceId PR. | 07:03 |
| pvuorela | i'm happy you're doing that stuff :) | 07:03 |
| dcaliste | Hopefully 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 |
| pvuorela | overall 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 |
| dcaliste | Indeed, 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 |
| dcaliste | For the later, as you mentioned in the PR comments, the intent is not clear to me. | 07:09 |
| dcaliste | The current implementation (before the PR), only export the parent, without exceptions. | 07:09 |
| dcaliste | But I guess the right thing would be to export the full series ? | 07:10 |
| dcaliste | As you know, I chose for simplicity in the current PR to export the xception alone instead. | 07:10 |
| dcaliste | So, indeed, this case must be sorted out before PR acceptance. | 07:11 |
| pvuorela | just 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 |
| dcaliste | Indeed, for instance, Google is sending only exception by emails for instance. | 07:11 |
| pvuorela | if they are doing just that, it can't be much wrong :) | 07:12 |
| dcaliste | I will change the comment there to reflect this possibility and the choice done. | 07:13 |
| pvuorela | yea. guess it could be all fine. | 07:13 |
| dcaliste | About 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 |
| dcaliste | My 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 |
| pvuorela | alright. | 07:16 |
| dcaliste | But 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 |
| pvuorela | :) | 07:17 |
| pvuorela | maybe it's just too much of a corner case to have gotten attention. | 07:18 |
| dcaliste | So, 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 |
| pvuorela | yep | 07:18 |
| dcaliste | Ok, so I've just updated the comment in this function. | 07:21 |
| pvuorela | looking good | 07:22 |
| dcaliste | Great. 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 |
| dcaliste | And it will be possible to address the notebook switch and all related signal handlers (onUidChanged and firends). | 07:25 |
| dcaliste | Another topic, you may have notice https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/24 | 07:31 |
| dcaliste | It's about getting and storing the information related to calendar allowed content. | 07:31 |
| dcaliste | Some calendars are made exclusively for VTODO for instance (OpenMX and Nextcloud are creating such calendar by default). | 07:32 |
| dcaliste | At 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 |
| pvuorela | seems good to me. | 07:33 |
| dcaliste | The idea is to get such information and adjust the UI possibilities accordingly. | 07:33 |
| dcaliste | In 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 |
| dcaliste | The other solution would be to make such calendar listed, but made read-only. | 07:34 |
| dcaliste | What do you think ? | 07:35 |
| pvuorela | if the notebooks aren't really supporting events, then better to not show them. | 07:35 |
| pvuorela | if someone added events on such, they've already failed to sync and all | 07:35 |
| dcaliste | Indeed, I just wanted to be sure we agree, then the PR is fine as it is, I guess. | 07:36 |
| pvuorela | i'd assume so. on the surface looked good already. | 07:36 |
| dcaliste | What 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 |
| dcaliste | So in theory, even non event calendar could be synced or not. | 07:38 |
| dcaliste | But 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 |
| dcaliste | You 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 |
| pvuorela | at least "Tasks" hints a bit that it's not about events. | 07:40 |
| dcaliste | Yes, 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 |
| pvuorela | exactly. | 07:43 |
| dcaliste | Actually, all this comes also from this proposition I made on the forum : https://forum.sailfishos.org/t/apps-by-ichthyosaurus/15753/21 | 07:43 |
| dcaliste | Which 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 |
| dcaliste | At 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 |
| pvuorela | not sure if i'm too thrilled to have big adjustments for running the buteo code in some applications :D | 07:47 |
| dcaliste | Hehe, that's the whole point : can we do this with minimal and logical modification to the plugin. Interesting chalenge. | 07:47 |
| pvuorela | sure | 07:48 |
| dcaliste | Ok, 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 |
| dcaliste | By 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 |
| pvuorela | ok, nice. | 07:56 |
| pvuorela | dcaliste: 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 |
| dcaliste | Sure, enjoy your day. Thanks again. | 08:00 |
| pvuorela | cheers :) | 08:00 |
| poetaster | piggz[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 |
| mal | what naming change are you talking about? | 17:41 |
| piggz[m] | poetaster: wdym? | 18:51 |
| poetaster | piggz[m], mal PackageName: Limit becomes Title: Limit? | 21:02 |
| poetaster | PackagerName vs. PackagedBy ? | 21:03 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!