| *** zbenjamin is now known as Guest28200 | 02:12 | |
| *** zbenjamin_ is now known as zbenjamin | 02:12 | |
| *** nyov is now known as Guest80495 | 04:10 | |
| dcaliste | Hello chriadam, how are you ? | 07:59 |
|---|---|---|
| chriadam | hi dcaliste | 08:03 |
| chriadam | I'm well thanks | 08:03 |
| chriadam | how are you? | 08:03 |
| dcaliste | Fine, thank you. I've seen your MRs in gerrit for QtPim. I've started to give a look but didn't finish. | 08:04 |
| dcaliste | Mainly, we've faced the same problems for QMF. | 08:04 |
| chriadam | oh, thank you. I am hoping to get those all integrated this week, as pvuorela kindly +2'd those qtpim ones already | 08:04 |
| dcaliste | I've mainly looked at how it's done, and it should be the same in QMF MRs and your QtPIM ones. | 08:05 |
| chriadam | hopefully - let's see if it passes CI ;-) | 08:05 |
| dcaliste | Indeed ! | 08:05 |
| chriadam | sorry, I dc'd | 08:06 |
| chriadam | regarding the caldav PR: I'm not sure precisely how Bree encountered the issues she hit. interestingly, one of those at least reproduces with master branch, so not a regression caused by the PR itself, apparently | 08:07 |
| chriadam | I haven't had a chance to investigate precisely what is happening, or repro myself | 08:07 |
| dcaliste | I'm curious about how to reproduce. | 08:07 |
| dcaliste | I don't have the problem with my OpenXChange account and I'm modifying exceptions regularly: physiotherapist time changes ;) | 08:08 |
| dcaliste | I'm doing all modifications and creations on device, the server being mainly a kind of backup in my use cases. | 08:08 |
| chriadam | I didn't see the issue with my brief testing either, but bree's testing was more comprehensive than mine, so hopefully she will be able to give precise repro instructions :-) | 08:09 |
| dcaliste | I'll try to see if it's the same when exceptions are initiated on server. | 08:09 |
| dcaliste | Indeed, let's also wait for reproduction instructions. | 08:10 |
| dcaliste | About CalDAV, you may have seen my MR from yesterday about a forum issue of calendar not syncing anymore from a Radicale server. | 08:10 |
| dcaliste | It's a problem in the calendar discovery code. | 08:10 |
| chriadam | oh, I didn't see that one yet | 08:11 |
| chriadam | path construction, or? | 08:11 |
| dcaliste | Request class is ignoring 403 errors and returning success in that case. Which confuses the later logic in CalDavClient because well this is an error but it takes the success code path. | 08:11 |
| chriadam | ah | 08:12 |
| dcaliste | I hesitated many time with flypig yesterday about the best way to solve this. At first, I wanted to remove the Request "hack" of treating 403 error as a success, but it's very intrusive to keep the backward compatibility. | 08:13 |
| dcaliste | Finally, I ended up with a modification in CalDavClient to also take the error code path when the response is 403. It's a bit hacky and I put a comment there to mentioned that it comes from the Request treatment of 403 errors. | 08:14 |
| dcaliste | I've packaged the MR and the user seems to be happy with it. | 08:14 |
| chriadam | sounds like a good pragmatic solution | 08:14 |
| dcaliste | See https://forum.sailfishos.org/t/after-upgrade-to-3-4-0-24-caldav-sync-stopped-working/3118/11 | 08:15 |
| dcaliste | And https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/merge_requests/73 | 08:15 |
| chriadam | thanks, I will check tomorrow | 08:15 |
| dcaliste | Thank you. | 08:16 |
| chriadam | thank you very much for investigating and fixing | 08:16 |
| chriadam | also, thanks for the email you sent the other week with the information about the kcalcore upgrade status | 08:16 |
| dcaliste | Well, the user was very nice and provided before asking all necessary information to quickly understand the root issue. | 08:16 |
| chriadam | we discussed it briefly in sprint planning, but no concrete plan for who will be able to work on that one yet unfortunately | 08:17 |
| chriadam | we have some loose ends we need to tie up on customer projects, then we'll have a clearer idea of availability within the team internally | 08:17 |
| dcaliste | About KCalCore upgrade, don't hesitate to ask question if something requires more information. And thank you for considering this internally. | 08:18 |
| chriadam | oh, I forgot to ask: how was your vacation last week? hopefully nice and relaxing | 08:19 |
| dcaliste | It was great, went sailing on the Mediterranean coast with friends for a week. The weather was great for autumn and we even succeeded to swim. | 08:20 |
| chriadam | beautiful! | 08:21 |
| chriadam | sounds great | 08:21 |
| dcaliste | It changed mind from the gloomy corona ambiance… | 08:21 |
| chriadam | yes, so important to keep good spirits in these somewhat depressing times | 08:21 |
| dcaliste | You may end up in confinment soon here again :/ | 08:21 |
| dcaliste | Sorry, we… | 08:21 |
| dcaliste | Not you ! | 08:21 |
| chriadam | hopefully the winter weather in the northern hemisphere doesn't drive another wave of infections :-( | 08:22 |
| chriadam | but anyway, I'm glad that you had a great vacation | 08:22 |
| dcaliste | About KCalCore transition, having https://git.sailfishos.org/mer-core/kcalcore/merge_requests/21 accepted would allow to modify mKCal ExtendedCalendar to inherit from MemoryCalendar. | 08:23 |
| chriadam | were there any other PRs to discuss - I unfortunately haven't progressed any outstanding things on my end. not sure if the jolla-calendar things have progressed? flypig? | 08:23 |
| dcaliste | Doing this would save a lot of KDateTime to QDateTime transition there. | 08:23 |
| chriadam | oh, I remember that kcalcore MR. yes, I will merge that one asap. | 08:23 |
| dcaliste | Because most of them would be in KCalendarCore already. | 08:23 |
| dcaliste | And if flypig is here, I would like to discuss the problem of calendar visibility that come back when editing setting page or event at each sync cycle for Google account. | 08:24 |
| dcaliste | Did you remember, the issue we began to discuss last time about the Contactd plugin that change visibility on account enable changes ? | 08:25 |
| chriadam | he was online a little while ago at least, hopefully he's around | 08:25 |
| flypig | I'm around... | 08:26 |
| flypig | I'm just checking the status of https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/266/ | 08:26 |
| dcaliste | I've investigated the problem of libaccount-glib emitting enableChanged signal too often. | 08:26 |
| dcaliste | Hello flypig ! | 08:26 |
| flypig | Hi :) I'm glad you had a good break. | 08:27 |
| flypig | What was your conclusion (about libaccount-glib)? | 08:27 |
| dcaliste | Well, it is not emitting this signal too often in fact. And we cannot by design add a signal on "real" change. | 08:28 |
| dcaliste | :( | 08:28 |
| flypig | That's too bad. | 08:29 |
| flypig | But that suggests some other issue then? | 08:29 |
| dcaliste | It is due to a server/client design to enable concurrency. | 08:29 |
| dcaliste | When an account manager is calling setEnable(), the signal will be emitted even if there is no change. | 08:30 |
| flypig | That was the underlying issue, as I understood it. | 08:30 |
| dcaliste | Because, this manager cannot know if the database actually reflect the value is possess because some concurrent process may have changed the value in between and the change signal may not be propagated yet. | 08:31 |
| dcaliste | In fqctm it4s not completely the issue at hand, let me explain why: | 08:31 |
| flypig | Ah, I see. | 08:31 |
| dcaliste | If you don't call setEnable(), the enableChanged signal is *not* emitted. | 08:32 |
| dcaliste | So if your code don't care about the actual status of the account in storage and just want to store a setting like the sync token for this account, then the signal is not emitted by libaccount-glib. | 08:33 |
| dcaliste | But in UI, the signal is emitted anyway, because, the sailfish-component-accounts is calling setEnable() unconditionnally and thus the signal is emitted every time the UI is calling sync(). | 08:34 |
| dcaliste | There is something we need to decide here about sailfish-component-accounts: | 08:34 |
| dcaliste | - current situation is that when syn() is called in QML, the account status (enabled or disabled) is enforced, whatever the change that is done. It is safe because we're sure that the status is the one reflected in UI. But it emits the enableChanged signal at each sync() call. | 08:36 |
| dcaliste | - possible corrected situation is to call setEnable() only when the UI actually flip it. Then, the signal is emitted properly, but it creates a race condition where the user may see an enabled account but actually a background process diasble it before it confirm the settig dialog and at the end the account is not enabled when the setting dialog is confirmed. | 08:37 |
| dcaliste | What do you think flypig and chriadam ? | 08:37 |
| chriadam | flypig was working on something to ensure that only a "delta" of changes is applied, rather than every setting, iirc | 08:39 |
| chriadam | which might mean the second (only call setEnabled() when the ui flips it) will happen | 08:39 |
| chriadam | but not sure of the status of that work, currently | 08:39 |
| chriadam | or am I remembering wrongly, flypig ? | 08:40 |
| flypig | Yes, that's been merged in already. | 08:40 |
| chriadam | oh, great | 08:40 |
| dcaliste | Yes, but the issue is deeper in sailfish-component-accounts, I think, look at line src/lib/account.cpp#623 | 08:40 |
| flypig | But I'm not 100% sure if it affects enabled/disabled status, because they're a bit special. | 08:40 |
| dcaliste | This setEnabled() is called unconditionnally there. | 08:40 |
| dcaliste | And this is triggerring the enableChanged() signal. | 08:41 |
| dcaliste | I would suggest to set a flag in Account::setEnabled() and call the setEnagled() on the underlying account only when the flag is on. | 08:42 |
| dcaliste | I would like to propose a MR for this that we can discuss, but I only have read access on this repo ! | 08:43 |
| chriadam | pvuorela any chance you could give write access ^ | 08:43 |
| pvuorela | suppose that's for the pull request branches, sure, i'll check. | 08:45 |
| chriadam | tyv | 08:45 |
| chriadam | m | 08:45 |
| dcaliste | Thank you pvuorela | 08:46 |
| flypig | Correct me if I'm wrong, but won't there be a danger that any setEnabled() used somewhere could trigger the same problem. Just for the sake of discussion, I'm wondering if something like an AgAccountWatch could be used instead. | 08:49 |
| flypig | I have a feeling these only apply to properties rather than account/service enabled states though. | 08:50 |
| flypig | For ref: https://gitlab.com/accounts-sso/libaccounts-qt/-/blob/master/Accounts/account.h#L70 | 08:51 |
| dcaliste | Indeed, any call to setEnabled() will trigger the signal and thus the notebook visibility. That's quite a fragile situation, I agree. What is AgAccountWatch ? | 08:51 |
| flypig | AgAccountWatch sends a glib notify whenever a property changes in the database. | 08:52 |
| flypig | Here's the underlying libaccounts-glib code: https://git.sailfishos.org/mirror/libaccounts-glib/blob/master/libaccounts-glib/ag-account.h#L170 | 08:54 |
| dcaliste | Ok, looking at it indeed, it may work, after all enable status is saved as a setting in fact… | 08:55 |
| flypig | It may suffer from the same issue as the signal, but might be worth checking. | 08:56 |
| gmc | hi folks, I posted on the forum last week, i'm trying to develop a nextcloud tasks app, and was looking at various ways to go about it.. one was using https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/, but that does not seem to support VTODO's yet? Also can't really find an example of how to use that, although i guess i can figure it out with a bit of puzzling | 08:56 |
| gmc | the other way (that i'm pursuing now) is to do the interaction with nextcloud's caldav endpoint completely in the app itself (which also is not ideal, since I found out the XMLHttpRequest in qml doesn't support the REPORT http verb) | 08:57 |
| gmc | so i might want to use QtNetwork, but that is then again another api forbidden by the harbour | 08:58 |
| chriadam | QNetworkAccessManager is forbidden by harbour rules? really? | 08:58 |
| gmc | (not that I mind too much, i'm alreaady out of harbour anyway due to using sailfishsecrets to securely store credentials) | 08:58 |
| gmc | chriadam: https://github.com/sailfishos/sdk-harbour-rpmvalidator/blob/harbour-qa/allowed_requires.conf does not have qtnework in there | 08:59 |
| chriadam | whoa | 08:59 |
| chriadam | pvuorela: that can't be intentional, surely? | 08:59 |
| dcaliste | flypig, ok, I'm going to give a deeper look at watches, but as you said, I'm afraid it will suffer from the same issue, at first sight. Because the watch code is actually called at the same place the signal enableChanged is called and not by a diff at the database level. | 09:00 |
| chriadam | gmc: in general, my advice would be: implement the requests manually in C++, expose things to QML selectively, don't depend on nemo-qml-plugin-calendar as it's likely to change in future etc I guess | 09:01 |
| gmc | chriadam: anyway, nemo-qml-plugin-calendar is also not in the allowed list for harbour, so I'm slowly coming around to the fact that publishing in harbour is only for the most trivial of trivial apps | 09:01 |
| chriadam | gmc: the buteo-sync-plugin-caldav and buteo-sync-plugin-carddav plugins are useful references if you need example code | 09:01 |
| pvuorela | qtnetwork https://github.com/sailfishos/sdk-harbour-rpmvalidator/blob/harbour-qa/allowed_libraries.conf#L8 | 09:02 |
| dcaliste | If we want to actually emit a "real" change signal, it would mean to add a SQL read statement before actually doing the write one and then propagate the signal through DBus to the manager. But it's very invasive and I'm doubtfull that upstream will like it. | 09:02 |
| dcaliste | qmc: use DBus interface to nemo-qml-plugin-calendar to list or modify events. | 09:02 |
| chriadam | pvuorela: you're right, it is there | 09:03 |
| chriadam | gmc: yup, just use QNetworkAccessManager, expose stuff manually to your QML code. | 09:03 |
| flypig | dcaliste, yes, I see what you mean. If you don't mind looking into it at any rate. And otherwise, it sounds like there's the higher-level solution in sailfish-components-accounts. | 09:03 |
| gmc | pvuorela: ok, now i'm confused.. it's a supported library, but i'm not allowed to require it? | 09:03 |
| dcaliste | qmc, as I said, also on forum, buteo-sync-plugin-caldav could also sync TODOs by modifying it not to restrict to event listing in the server request. | 09:04 |
| dcaliste | flypig, yes, that's the plan. I'll check for watchers, and then if not successfull, will submit a MR to saifish-componet-accounts and we can discuss the pros and cons there. | 09:04 |
| flypig | Perfect. Thank you. | 09:05 |
| flypig | Apologies in advance if it turns out to be a wild goose chase. | 09:05 |
| dcaliste | qmc, for the buteo plugin for CalDAV, the best in my opinion is to create a setting that enable TODOs syncing. Like that adventurous ones can flip the setting on and get TODOs syncing and all the rest are free from bugs related to TODOs. | 09:06 |
| dcaliste | flypig, : no problem. | 09:06 |
| dcaliste | chriadam ^ do you think it's a possible approach to enable TODOs syncing ? I can prepare an MR for this. | 09:07 |
| gmc | dcaliste: ok, still getting my bearings with all this.. the buteo plugin is what is used also for the system calendar and things? i've only looked at the app side of things so far, not the os side of things | 09:07 |
| chriadam | it's something we have discussed in the past. for actually syncing the data, I see no problem enabling. but for supporting them properly, that requires a lot of thought and design work in UI side, in Jolla Calendar app / notifications / events view etc I guess | 09:08 |
| chriadam | gmc: yes, the buteo plugins sync the data to the databases, which are then exposed in e.g. the jolla-calendar app | 09:08 |
| dcaliste | Yes, Buteo is the syncing framework. It is calling this plugin regularly. | 09:08 |
| gmc | chriadam: for now, i'm creating an app specifically to manage todo's, just like I have on android.. it's completely disjoint from the calendar, which is imho fine | 09:09 |
| dcaliste | chriadam, that's the point I think, just enable the sync in background and let gmc work on a UI for it. | 09:09 |
| dcaliste | The problem with enabling the sync for all is that is may create issues with code paths that are not tested (related to TODOs saving in mKCal and so on). | 09:09 |
| chriadam | dcaliste: well, if he's planning on making a harbour app, it won't be privileged / able to access the system database unfortunately. he is better off just syncing to app-specific sqlite db or whatever, IMO | 09:10 |
| dcaliste | That's why I'm suggesting to remove the event listing restriction from the plugin only with a setting. | 09:10 |
| pvuorela | gmc: i'm not sure is the content separation between those two files optimal now, but think they both get applied on the check. though for c/c++ you don't need explicit requires as rpm will automatically add the library dependencies. | 09:10 |
| gmc | pvuorela: ok thanks, that's good to know | 09:11 |
| dcaliste | chriadam: but Buteo is priviledge, so regular syncing may happen. Then he can display todos and modify them with with DBus calls. | 09:11 |
| dcaliste | Except if the DBus interface is restricted to priviledge rights also… | 09:12 |
| gmc | dcaliste: that's what i'm wondering.. i did some exploring, and it only showed me read access | 09:12 |
| gmc | but I may have to dig deeper | 09:12 |
| chriadam | ah, I see what you mean... going forward, I think the dbus APIs might be tightened up also, not 100% sure. abranson might know more than I | 09:12 |
| gmc | chriadam: so right now i'm indeed writing code to interact with nextcloud directly from the app, but i'd rather see it use the already existing synchronisation with nextcloud that's happening in the os.. but i guess that also requires a more mature app-permission model that's not there yet | 09:13 |
| chriadam | for now, I'd suggest doing it manually in C++ and storing to app-specific db, and exposing data to QML via your own type registrations / models, personally... my mantra is "reduce external dependencies" and in gmc's case, that means reducing which APIs and system components he depends on. | 09:14 |
| chriadam | I keep dcing | 09:15 |
| chriadam | I definitely suggest looking at the caldav plugin and seeing what would be needed to support TODO syncing in there. I know dcaliste has already done most of the work | 09:15 |
| abranson | hello | 09:15 |
| chriadam | but the codepaths need thorough testing | 09:15 |
| abranson | yeah it's worth keeping an eye on the repos, things are happening sooner rather than later | 09:16 |
| chriadam | then, yes, as you say, a better app permissions model is needed. that's a work in progress... no promises on ETA or details. | 09:16 |
| gmc | yeah, so i think for now indeed the approach i have now (do it myself) is the fastest way to get this app up and running.. | 09:16 |
| dcaliste | chriadam, in the Buteo plugin, every thing is ready at the moment. Just that the request sent to server is asking for filtering events only. We may add a OR filter saying we would like the todos also. | 09:16 |
| gmc | happy to do any testing on todo-enabled os infra though, to get things moving forward to a more ideal picture | 09:17 |
| dcaliste | It's a one-line modification, but it will trigger code path that are not tested in mKCal. | 09:17 |
| gmc | i'll look into installing the platform sdk sometime soon, i guess that's what's needed to work on this stuff | 09:17 |
| chriadam | gmc: yep. that would be greatly appreciated. dcaliste knows more about the caldav/kcalcore/mkcal side than anyone else currently, and flypig and I will be more than happy to help if you have any questions also | 09:18 |
| flypig | For sure. | 09:19 |
| chriadam | dcaliste: maybe we should just flip the switch (and expose via a setting in the accounts UI, as you suggest) | 09:19 |
| gmc | i'll probably need some, i'm still in the 'it's all so overwhelming' phase of entering a new project :) | 09:19 |
| chriadam | haha no doubt, and no worries | 09:20 |
| gmc | i'll get there :) | 09:20 |
| chriadam | I am not on IRC much these days, but will be here every tuesday, at about now minus 1.5 hours | 09:20 |
| chriadam | aside from that, feel free to send me an email whenever | 09:20 |
| chriadam | dcaliste: did you have anything else to discuss today? | 09:21 |
| chriadam | if not, just to sum up: | 09:21 |
| gmc | i must say, it's been a while since i was really active on irc as well :) | 09:21 |
| chriadam | 1) caldav PR - get the repro instructions from bree | 09:21 |
| chriadam | 2) mkcal PR - the memory calendar PR - review/test/merge this one | 09:21 |
| chriadam | 3) there was a kcalcore PR with unit tests now added, right? I need to reivew/test/merge that one also? | 09:22 |
| chriadam | and then 4) for flypig, is there something on our side needed for the jolla-calendar PR? | 09:22 |
| chriadam | I will do 1+2+3 tomorrow and thursday | 09:23 |
| flypig | Yes, I've asked pvuorela to take another look at the strings. That's the only outstanding issue as far as I'm aware. | 09:23 |
| pvuorela | dcaliste: pr access perhaps better now. | 09:23 |
| chriadam | ok great | 09:23 |
| flypig | chriadam, dcaliste, can I also request your thoughts on this please: https://git.sailfishos.org/mer-core/buteo-sync-plugins-social/merge_requests/73 | 09:23 |
| dcaliste | 2) -> this MR is not published yet. To be added from my side after the KCalCore is accepted. | 09:23 |
| chriadam | I will check that one also tomorrow, flypig | 09:23 |
| flypig | Many thanks. | 09:23 |
| dcaliste | 3) tests have been added, indeed. | 09:24 |
| chriadam | sounds good, thanks very much as always for your time and effort. | 09:25 |
| chriadam | anything else to discuss? | 09:26 |
| dcaliste | pvuorela, yes it works to push there now. Thanks | 09:26 |
| dcaliste | gmc and chriadam, I'll do some tests with my OpenXchange account to see if I can down sync some todos. There are some peculiarities with the calendar layout on the server. The tasks are not in the same notebooks and so on. | 09:26 |
| chriadam | ah, todo-specific collection? | 09:27 |
| dcaliste | That's fine chriadam. Thank you for all the exchanges today. Thank you also flypig and pvuorela. | 09:27 |
| gmc | dcaliste: cool, thanks | 09:27 |
| flypig | Thanks from me too :) | 09:27 |
| chriadam | thanks again! have a great week! | 09:27 |
| * chriadam -> away | 09:28 | |
| dcaliste | Yes, there is a todo specific notebook by default. But I guess that's server specific. | 09:28 |
| *** frinring_ is now known as frinring | 09:28 | |
| pvuorela | one potentially problematic detail with VTODO can be the coupling with time. might be what you wnat, but also often todo lists can be understood as just list of things to do. | 09:31 |
| gmc | pvuorela: indeed, personally i never use times in my VTODO's.. If there is something that must happen on a certain day, it's a VEVENT for me.. but other people may use these things differently of course | 09:34 |
| *** Sail0r_ is now known as Sail0r | 09:35 | |
| dcaliste | flypig, I've started to look at your MR in Google sync, but have not finished yet ! | 09:36 |
| flypig | Okay, great, I v.much appreciate it. I think I mentioned on the MR, but I think the changes are much clearer if each commit is taken separately. | 09:37 |
| flypig | But the big change is switching to use device-time rather than server-time for the change delta. | 09:39 |
| dcaliste | lbt or pvuorela, may you look at https://git.sailfishos.org/groups/mer-core/-/activity ? It seems that the hook on Maintainer changes is triggered in a loop since yesterday… | 09:56 |
| lbt | dcaliste: ty - I'm looking at it | 09:57 |
| dcaliste | Thanks lbt | 09:58 |
| lbt | it was all Thaodan's fault :D :D :D | 10:04 |
| dcaliste | Uhuh, thanks for the correction lbt. | 10:09 |
| lbt | no problems - it turns out that the api accepted the lowercase username to make the changes | 10:09 |
| lbt | however the script pulls back the usernames and it returns the correct uppercase one | 10:09 |
| lbt | but when it compares it to the yaml it sees Thaodan should not be there but thaodan should so.. it removes Thaodan and adds thaodan via the API... | 10:10 |
| lbt | so I suppose the script could do a case-insensitive compare ... but ... | 10:10 |
| lbt | anyhow... now I need to see why I can't send jolla.com emails | 10:11 |
| *** Ischwitch is now known as Ingvix | 12:57 | |
| *** monich_ is now known as monich | 17:45 | |
| lbt | PSA: services will be down for a bit - replacing a failed drive - back soon | 19:37 |
| Thaodan | lbt: Sorry to break your service, I was wondering if I should use Thaodan instead of thaodan but all names in the file where lowercase | 21:57 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!