Tuesday, 2020-04-07

*** zbenjamin is now known as Guest6182101:40
*** zbenjamin_ is now known as zbenjamin01:40
*** frinring_ is now known as frinring01:47
dcalisteHello chriadam, how are you ? Thank you for the merging wave today ! ;)06:52
chriadamhello dcaliste, I'm well thanks.  How are you?06:53
chriadambetter late than never ;-)06:53
chriadamI had a couple of questions about the caldav one, aside from that it LGTM, and flypig had some questions about two of the MRs I think06:53
dcalisteI'm fine, thank you. Flypig, are you here at the moment ?06:54
dcalisteI answered your CalDAV question in the MR.06:54
flypigGlad to hear you're both doing well.06:54
dcalisteBasically, it may work for some (most ?) of the servers, the one which honour the calendar-home-set property.06:54
dcalisteHello flypig, I hope you're fine too.06:55
flypigYes, all good :)06:55
dcalisteI would like to discuss with you both this MR : https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/55 if you don't kind ?06:55
dcalisteIt's the third stage for the disbaling of alarms on calendar uncheck in the calendar app.06:56
flypigdcaliste, chriadam did prod me about it, but I've not had a chance to look properly yet I'm afraid.06:56
dcalisteNo problem, do it when you have time of course.06:57
dcalisteJust to explain :06:57
dcaliste- the visibility of notebooks (mkcal defined) is now used to check or uncheck calendars in the setting page of calendar app.06:58
dcalistethis is replacing the QSetting exclude used before from the beginning, as far as I know from the git blame.06:58
dcalisteit's not chaning the API, and nemo-qml-plugin-calendar is still using the excluded list as an entry for in its API.06:59
dcalisteThis has two direct consequences:06:59
dcaliste- the storage is written (and reloaded) on setting page pop in calendar app.06:59
dcaliste- the listing method from mkcal are NOT returning the not visible events anymore.07:00
flypigWhat's the importance of the second point?07:01
dcalisteSecond change in nemo-qml-plugin-calendar : the enable / disable setting of the account /service treating a given notebook is used not to list at all the notebook in the calendar app.07:01
dcalisteflypig : that one is important indeed.07:01
chriadamI wonder if pvuorela could offer wisdom here, he knows far more about this layer than I do at least07:01
chriadamnot sure if he's online yet or not though07:01
dcalisteBecause, I've seen that before this MR, the calendarmanager in the qml binding was storing ALL events from the storage, even for hidden notebooks.07:02
chriadamthat sounds like an improvement to me ;-)07:03
flypigSo that's unnecessary overhead? But not affecting what the user sees?07:03
dcalisteExact, but it has now a possible drawback.07:03
chriadamare there any cases where you think this semantic change could cause a problem?  I'm thinking of cases like sync (if the user modifies an event, then later the calendar somehow becomes disabled, then the account is synced - what happens to the event modification?)07:03
dcalisteUnchecking a calendar in changing the visibility flag for the notebook. It is changing the listing of events in mkcal, when using methods like rawEvents().07:05
dcalisteOr expandedRawEvents().07:05
chriadam(which seems good in most cases, e.g. no alarms for events in calendars which are made invisible)07:06
dcalisteBut it's not changing the listing like allIncidences().07:08
dcalisteAnd in caldav at least, we're using the second class listing API, the one not affected by visibility.07:08
dcalistechriadam : yes for alarms, that's the purpose of all these MR, linking notebook visibility to alarm, and calendar check and uncheck to visibility.07:09
dcalisteflypig, there is currently a minor drawback that I'm discussing in length in the MR.07:10
dcalisteWhen changing visibility of a notebook (by unchecking it in the app), the agendamodels holding the events for each day are rebuilt.07:10
dcalisteThe list of stored events are compared to new lists. The comparison is done using a pointer to the old events.07:11
dcalisteBefore these events were still in the manager, but not used. Now they are not in the manager and it raises warnings.07:11
dcalisteAs discussed in the MR, I think these warnings can be removed and the events removed safely from the agendamodel.07:12
chriadamon the surface, I would agree.07:12
dcalisteI let you more time of course to think about this possible issue (or not).07:12
flypigI'm just reading the discussion on the MR. I'm a bit behind I'm afraid.07:12
chriadamI wonder what cases could arise which that warning would be useful (i.e. would let the developer know that there is some actual problem which deserves further investigation)07:12
chriadami.e. not caused by the visibility change resulting in list contents mismatch07:13
chriadambut caused by ... something else, incorrect bug07:13
dcalisteYes, thinking exactly the same, I don't know if I won't hide possible other issues by removing the warning...07:14
chriadampvuorela: do you have any thoughts about what else might trigger this case?07:15
chriadamif we cannot come up with anything, I'd vote for just removing the warning and merging the MR07:15
chriadamassuming we're happy with it otherwise07:15
flypigWhat is the comparison use for?07:16
dcalisteflypig: no problem, but since we started this work of silencing alarms together, I guess you were interested to the discussion.07:16
dcalisteflypig: it's for the sorted removal.07:16
flypigOh, yes, I'm definitely interested, I'm just not very useful!07:17
dcalistethe two lists (new and old) are compared together by going one step at a time.07:17
dcalisteAnd if an old item is lower than a new one, it means it has been removed, and it is popped from the model then.07:17
flypigUnder what circumstances would they usually be removed?07:19
dcalisteIt's difficult to check by looking at the code if objectEvent() call may return an empty value because it is used in a lot of places and behind getEvent() which is also massively used.07:19
dcalisteflypig: visibility changes or event removal I guess.07:19
dcalisteOr event change of day.07:20
flypigSo, in the current loop, the visibility is checked explicitly (since the events are still in the list)?07:20
dcalisteflypig, not sure I understand fully your question, but the visibility change code path is this one:07:20
dcaliste- setExcludedNotebooks()07:21
dcaliste- calendarworker changes the flag and notify for excluded changes07:21
flypigThanks, I'm just looking at that now then.07:21
dcaliste- manager catches the signal and trigger the timer for 5ms.07:22
dcaliste- the trigger of the timer is calling doQueryAndAgendaRefresh.07:23
dcalistewhich is calling updateAgendaModel(), which calls agendamodel::dorefresh()07:24
dcaliste- and finally you arrive at the update code in agenda model comparing the old and new lists.07:24
dcalisteOh, I forgot, one important step...07:25
chriadamhuh.  so if the 5ms timer happened to chance occur right at a DST boundary, for example, could it be that the list contents would differ (i.e. is it bounded by range?)07:26
dcalistechriadam: the range are given per day, the DST is happening in the night, I guess it will do no harm.07:27
dcalistefor the missing step, in doQueryAndAgendaRefresh(), when called from the trigger of the excludedNotebook, it is calling the calendarworker::loadData.07:27
dcalisteAnd this loadData, is listing events, and NOT listing the hidden ones (while before it did).07:28
dcalistethis loadData() is also listing events as occurrences, and this list is filtered out. Now and before.07:28
dcalistethen, when coming back to the manager, we do the doQueryAndAgendaRefresh() again.07:29
dcalisteAnd the updateAgendaModel() will emit the warnings, because the event list stored in the manager is not containing the old, now hidden, events.07:30
flypigCould all of the now-hidden events be removed in a pre-sweep, say, since we already know they've all been removed?07:30
dcalisteflypig, I though about this, but I'm afraid the changes to the binding code will be too huge to avoid mistake in that  case.07:31
dcalisteIn my opinion, the warnings are not harmfull.07:31
dcalisteBecause the events will be removed from the agenda model anyway.07:31
dcalistethe warnings are emitted in the comparison atep, which is successfull anyway and thus old events are removed at the end.07:32
bionade24Does anyone can point me to some login page backend example? I trying to find it currently in sailorgram but I can't find anything.07:32
flypigdcaliste, could an extra check be added to the while condition to avoid the eventsLessThan being called?07:34
dcalistechriadam and flypig, I'm adding a debug output for the code path in the MR to better follow what is happening.07:34
Nico|MentorforNhbionade24: Not sure, if it is a good example, but here is my login page backend: https://nheko.im/nheko-reborn/spoon/-/blob/master/src/login.h07:35
dcalisteflypig, that would be a safe way to do this, but there is no function to query if the manager is storing a given event, beside the objectEvent() one, which is emitting the warnings.07:37
flypigNo way to tell that the event is in a hidden calendar?07:37
dcalisteI can add one, which is not emitting warning (like an inquire), and base the getter on the inquire function and keep the warning in the getter.07:37
dcalisteflypig: not at that level, no. Need to inquire the manager to do so.07:38
bionade24Nico|MentorforNh: Thanks, I'm struggling to get good C++ QML interaction, as it seems for me like that I only can connect to QML signals of the active QML file. Is this right?07:38
bionade24Nico|MentorforNh: Thanks, I'm struggling to get good C++ QML interaction, as it seems for me like that I only can connect to QML signals of the active QML file. Is this right?07:38
Nico|MentorforNhWell, that is at least the easy way to do it07:39
Nico|MentorforNhAnd you also usually want to do the connection in the Qml side, since it keeps the Qml as more of a presentation layer and makes it easier to separate concerns07:40
chriadamdcaliste: we will consider this for a couple of days (I will ask Pekka if he has any input also)07:41
chriadammy opinion is: I think it's safe, and can't think of cases where such a warning would help us track down a problem.  but I might be wrong.07:41
dcalisteSure chriadam, thanks.07:42
chriadamaside from that: there are two buteo-syncfw MRs which are pending, one of which I will merge and tag as soon as Bea's PR has made it through the CI gate (may have already)07:42
chriadamthe other one is quite large (exposing to QML) and I haven't had an opportunity to review it properly yet07:43
dcalistechriadam: I've added a couple of comments in the caldav discovery MR. If you can dump part of your account db, I won't have to create a carddav only account myself ;)07:43
chriadamaside from that, the kcalcore MR#15 might need some more discussion and testing (flypig, can you think of a unit test which could be added to simulate the exchange case?)07:43
chriadamdcaliste: thanks, I will do so this evening07:44
flypigchriadam, not off the top of my head, but I'd be happy to think about it.07:44
chriadamthanks - would appreciate it07:44
spoofyHello. For about 2 days I'm constantly reflashing my xperias - f5121 aka single sim X and h4413 aka XA2 plus dual sim - both are getting bricked after updating to Rokua. Tried diffrent setups (luks on/off, 3rd pary repos on/off), but everytime after reboot I stuck at boot with sony logo. I think it's like: https://together.jolla.com/question/224414/bricked-my-xa2-plus-after-33014-update/ . I need to07:45
spoofymention that similar setup on two of my "Jollafied" Intex Aqua Fish, runs without issues after update.07:45
spoofySo I've got three questions: 1. When full image 3.3 Rokua will be available to download at shop.jolla.com/downloads? 2. Why after update from 3.2 to 3.3 "cutes-qt5" is not available in any repository? 3. Someone has any idea of what can cause the problem? Any help you could provide would be much appreciated.07:45
flypigMy query on MR#15 is whether those UI glitches were related, or completely separate. I wasn't entirely sure from th comments.07:45
chriadamspoofy: pketo or mkosola may be able to help07:45
chriadamflypig: I will check that one again in case I misunderstood07:46
chriadamspoofy: or rainemak perhaps07:46
dcalistechriadam: for the QML binding, it's still WIP from my side as adding the write part may change the read-only API. And I didn't rework it since then.07:46
abransonspoofy: cutes is an old qt framework that is no longer used in sailfish, so it's been dropped.07:46
chriadamyep, no worries07:46
chriadamwas there anything else to discuss today?07:46
spoofychriadam: Thanks.07:47
flypigchriadam, not from my side. This was helpful, thanks.07:47
bionade24Nico|MentorforNh: login.login(mxid.text, password.text, homeserver.text) Is this really the way you can access C++?07:49
bionade24Nico|MentorforNh: Or am I misunderstanding something?07:49
dcalistechriadam: no that was already a good discussion.07:50
dcalistechriadam: ah matbe just the messagingframework MR07:50
chriadamdcaliste: great.  thanks again for your time and effort.  big thanks for reviewing Bea's buteo PR!  and thanks for discussion, also flypig07:50
chriadamoh that one?07:50
chriadamlet me check07:50
dcalisteto silence the remaining bits about tfinding emails for calendars.07:50
Nico|MentorforNhbionade24: login is a context property (a Login*). You can call slots on that like that.07:50
dcalistechriadam: not of the highest importance though ;)07:52
chriadamah, need to consider that one, as in this case it seems to me like this warning might be useful for the case where qmf is told to sync an account, but it turns out the account isn't an email account07:52
bionade24mikkoh_: Thanks, so I don't need to connect in C++, because I did it this way in QML?07:52
chriadambut maybe I'm misunderstanding07:52
chriadambionade24: I think Nico was saying that the first "login" is  C++ QObject, exposed to QML via a context property.  and it has a Q_SLOT or Q_INVOKABLE method login() which takes those parameters07:53
Nico|MentorforNhbionade24: Yes, but you still need to connect to the C++ signals, if you want to react to them in the Qml layer07:53
dcalistechriadam: I've suppressed the warning in the account inquire method.07:53
Nico|MentorforNhchriadam: Yes, that is what I meant :307:53
dcalisteI think it's the caller responsability in that case to emit warnings if they cannot handle the case of a returned invalid account.07:54
chriadamtrue, I tend to agree.07:54
chriadamok, will review that one hopefully before next week07:54
dcalisteBecause it's an inquire method, it's valid to know without warning if an account is an email one or not.07:54
chriadamyes true07:54
chriadammore like "hey, can you use this one?"07:54
dcalisteSure, it's not in a hurry, it's only only about warnings ;)07:54
chriadamalright, let's end the meeting - have a great week everyone :-)07:55
dcalisteHave a good evening criadam, see you later.07:55
dcalistesorry chriadam07:55
flypigYou too, good night/day.07:55
dcalisteflypig, just to be sure I understand well your issue when testing MR!15:07:56
flypigYes, sure.07:57
dcalisteif you do put your device in Brisbane, remove all timezone from mkcal db, sync your EAS account only, you have the issue also ?07:57
dcalisteI mean, times are changing at each start of the app ?07:57
flypigI've not tried it with *just* an EAS account. I'd need to do that.07:57
flypigBut yes, each time I restart the app the times seem to be different.07:58
dcalisteThe app is syncing on start, may it have an impact ? I guess so.07:58
flypigOpening the app triggers a sync, so I expected it to be related to that.07:58
flypigAh, yes, I expect so.07:58
dcalisteIf you start without network, does it show the same effect ?07:59
flypigI'll have to check.07:59
dcalisteJust to be sure.07:59
flypigI can do that now... one second.07:59
pvuorelasorry, just noticed the discussion here.07:59
dcalisteHello pvuorela, it was about https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/5508:00
dcalisteAs mentioned in the MR discussion, it's a final MR to avoid having alarms ringing for unchecked calendar in the calendar app.08:00
dcalisteThe job is done by changing the visibility flag of an uncheck notebook.08:01
dcalisteA previous MR in mkcal bind the visibility flag with the clearAlarm code there.08:01
pvuorelaalright. for one i'm wondering if there's any chance that affects the synchronization side.08:03
dcalisteHaving this done, is actually raising some warnings, as discussed earlier here or in the MR. We were wondering the validity of these warnings.08:04
dcalistepvuorela, about the sync part, I've checked that for CalDAV at least, the mkcal methods used to list events are not affected by the visibility.08:04
dcalisteI may be wrong but the affected methods are:08:05
dcaliste- rawEvents() and expandedRawEvents() which are used in the QML bindings,08:05
dcaliste- while allIncidences() or deletedIncidences() or modifiedIncidences() as used in the CalDAV plugin are not affected by visibility changes.08:05
pvuorelaok good.08:07
dcaliste:) hopefully I did my survey properly...08:08
flypigdcaliste, sorry for the delay. Setting up these accounts is a bit of a laborious process :(08:17
dcalisteflypig, sure, I don't want to eat all your time...08:17
flypigIt's no problem... I'll get there.08:18
flypigdcaliste, I created you a slideshow: https://www.flypig.co.uk/images/general/calendar-network.png08:37
flypigI'm not too sure what to make of it myself.08:37
dcalisteWouha, looking at it. I guess each new view is a new calendar app start.08:38
flypigYes, exactly.08:38
flypigI let the syncs complete each time before closing and re-opening.08:38
dcalisteYou killed the timezone part of mkcal storage before the start, and only there, right ?08:38
flypigkilled timezone, created account, opened calendar (not shown), closed calendar, deleted account, created account.08:39
flypigThen I opened the calendar, and that's the first screenshot.08:39
flypigJust as a reminder, this is with your patch, but with Chris's patch removed.08:40
flypigBut I haven't tried it with both patches, or with neither patch. Would that help?08:41
dcalisteOk. Thanks a lot for your time. If you can, you may try with master only (Chris patch alone).08:42
flypigOkay, I'll do that. What do you think about the network/sync?08:42
flypigShould I include those steps in the test, or is it a red herring?08:42
dcalisteNow that I perfectly follow your steps, I'll try to reproduce something similar on my device.08:42
flypigIt would be good to have it confirmed on another device. My device isn't generally very clean (it gets a lot of hacked code added).08:43
dcalisteSeeing it changing without network is definitely interesting, because it has nothing to do then with changes in the database.08:43
dcalisteflypig, mine is the same...08:43
flypigThat's somehow reassuring :)08:44
dcalisteBut well, trying to reproduce this in a fake calendar (SQLITESTORAGEDB=$PWD/db jolla-calendar) would be of high interest.08:45
flypigYours is latest release version? Or with your patch?08:45
dcalisteflypig, depends, when I upgrade my modifications are removed, but not always because sometime, I just copy the recompiled libs, without touching the rpms, so the upgrade don't overwrite.08:46
dcalisteThe result is often a mess in term of what is actually running, official libs or hacked ones...08:47
flypigYes, you have the same problem as me: never quite know what version is running!08:47
flypigOkay, no problem. I'll run some more tests here too. It sort of feels like this is nothing to do with your or Chris's change though.08:47
dcalisteflypig: not completely sure, it looks related at least. But I've no clue how for the moment.08:49
dcalisteI'll try to reproduce in a fake calendar first locally, without network.08:49
dcalisteI'll report in the kcalcore MR or create a new one if necessary.08:50
flypigdcaliste, okay, great, thank you. I'll also add to the MR (or message you here if you still happen to be around) if I have test results to share.08:51
dcalisteThanks. Calendar is really an area full of surprises ;)08:51
flypigIsn't it just :)08:51
spoofyI'll past journal logs and send you link.oraz oświadczenie. Jeśli oświadczenie jest poprawnie wypełnione, a koperta z kartą do głosowania zaklejona, ta druga zostaje wrzucona do urny wyborczej.09:26
spoofyAh, bad paste - sorry.09:26
*** vals_ is now known as tango_09:29
tanriolDoes anyone here use F-Droid on Android 8.1 support (XA2)? For me it does not load app icons, showing just a generic icon instead. Is this a known problem or is something wrong with my device?10:20
Smartanriol: it worked for me yesterday10:43
Smar...I think that also means that icons worked, I didn’t spot anything unusual10:44
tanriolSmar: It did not work for me for months at least... I'm actually not sure whether it ever worked. Ok, no valuable information on that device, going to try a factory reset :-)10:49
Smartry to reinstall f-droid first?10:49
*** tigeli_ is now known as tigeli10:50
tanriolToo late :-)10:53
tanriolNow for a different question: according to TJC, at some point Firefox Sync was known not to work on XA2. Any information about whether this should have been fixed?11:01
Smarlooks like it’s still broken12:27
tanriolThat's a pity :-( after the Android orientation lock fix this is the main problem still stopping me from switching to XA2 in daily use.13:50
*** svartoyg_afk is now known as svartoyg14:49
*** frinring_ is now known as frinring17:29
MalinuxThough, still you have to lock/unlock android orientation from within the Android settings. or is there a way to either have it work with the orientation lock in the drop down menu?21:10
malthe top menu orientation lock should work in sfos 3.3.0 even with android apps21:34
MalinuxSeems like it only works if autorotate is activeated in the android settings23:50

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