| *** zbenjamin_ is now known as zbenjamin | 01:12 | |
| Mister_Magister | how can i depend my app on sailfishos version? Like Rquires=sailfishos >= 3.1.0.12 | 06:13 |
|---|---|---|
| ViGe | Why would you want to do that? | 06:17 |
| Mister_Magister | because i want to do that | 06:18 |
| Mister_Magister | my app could require some sfos version and above | 06:18 |
| Mister_Magister | becasue of the new feature or libs | 06:18 |
| ViGe | Then wouldn't it be better to require those? | 06:18 |
| Mister_Magister | you can't require then | 06:19 |
| Mister_Magister | them* | 06:19 |
| Mister_Magister | m'kay did this using sailfishsilica-qt5 dep | 06:34 |
| dcaliste | Hello chriadam, how are you ? | 07:06 |
| chriadam | hi dcaliste, I'm well thanks | 07:07 |
| chriadam | how are you? sorry I missed the meeting last Tuesday, I was out of the office that day and forgot :-( | 07:07 |
| chriadam | I hope that your vacation was nice (I believe you were on vacation the week before? or am I misremembering) | 07:07 |
| dcaliste | No problem, I had one week vacation before indeed. | 07:08 |
| dcaliste | Many things on the fxing front last weeks. We may do a review: | 07:10 |
| dcaliste | - kcalcore, https://git.sailfishos.org/mer-core/kcalcore/merge_requests/10, not a real issue, except for the icalconverter export tool. | 07:10 |
| chriadam | let me check | 07:11 |
| dcaliste | I've exported my full calendar to import it on a openxchange server online, a notice that some events were generated with an invalid DTEND. | 07:11 |
| dcaliste | This was due to setDtEnd(QDateTime()) in incidencehandler that didn't remove the dt end but was setting at an invalid date time. | 07:12 |
| chriadam | LGTM also, I wonder if flypig has time to merge and tag that one today? otherwise I will do so tomorrow | 07:12 |
| dcaliste | Ok, thanks. | 07:13 |
| dcaliste | Let's move up-stack… | 07:13 |
| dcaliste | - mkcal, https://git.sailfishos.org/mer-core/mkcal/merge_requests/25 about not setting the lastModified field automatically. | 07:14 |
| dcaliste | pvuorela suggested to use the same scheme as for dateCreated, if set use it, if not set set it at current. | 07:15 |
| dcaliste | I think it's a good idea to keep the same behaviour than current. I can make the change if you agree also. | 07:15 |
| chriadam | let me check | 07:17 |
| chriadam | so with the behaviour Pekka is suggesting, how does the user set a last modified time? just set it to a non-invalid dt? | 07:22 |
| chriadam | otherwise the backend will automatically set one if the lastModified time is currently invalid dt? | 07:22 |
| dcaliste | Exact. | 07:22 |
| chriadam | ok, sounds like a good compromise to me too | 07:22 |
| dcaliste | If the event is already in a calendar, the callback from the calendar will update the lastModified value at each modification, like setSummary(). | 07:23 |
| chriadam | i.e. manually / explicitly? | 07:23 |
| dcaliste | For new event, the lastModified field is set automatically if not set, otherwise the user value is iused. | 07:23 |
| dcaliste | For calendar event, this is done automatically by a listener created in the ExtendedCalendar object. | 07:24 |
| dcaliste | code path: | 07:24 |
| dcaliste | setSumarry() will call updated(). | 07:24 |
| dcaliste | updated() will call incidenceUpdated() for each observers (the ExtendedCalendar is a CalendarObserver). | 07:25 |
| dcaliste | and incidenceUpdated() in ExtendedCalendar is calling setLastModified(currentDateTime()). | 07:25 |
| chriadam | great. | 07:26 |
| chriadam | I guess that makes sense for any explicit user modification. | 07:26 |
| chriadam | just doesn't make sense to do it for automatic updates like syncs etc. | 07:26 |
| chriadam | which your PR will fix | 07:26 |
| dcaliste | So yes, any call to set*() methods will change the lastModification date time. The change is that the storage will _not_ change it on save, as it is done now, _except_ if the event does not have a valid lastModfied field yet. | 07:27 |
| dcaliste | Yes, this MR is to remove the check for spurious modification due to etag changes in caldav. | 07:27 |
| chriadam | so we just need to make sure that when the user explicitly modifies an event (e.g. in the calendar application) that we explicitly modify lastModification date prior to calling save? | 07:29 |
| chriadam | or maybe it already does that, if I remember correctly? | 07:29 |
| dcaliste | No probelm for existing workflow in calendar app (I've tested it btw), it's handled by the observer stuff. And for new event, it will be handled by pvuorela modification. | 07:30 |
| chriadam | cool | 07:31 |
| dcaliste | Great, so I'll ping later when I've done suggested modifications. | 07:33 |
| dcaliste | - mkcal, https://git.sailfishos.org/mer-core/mkcal/merge_requests/24 about the issue with all day event when changing time zone. | 07:33 |
| dcaliste | It's an ugly patch, but it's supposed to do the job. | 07:34 |
| chriadam | last comment suggests that there is some issue with nemo calendar - can you elaborate? | 07:35 |
| dcaliste | I think the question of pvuorela was about the case when having an exception given without time zone. (this is not possible to be done currently in ui because all date time are always with a tz, the local one). | 07:39 |
| chriadam | I see. can a synced exception occurrence event have this clocktime timespec? | 07:40 |
| dcaliste | In that case, the test to detect if all day (see the changes) will indeed not work but the date time will be in that case exactly what it will be transformed into if detected as all day… | 07:42 |
| dcaliste | So clock time spec with 00:00 time should work, in my opinion. | 07:42 |
| dcaliste | Even when coming from sync. | 07:42 |
| chriadam | great | 07:43 |
| chriadam | my original opinion was that we should merge that change, so I have no issues with that still | 07:43 |
| chriadam | I see flypig also approved | 07:43 |
| dcaliste | Ok, thanks. | 07:43 |
| chriadam | I will merge and tag tomorrow unless flypig has time to do so today | 07:44 |
| dcaliste | - buteo caldav, https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/50 some correction to issue due to early save to storage for etags. | 07:45 |
| dcaliste | The notebook pointers are not safe because any modification to the storage is creating new pointers to notebooks, even for unchanged ones. | 07:46 |
| dcaliste | So, when using a notebook pointer to change it, we get it from storage first. | 07:46 |
| chriadam | LGTM too, I checked that one last week but forgot to merge tag | 07:47 |
| chriadam | again, will do so tomorrow | 07:47 |
| dcaliste | Cool. | 07:47 |
| chriadam | sorry for being the bottleneck here! | 07:47 |
| dcaliste | - buteo caldav, https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/49 some issue fixed with HTML entites from SoGo servers. | 07:48 |
| chriadam | ah we discussed this last time IIRC. I was meant to merge that one too | 07:48 |
| chriadam | also #43 | 07:49 |
| chriadam | that one also requires the settings-accounts PR IIRC | 07:49 |
| chriadam | will merge those two tomorrow also. | 07:50 |
| chriadam | did Jaymzz contact you about the blog post yet? I haven't heard anything more from him since two weeks ago actually | 07:50 |
| chriadam | when he said it might be delayed, presumably due to his vacation or whatever | 07:51 |
| dcaliste | Great for #43, it would be a nice addition (not just bug correction) ! It requires a patch in sailfish settings indeed. | 07:51 |
| dcaliste | About the blog post, yes Jaymzz contacted me and I provided him with a bio. I guess that it's going on, he will send proofs when ready. | 07:52 |
| dcaliste | He told me that you indicated to him how to enable (install) on device, so nice. | 07:52 |
| chriadam | great | 07:54 |
| chriadam | hopefully that doesn't take much longer to be published, then | 07:54 |
| chriadam | did you have anything else to discuss? | 07:55 |
| dcaliste | I didn't have time to update the email folder sync proposal after discussion with pvuorela. About caldav, I still have https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/45 that should be tested more before accepting it. | 07:57 |
| dcaliste | And also, hopefully we can reach an agreement on https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/27 | 07:58 |
| chriadam | oh let me check that one | 07:58 |
| dcaliste | About !45 in caldav, I'll rebase it when all other MR discussed will land, because it is containing some changes that have been included into more urgent MR like !50. | 08:00 |
| chriadam | ok, great. I will merge/tag those other ones tomorrow, so hopefully e.g. thursday you should be able to rebase cleanly | 08:01 |
| chriadam | for the syncfw one, I will defer to slava and pekka | 08:01 |
| chriadam | once they're happy, I am happy to merge/tag. I definitely agree that the bug needs to be fixed, so we should be pragmatic. | 08:01 |
| dcaliste | Indeed, last proposition is representing really minimal changes to existing code, and it's not waking me up in the night anymore ;) | 08:03 |
| *** frinring_ is now known as frinring | 08:03 | |
| dcaliste | Besides, thanks to pvuorela for accepting jolla-calendar patch to sync on update only modified calendar. | 08:03 |
| dcaliste | We can continue to discuss remaining MRs next week otherwise. Thank you for taking time to review. | 08:04 |
| dcaliste | Ah, forgot, there is this one also : https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/47 but definitely, we can discuss about it next week. Not in a hurry. | 08:05 |
| dcaliste | (implement sync direction for caldav plugin). | 08:05 |
| chriadam | sync direction | 08:09 |
| chriadam | yes we should fix that | 08:09 |
| chriadam | but maybe we can discuss it next week | 08:09 |
| chriadam | indeed | 08:09 |
| chriadam | dcaliste: thanks again for your hard work. sorry that I've been letting the ball drop a bit on these things in the last couple of weeks. should be back to normal next week with luck. I will merge those PRs we discussed tomorrow. | 08:10 |
| dcaliste | No problem, anyway 3.1.1 is not freezed as far as I know, so it's fine. Let's see next week what remains on the board. | 08:11 |
| chriadam | yep, have another week afaik for it. | 08:11 |
| chriadam | sounds good - have a great week! | 08:11 |
| dcaliste | Thanks, have a good night. | 08:11 |
| *** Renault_ is now known as Renault | 08:47 | |
| attah | /poke flypig | 18:19 |
| attah | Python sharing plugins, could that be a thing? | 19:24 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!