Tuesday, 2020-12-01

*** zbenjamin is now known as Guest3235902:03
*** zbenjamin_ is now known as zbenjamin02:03
*** frinring_ is now known as frinring06:43
dcalisteHi chriadam, how are you ?07:58
chriadamhello dcaliste, I'm well thanks - how are you?07:59
dcalisteI'm fine thank you. I've seen you started to migrate some of the calendar code to upstream KCalendarCore. What do you think of it ?08:02
dcalisteI've made some comments in your WIP for Google sync plugin.08:02
chriadamI have started, yes - lots more work to do yet, as so far I've just done "mechanical" passes, without thinking too much about things :-)08:02
chriadamI saw your comments - thanks for that - I haven't yet had time to digest those08:03
chriadamthe "all day" one needing a separate flag seems fine08:03
chriadambut I still wonder about the ClockTime one08:03
chriadame.g. if I am a creature of habit, and want to have lunch at exactly 12:30 pm every day, no matter which country I am in08:03
chriadamwhat do we do in that case?  in the past, I'd have expected us to have saved an event with a dtStart of 12:30 in ClockTime spec08:04
chriadamwhereas now, I think it might get saved as LocalTime (i.e. whatever the system time zone is, when I save the event), and then I would expect that it might get transformed to different time when I travel to a different tz08:04
chriadambut I might be mistaken / misunderstanding08:04
dcalisteThis case is the simple one, in my opinion. Old ClockTime spec converts to LocalTime, mechanically.08:04
dcalisteThen, Qt when doing time comparison for a LocalTime spec is always using the system time zone, whatever zone you are in.08:05
dcalisteI mean that if your in Paris zone, it will say 11:30 UTC.08:05
dcalisteBut you travel to Vietnam, the same event will convert to 6:30UTC.08:06
chriadamwhat do you mean by "the event will convert" in this case?  (e.g. the event I previously saved?)08:07
dcalisteI mean, that a QDateTime(QDate(...), QTime(12,30), LocalTime).toUtc() will give this.08:07
chriadamok - interesting, so it's basically identical in semantics to the old KDateTime ClockTime spec?08:08
dcalisteThen, in mKCal, this event is saved *without* the timezone info as a floating date time, so it is reread as a LocalTime spec.08:08
chriadamright08:08
chriadamok, nice.08:08
dcalisteYes, this one can be convert mechanically from ClockTime to LocalTime.08:09
chriadamso what about when I _do_ want to specify a specific timezone for the event (e.g. call with my mother every Saturday at 7pm in my current local time zone (which happens to be AEST = GMT+10)) -> in this case when I travel to New Zealand I want the event to be not LocalTime but still AEST/GMT+10 etc08:10
chriadamI guess I will just have to double check how we use LocalTime in the code, and ensure that we use LocalTime for those cases which are meant to be ClockTime, but use some specific non-LocalTime timespec for the other cases?08:10
dcalisteThe one that needs to look at is the LocalZone old spec. 99% of the time is will convert to a TimeZone spec with the systemtime zone. But I think that 1% of the cases, it has been misused as a ClockTime meaning.08:11
dcalisteFor your example, you create a QDateTime(..., QTimeZone::systemTimeZone()) and you will be fine.08:11
dcalistemKCal will save the time zone and restore it or read. So if you travel to another timezone, the time will still be the same in absolute but will be a different one on your clock.08:12
dcalisteThat's why I think the LocalZone spec was removed from QDateTime, because it is redundant with the TimeZone spec and misleading with the ClockTime because does it mean "time zone at creation time" or "always system time zone".08:13
dcalisteAnd I think that's what we need to check during the migration because 99% of the cases, the code is written with the LocalZone spec.08:14
dcalisteUp to us to know if it means "time zone at creation time" -> TimeZone spec or "always system time zone" "always system time zone" -> LocalTime.08:15
chriadamthat makes sense.08:17
chriadamthank you for the in-depth explanation08:17
chriadamI am now certain that I did some of those wrongly at least in my sailfish-eas migration so far08:17
dcalisteIt took me litteraly years to get this ;)08:17
dcalisteBut once I grasp the idea, it looks quite simple and logical.08:18
dcalisteAbout the migration, I noticed you worked on nemo-qml-plugin-calendar, but I did it also : https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/3808:18
dcalisteBut I must admit that I need to redo it anyway, because it was done as a first attempt a long time ago when these spec considerations were totally unclear to me.08:19
chriadamyeah I started looking at that one but it didn't even rebase cleanly08:19
dcalisteSo don't take this one as an example yet :/08:19
chriadamand I figured it would probably be quicker for me to just do it from scratch08:20
chriadamagain, I just did a mechanical pass so entirely likely that I messed things up08:20
chriadambut it builds, at least.  shrug.08:20
chriadamjust to double check that I understood correctly:08:22
chriadam1) if I want an event like "lunch is at 12:30 pm every day, regardless of current timezone" then that is QDateTime(date, 12:30, Qt::LocalTime);08:23
chriadam2) if I want an event like "call my mother at 7pm (current timezone, AEST)" then that is QDateTime(date, 19:00, QTimeZone::systemTimeZone())08:23
chriadam?08:23
dcalisteTotally Exact.08:23
chriadamgreat, thanks.08:23
chriadamanother thing I noticed: some methods to parse timezone info are now not exposed by kcalcore08:24
dcalisteYeh, another colateral damage to the migration : KCalendarCore does not allow user defined timezone anymore.08:25
dcalisteThey just allow the system ones.08:25
chriadamspecifically, relating to (windows/eas) TIME_ZONE_INFORMATION struct stuff.  it's not a problem -> I've implemented some parsing and conversion stuff in sailfish-eas now.  but it's slightly different08:25
chriadamyes, like you say -> no longer a "custom" timezone, but instead, I now try to "detect" which QTimeZone is "closest" and use that08:25
dcalisteNormally KCalendarCore still do this internally, in this way if I remember correctly:08:26
chriadammy conversion / detection code is a bit funky because the exchange tz struct only supports a single transition (i.e. standard + daylight), whereas QTimeZone supports arbitrarily many transitions etc.08:26
dcaliste- if the system has a matching name with a system one, the system one override the user defined time zone.08:27
dcaliste- if no time zone in the system is matching the name, then the user defined time zone is parsed and its definition is compared to all system time zones. if one matchs, it is returned.08:27
dcaliste- if none match, a warning is raised (or an error ?).08:28
chriadamis there some API to access that?  what do I pass in, a VTIMEZONE component? or?08:28
dcalisteSo you can still have a VTIMEZONE ical entry, but has long as its name is in the system, the content is ignored.08:28
dcalisteYes, you can create an arbitrary calendar with this VTIMEZONE entry and see which time zone is returned for your calendar.08:29
chriadamin my case, I would have to build a VTIMEZONE component and fill it out with the transition info described in the TIME_ZONE_INFORMATION struct, I guess.  but better to let kcalcore do it once (properly) than me to reimplement the "detection" logic, I think.08:29
dcalisteParse the forged ICS calendar with the usual icalformat methods from KCalendarCore.08:29
chriadamthanks, I will investigate08:30
dcalisteThey try to match the windows names also if I remember correctly, let me give you the line number...08:30
dcalistehttps://invent.kde.org/frameworks/kcalendarcore/-/blob/master/src/icaltimezones.cpp#L51008:31
dcalisteThis method is using the icalTz.id to see if QTimeZone knows about this name.08:32
dcalisteThen tries with windowsIdToDefaultIanaId().08:32
chriadamif both of those fail (e.g. because the names we receive from this struct are not "proper" windows tz id values, but instead some display name / old identifier due to version of activesync we support, then it will fall down to the bottom loop08:35
chriadamin that case, it will fill out the icalTz.standard+daylight values via parsePhase()08:35
dcalisteYes, and then the match is done in the parent in https://invent.kde.org/frameworks/kcalendarcore/-/blob/master/src/icaltimezones.cpp#L43308:35
chriadammy brain is too small.  that resolveICalTimeZone() method seems strange to me08:38
chriadam++matchedTransitions;  --> but I don't understand how the match was determined.  it never compares the offsets08:39
chriadamoh, wait, it only compares timezones which match the phase.utcOffset.  never mind.08:39
chriadamhmm.  it checks icalZone.standard, but ignores the icalZone.daylight ?  I must be misunderstanding08:40
dcalisteNever read it in details myself, just imagined it should try to match the user defined transition with the known ones from the system...08:40
dcalisteI think it's very seldom used in KDE case, because most names are standard anyway and available on the system. So it may be buggy.08:41
chriadammore likely I'm just misunderstanding08:42
chriadamthere is a: const auto &transition = *it; there -> now that transition struct might contain the offsets of what it is transitioning to, not just the date of the transition08:42
chriadambut without knowing the type of "transition" there (because they use auto) I can't ... immediately tell from reading the code08:43
dcalisteIsn't candidate.transitions contaning both standard and daylight saving ones ?08:43
dcalisteI don't know what the abbreviation means in that context.08:43
dcalisteMaybe it contains the type information also...08:44
chriadamwell, I trust it more than I trust my own hand-rolled code.  and if something starts to fail, I will look deeper.08:44
chriadamI will just need to port the unit test we had in mkcal, and put it in sailfish-eas instead (i.e. to test that the mstz definition is handled properly when creating the mkcal event)08:44
chriadamall good :-)08:45
chriadamthanks for pointing out that method, I will definitely use that instead, to reduce code duplication etc.08:45
dcalisteBut I agree, that for the provided ical time zone, it is only using the standard ?08:45
dcalistestandard phase.08:45
dcalisteStrange indeed. But as I said, I suspect this not to be very tested... I may be wrong.08:46
chriadamwell, a good chance for me to provide some testing for it08:46
chriadamif there's one thing I know about myself, it's that: when it comes to timezone-related code, I trust other people more than me haha.08:47
chriadamand also "unit tests trump intuition" haha.08:47
dcalisteYeh, exactly. And if some others can take the burden of maintainance for this (with a little help), that's even better ;)08:49
chriadamdefinitely08:49
dcalisteWhat about the possibility to merge the mKCal ExtendedCalendar rewrite ?08:50
chriadamnext topic: I had a quick look at your caldav+buteo-syncfw PRs.  not in depth, and didn't do any on-device testing, even though I promised that I would (unfortunately I got sidetracked with a high-priority contacts sync bug which I had to fix)08:50
chriadambut from my quick look, it certainly seems good to me.08:50
dcalisteGreat, thank you.08:51
chriadamregarding the mkcal extendedcalendar thing: basically, I want to avoid merging anything to devel until after Thursday (branching) occurs08:51
chriadamcurrently, the only things we're merging is bugfixes for known issues08:51
chriadamto avoid destabilising devel att he moment08:51
dcalisteOk, I see. No problem.08:51
chriadamonce the branching is done, I will start merging a variety of your PRs including that one08:52
chriadammost likely monday next week, just in case something with branching needs attention over the weekend etc.08:52
dcalisteAbout bug fixing, what about this one : jolla-calendar#278 ?08:52
chriadamlet me check08:52
dcalisteNot of the highest importance :)08:53
chriadamLGTM - have poked Pekka but don't see any reason why we shouldn't merge that one08:53
chriadamthanks very much08:53
dcalisteThanks.08:53
dcalisteAbout the mKCal ExtendedCalendar rewrite, we wondered last week about the discrepancy in rawEvent() behaviour between MemoryCalendar and ExtendedCalendar.08:54
dcalisteI've looked in nemo bindings, and it's used only in one place.08:55
dcalisteBefore a for loop on returned events. It could be nice to put the visibility switch there and drop the specificity in ExtendedCalendar, couldn't it ?08:55
dcalisteSee https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/6608:56
chriadamnice!  that feels far nicer08:57
chriadamthan having an override method doing something different08:58
dcalisteThe remaining question if you agree for this, is : "is raw*() used outside the nemo bindings ?"08:58
chriadamlet me check08:59
chriadamat least, grep for rawEv returns nothing in sailfish-eas / activesync stuff09:00
chriadamrawT and rawJ returns no results either09:01
chriadamgrepping in the buteo repos now also09:05
chriadamno rawEv in those either09:05
chriadamso I think it's probably just the n-q-p-c09:05
dcalisteSo if you agree, I can modify the mKCal MR and when you will merge it, the nemo binding one should go in at the same time to be consistent.09:05
chriadamI agree - thank you09:06
chriadamdid MartinS get back to you about the PR he was supposed to look at?09:08
dcalisteNo, I guess he didn't have time for it yet.09:09
dcalisteAlso based on previous work on QML bindings for Buteo, I've added a list model for sync results and have a demo application showing the list of passed sync logs. You may have seen the screenshot I put yesterday.09:11
chriadamI saw the screenshot, yes, I didn't get a chance to look at the changes.  but yes, definitely a very nice thing to enable creation of a proper "sync log" UI09:12
dcalisteI still need to implement a filtering method on the model but it looks quite functional to get a page with sync feedback.09:12
chriadamI will add a comment to that calendar/timed alarms PR to poke martin again, sec09:12
dcalisteFor most plugins, the feedback is still sparse with just the time and the status, success or failure.09:14
dcalisteThanks for pushing also the work on timed alarms :)09:14
chriadamonce the buteo and caldav changes go in, we can look into porting further plugins one by one.  in some cases (e.g. google calendar) I think it will be relatively simple, as it already has some similarities to the caldav plugin in terms of per-event statuses.  for others it may be trickier, but let's see :-)09:16
chriadamI need to poke pvuorela and jpetrell about the sync log UI possibility also - maybe that's something our customers would want also.09:17
chriadamb2b / b2g I mean09:18
chriadamif it's a priority for them, then we can get more resourcing to port the plugins and do the UI design work also.09:18
chriadamlet's see :-)09:19
dcalisteYeh great. I could be used also to log the error of email daemon, as related to the recent work of flypig. I can give a look how to export the info from QMF to the email sync plugin.09:19
chriadamthat would be fantastic09:19
chriadamthanks for your work here - the fact that you have built all the pieces needed to test/demo end-to-end (buteo, plugin, qml exposure, demo app) is really great09:20
chriadamas it means we can do concrete things rather than talk about what might be.  I really appreciate the huge effort you give.09:20
dcalisteThanks. Besides, I will continue to look at your work on transitioning Google sync plugin and give feedback when I can.09:20
chriadamthank you :-)09:21
chriadamdid you have any other topics to discuss tonight?09:21
dcalisteNo, that's it, thank you for the help making things to go on. Have a good night and a nice week.09:21
chriadamthank you - have a great week also09:22
chriadamgnight!09:22
*** Ischwitch is now known as Ingvix15:36
*** Ischwitch is now known as Ingvix18:11
*** Ischwitch is now known as Ingvix18:41
wdehooghi. I have a problem with the SDK (3.4 target). the linking phase fails with unresolved references for all used libs. when loggin in on the mersdk vm and running make the linking succeeds.21:38
Nico[m]Did your build work before?21:39
Nico[m]How did you install your deps?21:39
ggabrielwdehoog: perhaps it would be useful to see the actual error, and to see what command exactly you type to make manually in mersdk21:42
wdehoogyes it worked before (3.2 target)21:43
wdehoogit works if I log in to mersdk vm,  execute sb2 -t SailfishOS-3.4.0.24-armv7hl, cd to the build dir and the execute ┬┤make┬┤21:44
wdehoogcompiling works in Sailfish IDE so all .o files are there but the linking fails21:45
ggabrielweird... you're sure it's the same target? so you don't have a 3.4 RC configured in the IDE?21:46
Nico[m]Hm, are you actually running make inside of sb2 with that command? How do your deps get installed?21:47
wdehoogI have build the libs on OBS, added a repo in the mersdk vm and installed them (all using sb2)21:49
Nico[m]Hm21:49
Nico[m]So not installed via rpm depends?21:50
Nico[m]Are you sure you reinstalled them in the right target?21:50
wdehoogbuild target SailfishOS-3.4.0.24-armv7hl21:50
ggabrielI'd like to see the actual linking error from the IDE21:50
Nico[m]I mean, you could have installed the deps into the wrong target, i.e. 3.2 by accident, but yeah, exact error would be useful21:51
wdehoogfailed https://pastebin.com/N2VXVhwR21:54
wdehoogsuccess https://pastebin.com/99fe20Xa21:55
ggabrielI'm not sure those are linking errors21:58
ggabrieland I don't know how the second time it succeeded21:59
ggabrielsorry, can't help tbh :)21:59
wdehoogthanks anyway21:59
wdehoogother problems I had. rsync and sdk-deploy-rpm were not installed. is that something you have to do yourself?22:00
Nico[m]The order of the libraries looks wrong to me :D22:00
wdehoogbtw I am running on a Oneplus One (community build)22:00
Nico[m]<wdehoog "other problems I had. rsync and "> That sounds more like your target wasn't installed correctly22:00
wdehoogrsync must be installed on the phone22:01
Nico[m]I think I just enabled dev mode22:03
*** Sellerie7 is now known as Sellerie23:33

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!