| *** zbenjamin is now known as Guest17446 | 02:57 | |
| *** zbenjamin_ is now known as zbenjamin | 02:57 | |
| dcaliste | Hello chriadam, how are you ? | 08:10 |
|---|---|---|
| chriadam | hi dcaliste, I'm well, thanks. I hope you had a great vacation | 08:10 |
| dcaliste | Yep, it was really nice, thanks. | 08:11 |
| chriadam | that's good! | 08:12 |
| chriadam | I haven't had a chance to re-test the caldav sync direction PR yet unfortunately | 08:12 |
| dcaliste | No problem, I guess ironing out the latest version took its time ! | 08:13 |
| chriadam | but I saw that pvuorela merged the mkcal custom properties for notebook PR | 08:13 |
| chriadam | yes, still ongoing with fixing bugs and whatnot for release. that never ends I guess ;-) | 08:13 |
| dcaliste | Did he ? I was thinking he was about to do it… Checking. | 08:14 |
| dcaliste | Oh indeed, I missed it. | 08:14 |
| dcaliste | Great. | 08:14 |
| chriadam | we still need to take that into use in various places, but at least that's possible now :-) | 08:15 |
| dcaliste | I will use it in CalDAV plugin and webcal one. Good, good. | 08:15 |
| dcaliste | I've looked again at mkcal!17, without happy ending :/ Still creating issues with existing behaviour when trying to clean up all day handling. | 08:16 |
| chriadam | what sort of issues? if some change fixes various issues but causes a behaviour break for some edge case, it may be fine (e.g. we pay that cost, for the overall improvement) but depends on the issues I guess | 08:17 |
| dcaliste | Something that was detected as a all day recurring rule is not detected anymore as one, or things like that. I still need to work on this with the target to have a saner handling of all day (using the incidence or rule allDay() instead of KDateTime one) but keeping the old behaviour as much as possible. | 08:20 |
| dcaliste | This will become mandatory when moving from KDateTime to QDateTime. | 08:20 |
| chriadam | right | 08:20 |
| dcaliste | Hopefully, I should end up with some backward compatibility code only in the "read" part and well confined in the code. But not yet there… | 08:21 |
| chriadam | cool | 08:22 |
| dcaliste | An example of what is breaking currently is: | 08:22 |
| dcaliste | a incidence (or recurrence rule) was defined with the old scheme (thinking of the recurrence exception date time provided by nemo-qml-plugin-calendar when defining an exception) but is stored with the proper new way. | 08:23 |
| dcaliste | Meaning it is defined with time = (0:0) in ClockTime time spec. | 08:24 |
| dcaliste | But new scheme stores it with DATE_ONLY timezone special flag. | 08:24 |
| dcaliste | When restored, it is saved as KDateTime date only and thus the operator()== is failing. | 08:25 |
| dcaliste | Which makes the calculation of repeated incidences to display in the calendar with the exception to fail. | 08:25 |
| dcaliste | Because the exception is not == to the generated recurring ocurrences… | 08:26 |
| dcaliste | That kind of issues. | 08:26 |
| chriadam | what do you mean by "when restored"? | 08:27 |
| dcaliste | When reread from storage. | 08:29 |
| chriadam | ok. so, basically, it's not fully round-trip stable, because it is "given" as clocktime 00:00, but returned in slightly different format (due to DATE_ONLY with QDateTime, vs KDateTime with clocktime spec difference?) | 08:30 |
| chriadam | can we "reliably" migrate existing rrules in the database, and update nemo-qml-plugin-calendar to fix its assumptions? | 08:31 |
| chriadam | and then just transition to the new format, altogether? or am I misunderstanding | 08:31 |
| dcaliste | You understand properly I think. I'm not sure yet that migrating the existing databases is the right solution. I need to investigate more the calculation of ocurrences and handling of exceptions to see if we can patch there instead. | 08:32 |
| dcaliste | All this to conclude that mkcal!17 still requires further work ;) | 08:33 |
| chriadam | yep :-) all good, thank you very much for your work there | 08:34 |
| chriadam | regarding the j-s-a PR for email folder selection, I think that one has just been approved internally for more work, so I think that you should see that one progress faster on our side (reviews/design/testing/etc) shortly. | 08:34 |
| dcaliste | Ok nice. pvuorela commented also on the webcal MR and I still need to address his remarks. | 08:35 |
| dcaliste | And move the current proposed code from calendar app to account settings. | 08:35 |
| chriadam | ah was that the decision there? | 08:36 |
| chriadam | ok cool | 08:36 |
| dcaliste | I think the consensus is to put the subscription handling under the account pages (even if under the hood we're not creating any account, just a sync profile). | 08:37 |
| chriadam | fair enough. seems a bit strange to me, but the designers know what they're doing :-) | 08:38 |
| dcaliste | I've been also looking at making ExtendedCalendar from mKCal to inherit MemoryCalendar from KCalCore. I've noticed that they are sharing a lot of code (almost 1000 lines). It's a WIP and I need to move some lines into KCalCore. | 08:38 |
| dcaliste | It would reduce the maintainance burden of mKCal a bit and move this burden upstream to KDE since KCalCore is now part of Framework5 stuff. | 08:40 |
| chriadam | ah great! | 08:40 |
| chriadam | did that one change much in upstream kcalore? | 08:40 |
| dcaliste | No, it's almost as is as far as I've seen. | 08:40 |
| dcaliste | Total guess here, but I think it's not much used at all by calendar projects in KDE. I guess they are inheriting from Calendar class directly. | 08:41 |
| chriadam | indeed | 08:42 |
| dcaliste | As I see it, MemoryCalendar is a slight simplification of ExtendedCalendar when Core and mobile were separated. | 08:42 |
| chriadam | definitely good to remove code duplication where possible, thanks | 08:42 |
| dcaliste | But since MemoryCalendar is in KCalCore, it's interesting to use it, I think. | 08:42 |
| dcaliste | The only drawback that may have importance is that internal QMaps are not accessible anymore directly, and thus we're creating copies a lot by using .values(). | 08:44 |
| dcaliste | And iterating over .values(). | 08:44 |
| chriadam | const copies? if so, cost is negligible due to implicit sharing | 08:44 |
| dcaliste | At the same time, it's only QSharedPointers, so copies should be lightweight. | 08:44 |
| chriadam | yep | 08:45 |
| dcaliste | Yeh, I tried to use const whereever I can and use std:: functions like copy_if() and firends instead of looping by hand. | 08:45 |
| chriadam | great - I'd guess that the quality of code you are writing is higher than the rest of kcalcore anyway, due to its age anyway | 08:46 |
| chriadam | so it may be that there are massive perf bottlenecks unrelated to this | 08:47 |
| chriadam | i.e. I wouldn't worry about it too much unless benchmarks show that it is causing some actual problem | 08:47 |
| dcaliste | The new upstream is much cleaner to that respect. Many parts have been cleaned or rewritten. | 08:47 |
| chriadam | that's good | 08:47 |
| dcaliste | Yeh, but the jump will cost a lot in SailfishOS… | 08:48 |
| chriadam | let's cross that bridge when we get there :-D | 08:48 |
| dcaliste | When you have time, can you review caldav!51 ? | 08:48 |
| dcaliste | You already looked at it. It's to report the number of added/modified/deleted entries in the logs. | 08:49 |
| dcaliste | It's not yet exposing the error string to the user or even in the log, but it's also cleaning some places where these strings are reported. | 08:49 |
| chriadam | ah, yes | 08:50 |
| chriadam | I will do so this week | 08:51 |
| chriadam | and follow up on the sync direction one also | 08:51 |
| dcaliste | Thanks. | 08:51 |
| chriadam | I didn't have anything else to discuss - was there anything else you wanted to discuss? | 08:52 |
| chriadam | blog post - I haven't heard anything more from Jaymzz yet. I guess making TJC post might be best after all :-/ | 08:52 |
| dcaliste | Finally, for the caldav plugin, I've also a WIP branch where I've changed the Q_FOREACH() loops by c++11 for(x:y) ones. Trying to respect the const this to avoid copies. | 08:52 |
| chriadam | ah cool. without the qAsConst() macro from more recent Qt, are you doign something similar, or? | 08:53 |
| dcaliste | I've used a const_cast<Foo>() when needed. | 08:54 |
| chriadam | cool, cheers | 08:54 |
| dcaliste | Jaymzz mailed me to explained to me the reason why it's lagging. | 08:54 |
| chriadam | ah great | 08:55 |
| chriadam | hopefully it is resolved soon then | 08:55 |
| dcaliste | Some political implications that he has no traction on ;) | 08:55 |
| chriadam | :-( | 08:55 |
| dcaliste | He told me it should ease after the blog post for 3.2.0 is out. Let's wait. | 08:56 |
| Nico[m] | I think there is also a stf::add_const, that doesn't require you to specify thr type | 08:56 |
| chriadam | nice one | 08:57 |
| dcaliste | Nico[m] the documention mentioned something about std::const I think or sometiing similar, but it's c++14. | 08:57 |
| Nico[m] | No idea if the sailfish gcc supports that thouvh | 08:57 |
| Nico[m] | Ah, yeah, that could be an issue | 08:57 |
| dcaliste | I tried, but it complained. I didn't dig further to see if it's because I didn't mention c++14 in the makefile, or if it's due to gcc 4.9. It was working with const_cast<>() so I staied on that. | 08:58 |
| Nico[m] | Sure, in that case const_cast is good enough | 08:59 |
| dcaliste | chriadam, I think time is running late for you. Have a nice week and see you later. | 08:59 |
| chriadam | dcaliste: thanks very much for your hard work as always | 09:00 |
| chriadam | dcaliste: have a great week! | 09:00 |
| dcaliste | No problem, still fun ! Thanks. | 09:00 |
| *** vilpan is now known as Guest71954 | 09:20 | |
| *** Guest71954 is now known as vilpan | 09:22 | |
| *** frinring_ is now known as frinring | 10:08 | |
| *** vilpan1 is now known as vilpan | 13:35 | |
| *** Renault_ is now known as Renault | 13:58 | |
| Krikke | finally | 14:18 |
| *** vilpan1 is now known as vilpan | 14:21 | |
| adantes | hi | 18:42 |
| adantes | Why is it that sysmon accuses some cpu activity, battery drain activity, during the night, when al the comms are off, android procceses stoped | 18:43 |
| adantes | xa2 ultra, sailfish 3.1 | 18:43 |
| adantes | is it going the Android | 18:44 |
| adantes | / ios path? | 18:44 |
| adantes | where turned off is just a way of saying.. | 18:44 |
| mal | adantes: can you show some more information, any indication what is using cpu? | 18:46 |
| adantes | mal: thanks for the repy.. nope, i jus wake in the morning, look at the latest 8h activity, and some 4% of battery draining | 18:49 |
| adantes | does anyone suggest a way of monitor this? | 18:49 |
| adantes | today Ill try put in flight mode | 18:50 |
| attah | Whoa.. that gave me a good scare. For whatever reason trhe GUI didn't load completely on first boot after upgrade... and obviously this was the first time in years i hadn't done a backup | 18:57 |
| r0kk3rz | oh update, cool | 22:13 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!