| rinigus | piggz @piggz:matrix.org: pong. (But will be out of reach soon till evening) | 04:27 |
|---|---|---|
| piggz | rinigus: nevermind :) | 06:48 |
| pvuorela | dcaliste: heya | 06:56 |
| dcaliste | Good morning pvuorela. | 06:57 |
| pvuorela | dcaliste: been now checking the notebook set again and did a pr for adapting eas. all known cases compiling fine for me now. | 06:58 |
| dcaliste | Great, thank you for the coordination and missing bits in EAS. | 06:59 |
| pvuorela | all in all looking good, but i'll still need to go through the mkcal commits in more detail. | 07:01 |
| pvuorela | maybe slightly scared what other code this could break somewhere even if the adaptation is easy. | 07:02 |
| dcaliste | Ok, thanks. I think the next step is to separate the storage backend from ExtendedStorage API. Maybe I'll rework a bit mkcal#28, but it's a good starting point in my opinion. And since it is happening behind the scene of ExtendedStorage, it should not have too many API breakages. | 07:02 |
| pvuorela | sure | 07:02 |
| dcaliste | Yes, I know that several community code are already using mKCal directly and will have to be updated. | 07:03 |
| dcaliste | Once it is accepted, and published in 4.5 or whatever public version, there should be a forum official thread about it. | 07:03 |
| dcaliste | I can be mentioned in such thread as a help to update these codes with PRs. | 07:04 |
| pvuorela | well it's not harbour allowed or anything but some mention could be in place. | 07:04 |
| dcaliste | Yes, for harbour it's safe ;) but there are many other code on chum or wherever. | 07:05 |
| pvuorela | and if there are other adjustments it could be ok among them. now just alone the benefit of the breakage is not that big for the app side. | 07:05 |
| dcaliste | Indeed. To come back to the separation of backend and extendedstorage API, this could allow transparently to deal with several separated SQlite DBs exposed in the same calendar (a bit like it was designed for according to the doc and some remaining comments here and there in the code). | 07:07 |
| dcaliste | That would be a huge benefit for the external codes because they could deal with calendar entries without asking for system calendar permissions. | 07:07 |
| dcaliste | And, if I understood it well, the idea of reworking the mKCal API is to be able to make it stable enough for harbour permission, right ? | 07:09 |
| pvuorela | hope some day. need to figure out a bunch of things before that can happen. | 07:10 |
| dcaliste | Indeed, I forgot to mention long term objective in the sentence ;) | 07:11 |
| dcaliste | About mkcal#28, after the current rework about ::Ptr has been accepted, I think I'm going to separate in into two or more PRs with one or two commits to get the less controversial changes going in first and then just concentrate on the API design for the storage backend part. | 07:13 |
| pvuorela | that's a good plan. | 07:13 |
| dcaliste | With all the changes done in codes using mKCal storage API, I think it was a good move to make the readonly be a hint only. It simplified a lot various place that needed to make the notebook readwrite to commit changes before puting it back to read only. | 07:17 |
| pvuorela | indeed. was a strange setup when the readonly state was modified but not updated. | 07:18 |
| dcaliste | But looking at the Buteo plugin making use of mKCal storage API, I found a lot of confusion about the ::save() routine. Many times, any change to notebook were supposedly commited with a save() call. Which is inaccurate. | 07:21 |
| dcaliste | All storage API is in-sync. All notebook related changes are commited immediately and incidence changes are commited immediately with the save() call. | 07:21 |
| dcaliste | Would it be a good idea to rename save() into saveIncidenceChanges() ? | 07:22 |
| pvuorela | hm, wonder if it's worth it. most of the time the changes should be anyway to incidences. | 07:23 |
| dcaliste | I didn't change behaviour in the Buteo plugins not to mix up things and potentially introduce regression in a move that is not related, but particularly the Google plugin (and vk and facebook) is calling save() after a call to updateNotebook(). | 07:23 |
| dcaliste | We're breaking API already and doing a lot of repos update, so it's now or much later in time. I agree it doesn't bring anything, except maybe a clearer intent for the API. | 07:24 |
| dcaliste | Oh, just remembering, what about jolla-email#532 ? I've changed it to hide the signature icon in email listing when there is no capability to verify or display such signatures. | 07:33 |
| pvuorela | dcaliste: commented there | 07:38 |
| dcaliste | Ah, yes, good point. Thanks for raising it. I'll add cache in the C++ part. | 07:40 |
| dcaliste | Do you have any news about week view design by the way ? | 07:43 |
| pvuorela | sorry :/ i'll try pinging again. | 07:43 |
| dcaliste | Thanks. | 07:45 |
| pvuorela | dcaliste: there's something, perhaps enough to share but i'll get back to that later. | 07:49 |
| dcaliste | Great news. I'm eager to learn about it ;-) | 07:53 |
| dcaliste | Thanks, let's review (and fix if necessary) the noptr PRs for mKCal and rework mkcal#28 from my side. | 07:57 |
| pvuorela | yep. if nothing surprising i'll approve and merge later. after i've gotten my related changes reviewed. | 07:58 |
| pvuorela | btw you can use JB#58152 as bug reference | 07:58 |
| dcaliste | Ah, sure, I'll update the various commit messages. | 07:59 |
| pvuorela | i can also do annotated tags but that could be important enough change to have the bug reference more visible. | 07:59 |
| dcaliste | Sure, no problem to amend the various commit messages. | 08:00 |
| dcaliste | Ok, pvuorela, JB id added for the various PRs. | 08:10 |
| pvuorela | dcaliste: thanks | 08:11 |
| *** Mikaela is now known as Guest715 | 20:59 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!