Tuesday, 2020-11-24

*** vgtw_ is now known as vgtw00:47
*** zbenjamin_ is now known as zbenjamin02:10
*** frinring_ is now known as frinring03:20
*** nyov is now known as Guest7250404:02
*** nyov is now known as Guest2907104:59
chriadamHi dcaliste, I hope that your week went well?07:56
dcalisteHello chriadam, yes previous days were fine. What about you ?07:58
chriadamyes, not too bad, thanks.  How did the scans on your hand you - finger improving, I hope?08:01
dcalisteYes, the surgeon (and myself) is happy with the outcome. I regain already 90% of move amplitude and force with my left middle finger. Not sure that the remaining 10% are achievable, but eh it's already far better than it was forseeable last May. So great.08:04
chriadamthat's good to hear.  with some luck, perhaps the last 10% will return also?  the body is an amazing thing.08:05
dcalisteAbout code dev during last two weeks, I was looking at bindings of exceptions in nemo-qml-plugin-calendar, I found this https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/6408:06
dcalisteIt's a specific case, and I'm not using invitation, so I'm not impacted, but it seems to me that it could be a bug for exception deletion with invitation.08:07
chriadamI agree08:09
chriadamseems pvuorela was going to look into that further, I wonder if he has had a chance to do so yet, or if I should poke him ;-)08:09
dcalisteSure, but I also mixed two questions with the MR... You have the issue with the exception deletion not sending the cancellation, and you have my question about the deleteEvent() API.08:11
dcalisteMaybe I should have separated the two for clarity.08:11
chriadamprobably fine as is, honestly.08:12
dcalisteOk, thanks. About exceptions, I'm wondering about two things:08:12
dcaliste- when you create a recurring event, and you add an exception (one of the occurrence is replaced by an incidence with different time or summary or whatever), if you delete this exception you end up with no occurrence at that date.08:14
dcaliste- you cannot edit the list of deleted occurrence. If by mistake you end up deleting an occurrence and you want to revert later on, it's not possible by modifying the parent incidence.08:14
dcalisteThese two things are not peculiar to SailfishOS, they are the same in NextCloud web interface also. Or OpenXchange one.08:15
dcalisteIn my opinion, this is an annoying behaviour, what do you think ?08:15
dcalistepvuorela, if you have time, I would like, please, to have your opinion on this matter ^08:16
chriadami.e. some way to "clear specific EXDATEs" from the parent series?08:17
dcalisteWell, I'm developping this, but I would like your opinion on the matter before going further indeed ;)08:17
dcalisteI have a demo UI for this and bindings in nemo-qml-plugin-calendar.08:17
dcalisteBut I wonder if I'm the only one annoyed by this lack of editing capability and if you would welcome such changes. After all, it seems that the other UI I know about are not proposing such possibilities.08:19
dcalisteI can start a forum thread to ask around what people are thinking also, cannot I ?08:19
chriadamplease do08:20
chriadamfor all UX things I defer to Martin, Joona and Pekka08:20
chriadambut I am certain that they would be interested in seeing what feedback there is from the community. and certainly, from what you describe, it seems strange not to be able to "undo" the accidental creation of an exdate08:21
dcalisteYeh, that's what I find annoying. For my physiotherapist appointments, I setup a recurring event since last May, but I often have changes, moving and cancellation of occurrences because I go less often than in May. Thus the scratching push ;)08:23
dcalisteOk, I'll inquire on the forum what people are thinking and discuss there first the pro and cons of such addition.08:24
dcalisteAbout mKCal, you had a question about merging the implementation of MemoryCalendar and ExtendedCalendar.08:25
dcalisteAbout the fact that the two implementation diverged a bit on what to return as rawEvents(), visible or not.08:25
chriadamlet me check that one again, my memory is bad08:25
dcalisteI think we cannot do much here without breaking a lot of things.08:26
dcalisteIn fact the different semantic is preexitant to this MR. But now it's much more visible !08:27
chriadamas mentioned, I don't have a strong aversion to the MR, so long as it's documented clearly somehow08:29
chriadamthat the semantics of the method impl are not what one might expect08:30
dcalisteOk, I'll add comments in ExtendedCalendar that it's like that for backward compatibility reasons.08:30
dcalisteBesides, we could change the semantic to be the same and filter out later on in nemo-qml-plugin-calendar. After all, only nemo-qml-plugin-calendar is using this rawEvents() things I think (or hope).08:31
chriadamregarding timeline: pvuorela just mentioned to me that we are branching an important release next Thursday (or maybe Friday).  Probably won't get this MR merged until after then, don't want to destabilise - hope that's ok with you?08:32
dcalisteLet's do this in two steps if you agree. I'll add documentation in the current MR to say that it's done to preserve compatibity and later on studied what to change in nemo-qml-plugin-calendar to assume that events without visibility could be returned.08:32
dcalisteOk, to postpone the merge after the branching.08:33
dcalisteNo problem.08:34
dcalisteI've finally implemented the per item logging in CalDAV based on https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/5108:34
dcalisteKind of validation test for the new API proposed there.08:34
dcalisteIt's working well. I can see in the log the UID of added r modified events.08:35
chriadamwere any changes required to the buteo-syncfw MR, or was all good?08:35
dcalisteSee https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/74 for the CalDAV part.08:35
dcalisteNo, all was good so far.08:35
chriadamexcellent news08:37
chriadamthanks, I will check those two together, this week08:37
dcalisteThen, for the UI part, I'll need to develop a new class in nemo-qml-plugin-calendar, a new ListModel to expose a list of given UIDs. Currently there is only the AgendaModel which expose a list of UIDs based on date ranges. But that's for later. The fact that the data are already in the log is a good step.08:37
dcalisteYou will see that I'm not logging the failure details yet in the CalDAV MR. I'll add this later also.08:38
dcalisteAnother calendar topic, I finished also some implementation I started some time ago adding QML binding and UI for timed alarms : https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/6508:40
chriadamwhat do you mean?  you log the fact of a failure, but not the cause?  or?08:40
dcalisteSorry, yes that's it.08:40
dcalisteThe item with UID foo is logged as failed upload.08:41
dcalistefor instance.08:41
dcalistewhile the item UID bar is logged as successful upload.08:41
chriadamyep, already a huge improvement08:41
dcalisteThere is an added API to add a CDATA with whatever extract of HTTP response we can paste to the explain the failure.08:42
dcalisteBut I've not yet used it because it requires a bit more extended changes in the CalDAV plugin to store the HTTP responses.08:43
dcalisteNothing blocking, just I wanted to see if the UID logging was already working or not.08:43
chriadamlet me check the timed one (you've been busy!)08:44
dcalisteThe CDATA could be used also to logg something on success, for example in the case of deletion, we can store the summary, so the user can see what the event that has been deleted was talking about.08:44
chriadamoh, this timed one is to choose arbitrary time before event, rather than the specific options08:45
dcalisteFor the timed alarm, there is also on in jolla-calendar #276.08:45
chriadamyep, I remember it now08:45
chriadamI will ask MartinS if he has had a chance to think about that one08:45
dcalisteYes, convenient to set all day reminders at a proper time.08:45
dcalisteOr to add reminders much more in advance than 2 days, for example the Sunday evening before some event in the week because after you're busy during the week or what ever.08:46
dcalisteThank you to see with Martin (if he's available), because it's mainly a UI change. The QML binding is straight forward in my opinion.08:47
dcalisteOr almost since we can still expose only one reminder, the relative reminders have priority.08:48
dcalisteSetting a timed alarm will make the relative reminders to be set at -1 (no reminder).08:48
dcalisteOtherwise it's just about adding a new QDateTime property with the timed alarm.08:49
chriadamyep.  I think the motivation to add such a feature is clear, hopefully MartinS agrees08:49
chriadamit's more a question of "how to expose in UI"08:49
chriadamI have asked MartinS in internal chat channel, hopefully he has a chance ot take a look this week.08:50
chriadamoh, while I remember: I had a quick look at the kcalcore upgrade thing08:50
chriadambut I must have set the submodule up wrongly I think08:51
chriadambecause it couldn't find the commit sha108:51
dcalisteOh nice, great.08:51
dcalisteah :/08:51
dcalistegit submodule init08:51
dcalistegit submodule update08:51
dcalistedidn't work ?08:51
dcalisteLet me check which sha did I push...08:52
chriadamno.  it says: "upload-pack: not our ref: 5fd0c382..."08:52
chriadam"fetched in submodule path 'upstream', but it did not contain 5fd0c382... Direct fetching of that commit failed'08:52
dcalisteStrange, it exists upstream : https://invent.kde.org/frameworks/kcalendarcore/-/commit/5fd0c38248ddebd0f69db1a907d56e2c35abc9fe08:53
dcalisteAh, wrong address in the submodule... Still the anongit.kde.org.08:54
dcalisteThey migrated to gitlab earlier.08:54
dcalisteHow to change this...08:54
chriadamI'm happy to edit my .git/config manually to update the git url08:55
chriadamwhat's the "correct" git url?08:55
dcalisteOk, I've pushed a new commit updating the .gitmodules file.08:56
chriadamexcellent, thanks very much08:56
dcalisteThe right address is git://invent.kde.org/frameworks/kcalendarcore08:56
dcalisteDid I told you last time that all mKCal tests are passing after migration now ?08:57
chriadamyes!  very exciting08:57
chriadamcertainly gives confidence08:57
chriadamexcellent work, as always.08:58
chriadamI (and hopefully flypig?  or perhaps blam) will be spending some time over the next couple of weeks looking into the buteo plugins and sailfish-eas things.08:59
dcalisteExactly. And there is a jump of activity upstream. They have added some new properties from RFC7986. Not that it's fundamental changes but it could help to standardize a bit more things like colours, names and descriptions, after I add required bits in mKCal of course...08:59
dcalisteThanks to flypig and blam for this.09:00
dcalisteThey have also added the changes to store conferencing data in a standard way as described in rfc7986.09:00
dcalisteIt's a new field in an event to store URL of connexion, type of conferencing... This may be of corporate interest in case.09:01
chriadamsounds definitely so09:01
dcalisteAt the moment, all this information is packed in the description, but it can be saved properly also in its own field so it can be presented to the user in a specific way.09:02
chriadamyes, definitely makes sense09:03
chriadamoh, big thanks for your very helpful review on flypig's google-calendars PR09:04
dcalisteIt was just information in case it's useful later...09:04
dcalisteWell, it's very interesting too see how it's going in the Google sync plugin.09:04
chriadamsync is a complicated thing ;-)09:04
dcalisteNot that I'm going to use it, but it helps to clarify things for CalDAV also.09:04
dcalisteAs discussed two weeks ago with flypig, we should create an abstraction in my opinion to gather the sync logic and its application to mKCal storage.09:05
dcalisteIt looks very similar between the two plugins.09:05
dcalisteBut it's so much changes and risk of bugs that it's just smoke idea at the moment.09:06
dcalisteAnd maybe for later also ;)09:06
chriadamprobably worth me mentioning:09:06
chriadamsomething like this already existed in buteo09:06
chriadamcalled the "hcalendar storage plugin"09:06
chriadamso the client plugins (google and caldav in this case) would solely be responsible for communication with the remote server, then transforming the data into ics.  those .ics would then be provided to the hcalendar storage plugin, which does the actual synchronisation stuff.09:07
dcalisteIndeed, the storage plugin interface. Never looked deeper into it, but it could be valuable. Thanks for mentioning it.09:07
chriadamwhen I started, I didn't fully understand how the pieces were supposed to fit together.  so I ignored it.  probably a mistake, in hindsight.09:07
chriadambut we were in a rush to get J1 shipping, and I made a lot of mistakes.09:08
chriadamdid you have anything else to discuss today?09:09
dcalisteNo, it was logical to do as you did. The architecture is complex and difficult to grasp. Peculiarities of mKCal storage vs memory as discussed with flypig is really a source of difficulties to write things properly.09:09
dcalisteIt took me several years of playing with this code to actually properly understand how it is working, so even if you're faster, it was not possible to do differently within the timeframe.09:11
chriadamI tell myself the same thing to help me sleep at night :-P09:12
dcalisteAbout today's meeting, no that's it. Thanks for the discussion as always.09:12
chriadamthank you very much also.  quick summary:09:12
chriadam1) branching soon, we won't merge changes until after then, probably (i.e. next thursday).09:12
chriadam2) mkcal extended calendar / memory calendar - minor doc change to come, then can merge09:13
chriadam3) per-item logging in caldav - requires buteo-syncfw MR.  can test together now, should be all good.09:13
chriadam4) event reminder alarms - nqpc+j-c changes.  I've poked MartinS, let's see.09:14
chriadam5) kcalcore upgrade - me and flypig or blam to continue with this over the next two weeks09:14
chriadamwas that all or did I forget something?09:14
dcalisteThat's all indeed ;) About the per item logging, I mentioned it's logging failures also. This is orthogonal to the failure tagging of events.09:15
dcalisteWe can discuss this on next meeting if you wish.09:15
chriadamit will probably become clear to me when I check and test the MRs, but yes we should discuss next week :-)09:16
chriadamthanks again, for your effort and time!09:16
chriadamit is greatly appreciated09:16
chriadamhave a great week!09:16
dcalisteOk so have a nice week.09:16
elros1rinigus: hi, since 3.4.0.x statefs is not installed by default. collectd.service requires it so fails to start. I guess some statefs providers also should be pulled by rpm.21:04
malstatefs should not be used, for most things there should be some replacement21:17
riniguselros1: wasn't aware of that. I will look into it after I update my port. Then we'll see if there are replacements for all data21:25
rinigusAnd I do wonder what was wrong with statefs...21:25
malwhat does it use statefs for?21:26
malrinigus: it just made things more complicated in many ways and caused all sort of issues and maintenance burden21:26
Nico[m]I really liked statefs from the outside at least21:46
Nico[m]Do contextproperty and friends still work?21:47
malyes, https://git.sailfishos.org/mer-core/nemo-qml-plugin-contextkit/commits/master21:54
malyou can see the commit "Reimplement contextkit QML API"21:54
Nico[m]Also the C++ API?22:09

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