| *** vgtw_ is now known as vgtw | 00:47 | |
| *** zbenjamin_ is now known as zbenjamin | 02:10 | |
| *** frinring_ is now known as frinring | 03:20 | |
| *** nyov is now known as Guest72504 | 04:02 | |
| *** nyov is now known as Guest29071 | 04:59 | |
| chriadam | Hi dcaliste, I hope that your week went well? | 07:56 |
|---|---|---|
| dcaliste | Hello chriadam, yes previous days were fine. What about you ? | 07:58 |
| chriadam | yes, not too bad, thanks. How did the scans on your hand you - finger improving, I hope? | 08:01 |
| chriadam | go* | 08:01 |
| dcaliste | Yes, 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 |
| chriadam | that's good to hear. with some luck, perhaps the last 10% will return also? the body is an amazing thing. | 08:05 |
| dcaliste | About 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/64 | 08:06 |
| dcaliste | It'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 |
| chriadam | I agree | 08:09 |
| chriadam | seems 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 |
| dcaliste | Sure, 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 |
| dcaliste | Maybe I should have separated the two for clarity. | 08:11 |
| chriadam | probably fine as is, honestly. | 08:12 |
| dcaliste | Ok, 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 |
| dcaliste | These two things are not peculiar to SailfishOS, they are the same in NextCloud web interface also. Or OpenXchange one. | 08:15 |
| dcaliste | In my opinion, this is an annoying behaviour, what do you think ? | 08:15 |
| dcaliste | pvuorela, if you have time, I would like, please, to have your opinion on this matter ^ | 08:16 |
| chriadam | i.e. some way to "clear specific EXDATEs" from the parent series? | 08:17 |
| dcaliste | Well, I'm developping this, but I would like your opinion on the matter before going further indeed ;) | 08:17 |
| dcaliste | I have a demo UI for this and bindings in nemo-qml-plugin-calendar. | 08:17 |
| dcaliste | But 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 |
| dcaliste | I can start a forum thread to ask around what people are thinking also, cannot I ? | 08:19 |
| chriadam | please do | 08:20 |
| chriadam | for all UX things I defer to Martin, Joona and Pekka | 08:20 |
| chriadam | but 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 exdate | 08:21 |
| dcaliste | Yeh, 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 |
| dcaliste | Ok, I'll inquire on the forum what people are thinking and discuss there first the pro and cons of such addition. | 08:24 |
| dcaliste | About mKCal, you had a question about merging the implementation of MemoryCalendar and ExtendedCalendar. | 08:25 |
| dcaliste | About the fact that the two implementation diverged a bit on what to return as rawEvents(), visible or not. | 08:25 |
| chriadam | let me check that one again, my memory is bad | 08:25 |
| dcaliste | I think we cannot do much here without breaking a lot of things. | 08:26 |
| dcaliste | In fact the different semantic is preexitant to this MR. But now it's much more visible ! | 08:27 |
| chriadam | indeed | 08:28 |
| chriadam | as mentioned, I don't have a strong aversion to the MR, so long as it's documented clearly somehow | 08:29 |
| chriadam | that the semantics of the method impl are not what one might expect | 08:30 |
| dcaliste | Ok, I'll add comments in ExtendedCalendar that it's like that for backward compatibility reasons. | 08:30 |
| dcaliste | Besides, 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 |
| chriadam | yes | 08:31 |
| chriadam | regarding 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 |
| dcaliste | Let'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 |
| dcaliste | Ok, to postpone the merge after the branching. | 08:33 |
| chriadam | thanks | 08:34 |
| dcaliste | No problem. | 08:34 |
| dcaliste | I've finally implemented the per item logging in CalDAV based on https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/51 | 08:34 |
| dcaliste | Kind of validation test for the new API proposed there. | 08:34 |
| dcaliste | It's working well. I can see in the log the UID of added r modified events. | 08:35 |
| chriadam | were any changes required to the buteo-syncfw MR, or was all good? | 08:35 |
| dcaliste | See https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/74 for the CalDAV part. | 08:35 |
| dcaliste | No, all was good so far. | 08:35 |
| chriadam | excellent news | 08:37 |
| chriadam | thanks, I will check those two together, this week | 08:37 |
| dcaliste | Then, 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 |
| dcaliste | You will see that I'm not logging the failure details yet in the CalDAV MR. I'll add this later also. | 08:38 |
| dcaliste | Another 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/65 | 08:40 |
| chriadam | what do you mean? you log the fact of a failure, but not the cause? or? | 08:40 |
| dcaliste | Sorry, yes that's it. | 08:40 |
| dcaliste | The item with UID foo is logged as failed upload. | 08:41 |
| dcaliste | for instance. | 08:41 |
| dcaliste | while the item UID bar is logged as successful upload. | 08:41 |
| chriadam | cool | 08:41 |
| chriadam | yep, already a huge improvement | 08:41 |
| dcaliste | There is an added API to add a CDATA with whatever extract of HTTP response we can paste to the explain the failure. | 08:42 |
| dcaliste | But 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 |
| dcaliste | Nothing blocking, just I wanted to see if the UID logging was already working or not. | 08:43 |
| chriadam | definitely | 08:44 |
| chriadam | let me check the timed one (you've been busy!) | 08:44 |
| dcaliste | The 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 |
| chriadam | oh, this timed one is to choose arbitrary time before event, rather than the specific options | 08:45 |
| dcaliste | For the timed alarm, there is also on in jolla-calendar #276. | 08:45 |
| chriadam | yep, I remember it now | 08:45 |
| chriadam | I will ask MartinS if he has had a chance to think about that one | 08:45 |
| dcaliste | Yes, convenient to set all day reminders at a proper time. | 08:45 |
| dcaliste | Or 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 |
| dcaliste | Thank 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 |
| dcaliste | Or almost since we can still expose only one reminder, the relative reminders have priority. | 08:48 |
| dcaliste | Setting a timed alarm will make the relative reminders to be set at -1 (no reminder). | 08:48 |
| dcaliste | Otherwise it's just about adding a new QDateTime property with the timed alarm. | 08:49 |
| chriadam | yep. I think the motivation to add such a feature is clear, hopefully MartinS agrees | 08:49 |
| chriadam | it's more a question of "how to expose in UI" | 08:49 |
| dcaliste | Exactly. | 08:50 |
| chriadam | I have asked MartinS in internal chat channel, hopefully he has a chance ot take a look this week. | 08:50 |
| chriadam | oh, while I remember: I had a quick look at the kcalcore upgrade thing | 08:50 |
| chriadam | but I must have set the submodule up wrongly I think | 08:51 |
| chriadam | because it couldn't find the commit sha1 | 08:51 |
| dcaliste | Oh nice, great. | 08:51 |
| dcaliste | ah :/ | 08:51 |
| dcaliste | git submodule init | 08:51 |
| dcaliste | git submodule update | 08:51 |
| dcaliste | didn't work ? | 08:51 |
| dcaliste | Let me check which sha did I push... | 08:52 |
| chriadam | no. 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 |
| dcaliste | Strange, it exists upstream : https://invent.kde.org/frameworks/kcalendarcore/-/commit/5fd0c38248ddebd0f69db1a907d56e2c35abc9fe | 08:53 |
| dcaliste | Ah, wrong address in the submodule... Still the anongit.kde.org. | 08:54 |
| dcaliste | They migrated to gitlab earlier. | 08:54 |
| dcaliste | How to change this... | 08:54 |
| chriadam | I'm happy to edit my .git/config manually to update the git url | 08:55 |
| chriadam | what's the "correct" git url? | 08:55 |
| dcaliste | Ok, I've pushed a new commit updating the .gitmodules file. | 08:56 |
| chriadam | excellent, thanks very much | 08:56 |
| dcaliste | The right address is git://invent.kde.org/frameworks/kcalendarcore | 08:56 |
| dcaliste | Did I told you last time that all mKCal tests are passing after migration now ? | 08:57 |
| chriadam | yes! very exciting | 08:57 |
| chriadam | certainly gives confidence | 08:57 |
| chriadam | excellent work, as always. | 08:58 |
| chriadam | I (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 |
| dcaliste | Exactly. 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 |
| dcaliste | Thanks to flypig and blam for this. | 09:00 |
| dcaliste | They have also added the changes to store conferencing data in a standard way as described in rfc7986. | 09:00 |
| dcaliste | It'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 |
| chriadam | sounds definitely so | 09:01 |
| dcaliste | At 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 |
| chriadam | yes, definitely makes sense | 09:03 |
| chriadam | oh, big thanks for your very helpful review on flypig's google-calendars PR | 09:04 |
| dcaliste | It was just information in case it's useful later... | 09:04 |
| dcaliste | Well, it's very interesting too see how it's going in the Google sync plugin. | 09:04 |
| chriadam | sync is a complicated thing ;-) | 09:04 |
| dcaliste | Not that I'm going to use it, but it helps to clarify things for CalDAV also. | 09:04 |
| dcaliste | As 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 |
| dcaliste | It looks very similar between the two plugins. | 09:05 |
| dcaliste | But it's so much changes and risk of bugs that it's just smoke idea at the moment. | 09:06 |
| dcaliste | And maybe for later also ;) | 09:06 |
| chriadam | probably worth me mentioning: | 09:06 |
| chriadam | something like this already existed in buteo | 09:06 |
| chriadam | called the "hcalendar storage plugin" | 09:06 |
| chriadam | so 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 |
| dcaliste | Indeed, the storage plugin interface. Never looked deeper into it, but it could be valuable. Thanks for mentioning it. | 09:07 |
| chriadam | when 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 |
| chriadam | but we were in a rush to get J1 shipping, and I made a lot of mistakes. | 09:08 |
| chriadam | did you have anything else to discuss today? | 09:09 |
| dcaliste | No, 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 |
| chriadam | ;-) | 09:10 |
| dcaliste | It 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 |
| chriadam | I tell myself the same thing to help me sleep at night :-P | 09:12 |
| dcaliste | About today's meeting, no that's it. Thanks for the discussion as always. | 09:12 |
| chriadam | thank you very much also. quick summary: | 09:12 |
| chriadam | 1) branching soon, we won't merge changes until after then, probably (i.e. next thursday). | 09:12 |
| chriadam | 2) mkcal extended calendar / memory calendar - minor doc change to come, then can merge | 09:13 |
| chriadam | 3) per-item logging in caldav - requires buteo-syncfw MR. can test together now, should be all good. | 09:13 |
| chriadam | 4) event reminder alarms - nqpc+j-c changes. I've poked MartinS, let's see. | 09:14 |
| chriadam | 5) kcalcore upgrade - me and flypig or blam to continue with this over the next two weeks | 09:14 |
| chriadam | was that all or did I forget something? | 09:14 |
| dcaliste | That'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 |
| dcaliste | We can discuss this on next meeting if you wish. | 09:15 |
| chriadam | it will probably become clear to me when I check and test the MRs, but yes we should discuss next week :-) | 09:16 |
| chriadam | thanks again, for your effort and time! | 09:16 |
| chriadam | it is greatly appreciated | 09:16 |
| chriadam | have a great week! | 09:16 |
| dcaliste | Ok so have a nice week. | 09:16 |
| elros1 | rinigus: 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 |
| mal | statefs should not be used, for most things there should be some replacement | 21:17 |
| rinigus | elros1: 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 data | 21:25 |
| rinigus | And I do wonder what was wrong with statefs... | 21:25 |
| mal | what does it use statefs for? | 21:26 |
| mal | rinigus: it just made things more complicated in many ways and caused all sort of issues and maintenance burden | 21:26 |
| Nico[m] | I really liked statefs from the outside at least | 21:46 |
| Nico[m] | Do contextproperty and friends still work? | 21:47 |
| mal | yes, https://git.sailfishos.org/mer-core/nemo-qml-plugin-contextkit/commits/master | 21:54 |
| mal | you 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/!