| *** zbenjamin is now known as Guest11354 | 02:34 | |
| *** zbenjamin_ is now known as zbenjamin | 02:34 | |
| *** frinring_ is now known as frinring | 07:02 | |
| dcaliste | Hello chriadam, I hope you're fine. | 07:56 |
|---|---|---|
| chriadam | hi dcaliste | 07:56 |
| chriadam | I'm well, thanks. how are you? | 07:56 |
| dcaliste | I'm fine, thank you. I guess you've been busy with debugging recently ? | 07:57 |
| chriadam | busy with a task related to contact search sorting | 07:58 |
| chriadam | iterated 2 separate prototypes which I threw away for various reasons before settling on the final solution | 07:58 |
| chriadam | result can be foudn in nemo-qml-plugin-contacts | 07:58 |
| chriadam | PR | 07:58 |
| chriadam | I haven't really had a chance to switch back to the mkcal/kcalcore thing in the last few days unfortunately | 07:59 |
| chriadam | I agree with your comment (that we shouldn't have one behaviour for one codepath, and different behaviour for the other) | 07:59 |
| chriadam | but wondering whether we can just identify those other cases and fix those also | 07:59 |
| chriadam | or whether, as you say, since we only call it from localtimezone perspective in calendar anyway, whether we should just ignore that complexity | 08:00 |
| chriadam | I've asked flypig whether he might not have time to take a look also, while I finish off that contact search sorting task | 08:00 |
| flypig | I'll take another look today. It takes me a while to get my head around it though. | 08:01 |
| dcaliste | I don't know, I'm also wondering how this can go with upstream also where there is no ClockTime thingies, just a LocalTime zone. It seems to me that what we're trying to fix is coming fropm tests only but as I said won't happen i practice. | 08:02 |
| dcaliste | We should rewrite the tests we have with expansion time zone as local zone and see what is breaking. | 08:02 |
| chriadam | hmm, but then we risk having tests fail or pass depending on which timezone they are run in, doesn't it? | 08:03 |
| Aard | s | 08:03 |
| dcaliste | It makes the writing of the tests a bit flacky, because we never know where the tests will be run. | 08:04 |
| dcaliste | ;) | 08:04 |
| dcaliste | Indeed, we need to design the test with the idea in mind that it may be run in a different timezone. | 08:04 |
| chriadam | I guess so long as we run them in enough timezones (e.g. Pacific/Midway + France/Paris + Europe/Helsinki + Australia/Brisbane) then we can be "reasonably sure" | 08:04 |
| chriadam | America/Toronto | 08:05 |
| dcaliste | Testing it is quite easy, just switch the device in a different time zone. | 08:05 |
| chriadam | yes | 08:05 |
| dcaliste | And when switching to QDateTime, just adjust the env variable TZ= | 08:05 |
| dcaliste | Which will make the tests to be run in different time zones at once with qsetenv(). | 08:06 |
| chriadam | what is the env var for? | 08:06 |
| chriadam | ah.. | 08:06 |
| dcaliste | Doesn't work with KDateTime :( | 08:06 |
| chriadam | true | 08:06 |
| dcaliste | I'm trying to push https://phabricator.kde.org/D25289 upstream, to avoid the regression of floating time events to be read as systemTimeZone. | 08:08 |
| chriadam | dcaliste: I saw that, hopefully there is fruitful conclusion | 08:08 |
| chriadam | thanks for doing that! | 08:08 |
| dcaliste | Yeh, I'm wondering how korganizer is handling such events currently… | 08:08 |
| dcaliste | Trying to prepare the transition to upstream, checking that every piece can match… | 08:09 |
| chriadam | no idea... I suspect it's just broken, and some client (maybe akonadi or so) has workarounds | 08:09 |
| dcaliste | Speaking about workaround… | 08:09 |
| chriadam | huge amount of work you've been doing, I am very grateful. | 08:09 |
| dcaliste | …why in icalformat_p.cpp in kcalcore we have this define at line 302 ? | 08:10 |
| dcaliste | #if !defined(KCALCORE_FOR_MEEGO) | 08:10 |
| dcaliste | // +1 day because end date is non-inclusive. | 08:10 |
| chriadam | oh gawd | 08:11 |
| chriadam | nfi | 08:11 |
| chriadam | I guess it's trying to match rfc semantics | 08:11 |
| dcaliste | It is not symmetric, on read we're not substracting one, but on write we're adding one. | 08:11 |
| chriadam | where an all-day event's dtend is +1 or something | 08:11 |
| dcaliste | It is adding a lot of confusion a(and code) in Caldav plugin. | 08:11 |
| chriadam | yeah | 08:11 |
| chriadam | so many things like that where I should have fixed mkcal / stack, but instead I just added workarounds in plugins | 08:12 |
| dcaliste | Sorry, reverse : | 08:12 |
| chriadam | because I didn't want to touch the underlying stack code if I could avoid it. in retrospect, was definitely a mistake | 08:12 |
| dcaliste | we're substracting one when reading… | 08:12 |
| dcaliste | … but _not_ adding one when writing. | 08:12 |
| dcaliste | So Caldav needs to add one by hand… | 08:13 |
| chriadam | dcaliste: that makes more sense. we get the +1 date from the ics (due to rfc semantics) | 08:13 |
| chriadam | oh wait... although surprised that we have to add one in caldav case, unless we already 'accounted' for the rfc exclusive dtend semantics, somewhere else in code | 08:13 |
| dcaliste | Confusion : here it's a _!_defined | 08:14 |
| chriadam | oh | 08:14 |
| dcaliste | So currently, kcalcore is _not_ adding one and thus is violating semantics. | 08:14 |
| chriadam | sigh. | 08:14 |
| dcaliste | So, Caldav fix it by adding one itself. | 08:14 |
| dcaliste | What about killing this #if !defined and fix Caldav and probably exchange or google sync plugins ? | 08:15 |
| chriadam | yes, I think we should | 08:15 |
| chriadam | but... not this week | 08:15 |
| dcaliste | ;) | 08:15 |
| dcaliste | No problem. | 08:15 |
| chriadam | let's discuss again next week ;-) | 08:15 |
| dcaliste | I'm cleaning incidencehandler in Caldav and removing all code for fixes that have been already implemented in mkcal or kcalcore. | 08:16 |
| dcaliste | Did you remember why a copy was implemented there, and why not use the Incdence::assign() or operator=() ? | 08:17 |
| chriadam | I don't... | 08:17 |
| dcaliste | Was it because it is also copying the UID and we should keep our NBUID stuff ? | 08:18 |
| chriadam | possibly? I don't remember any of that stuff honestly. | 08:18 |
| dcaliste | Because I didn't see any difference beside this one, but I may have miss something, because many members values are copied. | 08:18 |
| dcaliste | Ok, so I'll continue to replace it with operator=() and see if it breaks somewhere. | 08:19 |
| chriadam | sounds good | 08:19 |
| dcaliste | (I'm copying NBUID before so this is not an issue per se). | 08:19 |
| dcaliste | I knwo you're busy, and of course we can discuss further next week, but I've finally settle myself with an API change for real deletion in storage : https://git.sailfishos.org/mer-core/mkcal/merge_requests/30 | 08:20 |
| chriadam | I haven't looked at that one, but I'm all for it | 08:21 |
| dcaliste | It is basically adding two methods depending what you want to purge from the database : | 08:21 |
| dcaliste | - remove incidences that hjave been marked as deleted when calling save(). | 08:21 |
| chriadam | storage->save() now takes a "purge deleted" flag, right? | 08:22 |
| dcaliste | Exactly. | 08:22 |
| chriadam | yup, makes sense | 08:22 |
| dcaliste | It is working only for incidences that have been marked as deleted in "this session". | 08:22 |
| dcaliste | Not incidences that are already marked as deleted in the database. | 08:22 |
| chriadam | ah, interesting.. | 08:23 |
| chriadam | even if you load incidences into the calendar? | 08:23 |
| dcaliste | Yes, because deleted incidences cannot be loaded in a calendar. | 08:23 |
| chriadam | agh | 08:23 |
| dcaliste | We can only list them with deletedIncidences(). | 08:23 |
| dcaliste | Thus the second function : | 08:23 |
| dcaliste | to purge a list of already deleted incidences. | 08:24 |
| dcaliste | This list can be easily built from the return of deletedIncidences(). | 08:24 |
| chriadam | cool | 08:24 |
| dcaliste | Yeh, I think it is covering well the need in caldav plugin (and webcal also) : | 08:25 |
| dcaliste | - mark as deleted and purge the incidences that have been deleted on server. | 08:25 |
| chriadam | great | 08:25 |
| dcaliste | - list deleted incidences and purge the ones that the server aknowledge deletion. | 08:25 |
| dcaliste | And the db stay clean ;) | 08:26 |
| dcaliste | The calendar UI is marking the incidences as deleted as usual without code change. | 08:26 |
| dcaliste | And as a bonus, the custom properties are not deleted when an incidence is marked as deleted. | 08:27 |
| chriadam | woohoo ;-) | 08:27 |
| dcaliste | Thus, we can have access to URL and etag for mark-as-deleted incidences. | 08:28 |
| chriadam | yep :-) | 08:28 |
| dcaliste | Besides, they have added in kcalendarcore upstream a member URL for an incidence. | 08:29 |
| chriadam | ah, nice. | 08:30 |
| dcaliste | When switching to upstream, we'll have to aklter the component table to add this info :/ | 08:30 |
| chriadam | yep | 08:30 |
| chriadam | although I thought there was a URI one already? | 08:30 |
| chriadam | field* | 08:30 |
| chriadam | or is that different? | 08:30 |
| dcaliste | Yes, but it has a different meaning. | 08:30 |
| dcaliste | ;) : | 08:30 |
| chriadam | dang | 08:30 |
| dcaliste | URI is to identify the incidence uniquely (hopefully), and is just something klike ical://UID | 08:31 |
| chriadam | right, I see. | 08:31 |
| dcaliste | It's not about it's location. | 08:31 |
| dcaliste | (not geo location…) | 08:31 |
| dcaliste | Thus the addition of the URL member. | 08:31 |
| chriadam | true. well, adding a field should hopefully be simple | 08:32 |
| dcaliste | Yeh, we'll see at that moment if we're using a oneshot or a alter in kcal directly. | 08:32 |
| dcaliste | s/kcal/mkcal/ | 08:33 |
| chriadam | either sounds fine, I agree let's see. | 08:34 |
| chriadam | dcaliste: I have to head off in 5 mins unfortunately - was there anything high priority you'd like me to follow up on? | 08:34 |
| dcaliste | No it's fine, we've discussed the various things at hand. Thank you for taking from your busy schedule currently. | 08:34 |
| chriadam | no, thank you for your time and effort as always! | 08:34 |
| chriadam | much appreciated | 08:35 |
| chriadam | I hope you have a good week! | 08:35 |
| dcaliste | Thanks, I wish you too. | 08:35 |
| *** b_lindeijer is now known as bjorn | 09:54 | |
| Ingvix_ | Hey, might someone know what's the path of default localstorage database location in sfos? | 11:47 |
| Ingvix_ | I need to go remove some corrupted data | 11:48 |
| abranson | Ingvix_: storage for what? contacts/calendar etc are under /home/nemo/.local/share/system/privileged | 11:52 |
| Ingvix_ | Alright, I just did a search for directories named OfflineStorage and realized they are app-specific but now I know where they are. Thanks anyway | 11:54 |
| *** Snoras_ is now known as Snoras | 14:28 | |
| Krikke | hey, is there a faster way to switch between prefer 4G and prefer 3G than through the settings? like some plugin for the top menu. Thanks. | 15:47 |
| Tegu | hm, if you find a way, I'm curious as well | 15:49 |
| Krikke | I have to do it constantly to save battery | 15:50 |
| Tegu | you probably know that you can hold the mobile data icon on the top menu and go to the mobile settings from there. but takes a few steps | 15:50 |
| Krikke | and it's a real pita atm | 15:51 |
| Tegu | save battery? | 15:51 |
| Krikke | you can what? | 15:51 |
| Krikke | lol again these hidden features | 15:51 |
| Tegu | :D | 15:51 |
| Krikke | I didn't know that | 15:52 |
| Tegu | indeed, very jolla style | 15:52 |
| Krikke | thanks | 15:52 |
| Tegu | just try to press and hold everything although it gives no visual hints :D | 15:52 |
| Krikke | yeah I was testing it out | 15:53 |
| Krikke | was wondering why you couldn't add them to top menu shortcuts | 15:53 |
| Krikke | also bluetooth | 15:53 |
| Krikke | well 4G drains 20% battery over night, 3G only 10% | 15:54 |
| Tegu | oh, interesting | 15:54 |
| Krikke | yes very | 15:55 |
| Tegu | I kinda was under impression that 3G isn't really energy-efficient | 15:56 |
| Tegu | but on the other hand, I don't really know much | 15:56 |
| Krikke | there's some bug in sfos | 15:56 |
| Krikke | works fine on X | 15:56 |
| Krikke | XA2 has some bug | 15:57 |
| Tegu | too bad :/ | 15:58 |
| Krikke | yeah well, seems they're too busy with porting to xperia 10 to have time to fix real issues | 15:59 |
| Tegu | yea, saw the blog post. wonder how many bugs that device will have | 16:00 |
| Tegu | hopefully not too many | 16:00 |
| Krikke | I don't care, onna get 5G when it's available | 16:01 |
| *** albertux1 is now known as albertux | 16:33 | |
| *** Snoras_ is now known as Snoras | 18:46 | |
| Simerax | Anyone knows if there is a way to use the "WeekDaySelector" from the standard jolla-clock application? | 21:25 |
| Simerax | nvm found it | 21:36 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!