| *** zbenjamin is now known as Guest61821 | 01:40 | |
| *** zbenjamin_ is now known as zbenjamin | 01:40 | |
| *** frinring_ is now known as frinring | 01:47 | |
| dcaliste | Hello chriadam, how are you ? Thank you for the merging wave today ! ;) | 06:52 |
|---|---|---|
| chriadam | hello dcaliste, I'm well thanks. How are you? | 06:53 |
| chriadam | better late than never ;-) | 06:53 |
| chriadam | I 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 think | 06:53 |
| dcaliste | I'm fine, thank you. Flypig, are you here at the moment ? | 06:54 |
| flypig | Hello. | 06:54 |
| dcaliste | I answered your CalDAV question in the MR. | 06:54 |
| flypig | Glad to hear you're both doing well. | 06:54 |
| dcaliste | Basically, it may work for some (most ?) of the servers, the one which honour the calendar-home-set property. | 06:54 |
| dcaliste | Hello flypig, I hope you're fine too. | 06:55 |
| flypig | Yes, all good :) | 06:55 |
| dcaliste | I 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 |
| dcaliste | It's the third stage for the disbaling of alarms on calendar uncheck in the calendar app. | 06:56 |
| flypig | dcaliste, chriadam did prod me about it, but I've not had a chance to look properly yet I'm afraid. | 06:56 |
| dcaliste | No problem, do it when you have time of course. | 06:57 |
| dcaliste | Just 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 |
| dcaliste | this is replacing the QSetting exclude used before from the beginning, as far as I know from the git blame. | 06:58 |
| dcaliste | it'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 |
| dcaliste | This 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 |
| flypig | What's the importance of the second point? | 07:01 |
| dcaliste | Second 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 |
| dcaliste | flypig : that one is important indeed. | 07:01 |
| chriadam | I wonder if pvuorela could offer wisdom here, he knows far more about this layer than I do at least | 07:01 |
| chriadam | not sure if he's online yet or not though | 07:01 |
| dcaliste | Because, 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 |
| chriadam | that sounds like an improvement to me ;-) | 07:03 |
| flypig | So that's unnecessary overhead? But not affecting what the user sees? | 07:03 |
| dcaliste | Exact, but it has now a possible drawback. | 07:03 |
| chriadam | are 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 |
| dcaliste | Unchecking 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 |
| dcaliste | Or expandedRawEvents(). | 07:05 |
| chriadam | (which seems good in most cases, e.g. no alarms for events in calendars which are made invisible) | 07:06 |
| dcaliste | But it's not changing the listing like allIncidences(). | 07:08 |
| dcaliste | And in caldav at least, we're using the second class listing API, the one not affected by visibility. | 07:08 |
| dcaliste | chriadam : 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 |
| dcaliste | flypig, there is currently a minor drawback that I'm discussing in length in the MR. | 07:10 |
| dcaliste | When changing visibility of a notebook (by unchecking it in the app), the agendamodels holding the events for each day are rebuilt. | 07:10 |
| dcaliste | The list of stored events are compared to new lists. The comparison is done using a pointer to the old events. | 07:11 |
| dcaliste | Before these events were still in the manager, but not used. Now they are not in the manager and it raises warnings. | 07:11 |
| dcaliste | As discussed in the MR, I think these warnings can be removed and the events removed safely from the agendamodel. | 07:12 |
| chriadam | on the surface, I would agree. | 07:12 |
| dcaliste | I let you more time of course to think about this possible issue (or not). | 07:12 |
| flypig | I'm just reading the discussion on the MR. I'm a bit behind I'm afraid. | 07:12 |
| chriadam | I 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 |
| chriadam | i.e. not caused by the visibility change resulting in list contents mismatch | 07:13 |
| chriadam | but caused by ... something else, incorrect bug | 07:13 |
| dcaliste | Yes, thinking exactly the same, I don't know if I won't hide possible other issues by removing the warning... | 07:14 |
| chriadam | pvuorela: do you have any thoughts about what else might trigger this case? | 07:15 |
| chriadam | if we cannot come up with anything, I'd vote for just removing the warning and merging the MR | 07:15 |
| chriadam | assuming we're happy with it otherwise | 07:15 |
| flypig | What is the comparison use for? | 07:16 |
| dcaliste | flypig: no problem, but since we started this work of silencing alarms together, I guess you were interested to the discussion. | 07:16 |
| dcaliste | flypig: it's for the sorted removal. | 07:16 |
| flypig | Oh, yes, I'm definitely interested, I'm just not very useful! | 07:17 |
| dcaliste | the two lists (new and old) are compared together by going one step at a time. | 07:17 |
| dcaliste | And 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 |
| flypig | Under what circumstances would they usually be removed? | 07:19 |
| dcaliste | It'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 |
| dcaliste | flypig: visibility changes or event removal I guess. | 07:19 |
| dcaliste | Or event change of day. | 07:20 |
| flypig | So, in the current loop, the visibility is checked explicitly (since the events are still in the list)? | 07:20 |
| dcaliste | flypig, 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 changes | 07:21 |
| flypig | Thanks, 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 |
| dcaliste | which 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 |
| dcaliste | Oh, I forgot, one important step... | 07:25 |
| chriadam | huh. 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 |
| dcaliste | chriadam: the range are given per day, the DST is happening in the night, I guess it will do no harm. | 07:27 |
| chriadam | ok | 07:27 |
| dcaliste | for the missing step, in doQueryAndAgendaRefresh(), when called from the trigger of the excludedNotebook, it is calling the calendarworker::loadData. | 07:27 |
| dcaliste | And this loadData, is listing events, and NOT listing the hidden ones (while before it did). | 07:28 |
| dcaliste | this loadData() is also listing events as occurrences, and this list is filtered out. Now and before. | 07:28 |
| dcaliste | then, when coming back to the manager, we do the doQueryAndAgendaRefresh() again. | 07:29 |
| dcaliste | And the updateAgendaModel() will emit the warnings, because the event list stored in the manager is not containing the old, now hidden, events. | 07:30 |
| flypig | Could all of the now-hidden events be removed in a pre-sweep, say, since we already know they've all been removed? | 07:30 |
| dcaliste | flypig, 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 |
| dcaliste | In my opinion, the warnings are not harmfull. | 07:31 |
| dcaliste | Because the events will be removed from the agenda model anyway. | 07:31 |
| dcaliste | the warnings are emitted in the comparison atep, which is successfull anyway and thus old events are removed at the end. | 07:32 |
| bionade24 | Does 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 |
| flypig | dcaliste, could an extra check be added to the while condition to avoid the eventsLessThan being called? | 07:34 |
| dcaliste | chriadam and flypig, I'm adding a debug output for the code path in the MR to better follow what is happening. | 07:34 |
| Nico|MentorforNh | bionade24: 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.h | 07:35 |
| dcaliste | flypig, 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 |
| flypig | No way to tell that the event is in a hidden calendar? | 07:37 |
| dcaliste | I 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 |
| dcaliste | flypig: not at that level, no. Need to inquire the manager to do so. | 07:38 |
| bionade24 | Nico|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 |
| bionade24 | Nico|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|MentorforNh | Well, that is at least the easy way to do it | 07:39 |
| Nico|MentorforNh | And 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 concerns | 07:40 |
| chriadam | dcaliste: we will consider this for a couple of days (I will ask Pekka if he has any input also) | 07:41 |
| chriadam | my 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 |
| dcaliste | Sure chriadam, thanks. | 07:42 |
| chriadam | aside 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 |
| chriadam | the other one is quite large (exposing to QML) and I haven't had an opportunity to review it properly yet | 07:43 |
| dcaliste | chriadam: 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 |
| chriadam | aside 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 |
| chriadam | dcaliste: thanks, I will do so this evening | 07:44 |
| flypig | chriadam, not off the top of my head, but I'd be happy to think about it. | 07:44 |
| chriadam | thanks - would appreciate it | 07:44 |
| spoofy | Hello. 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 to | 07:45 |
| spoofy | mention that similar setup on two of my "Jollafied" Intex Aqua Fish, runs without issues after update. | 07:45 |
| spoofy | So 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 |
| flypig | My query on MR#15 is whether those UI glitches were related, or completely separate. I wasn't entirely sure from th comments. | 07:45 |
| chriadam | spoofy: pketo or mkosola may be able to help | 07:45 |
| chriadam | flypig: I will check that one again in case I misunderstood | 07:46 |
| chriadam | spoofy: or rainemak perhaps | 07:46 |
| dcaliste | chriadam: 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 |
| abranson | spoofy: cutes is an old qt framework that is no longer used in sailfish, so it's been dropped. | 07:46 |
| chriadam | yep, no worries | 07:46 |
| chriadam | was there anything else to discuss today? | 07:46 |
| spoofy | chriadam: Thanks. | 07:47 |
| flypig | chriadam, not from my side. This was helpful, thanks. | 07:47 |
| bionade24 | Nico|MentorforNh: login.login(mxid.text, password.text, homeserver.text) Is this really the way you can access C++? | 07:49 |
| bionade24 | Nico|MentorforNh: Or am I misunderstanding something? | 07:49 |
| dcaliste | chriadam: no that was already a good discussion. | 07:50 |
| dcaliste | chriadam: ah matbe just the messagingframework MR | 07:50 |
| chriadam | dcaliste: great. thanks again for your time and effort. big thanks for reviewing Bea's buteo PR! and thanks for discussion, also flypig | 07:50 |
| chriadam | oh that one? | 07:50 |
| chriadam | let me check | 07:50 |
| dcaliste | to silence the remaining bits about tfinding emails for calendars. | 07:50 |
| Nico|MentorforNh | bionade24: login is a context property (a Login*). You can call slots on that like that. | 07:50 |
| dcaliste | https://git.sailfishos.org/mer-core/messagingframework/merge_requests/39 | 07:51 |
| dcaliste | chriadam: not of the highest importance though ;) | 07:52 |
| chriadam | ah, 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 account | 07:52 |
| bionade24 | mikkoh_: Thanks, so I don't need to connect in C++, because I did it this way in QML? | 07:52 |
| chriadam | but maybe I'm misunderstanding | 07:52 |
| chriadam | bionade24: 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 parameters | 07:53 |
| Nico|MentorforNh | bionade24: Yes, but you still need to connect to the C++ signals, if you want to react to them in the Qml layer | 07:53 |
| dcaliste | chriadam: I've suppressed the warning in the account inquire method. | 07:53 |
| Nico|MentorforNh | chriadam: Yes, that is what I meant :3 | 07:53 |
| Nico|MentorforNh | Thanks | 07:53 |
| dcaliste | I 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 |
| chriadam | true, I tend to agree. | 07:54 |
| chriadam | ok, will review that one hopefully before next week | 07:54 |
| dcaliste | Because it's an inquire method, it's valid to know without warning if an account is an email one or not. | 07:54 |
| chriadam | thanks | 07:54 |
| chriadam | yes true | 07:54 |
| chriadam | more like "hey, can you use this one?" | 07:54 |
| dcaliste | Sure, it's not in a hurry, it's only only about warnings ;) | 07:54 |
| chriadam | indeed | 07:54 |
| chriadam | alright, let's end the meeting - have a great week everyone :-) | 07:55 |
| dcaliste | Have a good evening criadam, see you later. | 07:55 |
| dcaliste | sorry chriadam | 07:55 |
| chriadam | gnight! | 07:55 |
| flypig | You too, good night/day. | 07:55 |
| dcaliste | flypig, just to be sure I understand well your issue when testing MR!15: | 07:56 |
| flypig | Yes, sure. | 07:57 |
| dcaliste | if 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 |
| dcaliste | I mean, times are changing at each start of the app ? | 07:57 |
| flypig | I've not tried it with *just* an EAS account. I'd need to do that. | 07:57 |
| flypig | But yes, each time I restart the app the times seem to be different. | 07:58 |
| dcaliste | The app is syncing on start, may it have an impact ? I guess so. | 07:58 |
| flypig | Opening the app triggers a sync, so I expected it to be related to that. | 07:58 |
| dcaliste | ;) | 07:58 |
| flypig | Ah, yes, I expect so. | 07:58 |
| dcaliste | If you start without network, does it show the same effect ? | 07:59 |
| flypig | I'll have to check. | 07:59 |
| dcaliste | Just to be sure. | 07:59 |
| flypig | I can do that now... one second. | 07:59 |
| pvuorela | sorry, just noticed the discussion here. | 07:59 |
| dcaliste | Hello pvuorela, it was about https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/55 | 08:00 |
| dcaliste | As mentioned in the MR discussion, it's a final MR to avoid having alarms ringing for unchecked calendar in the calendar app. | 08:00 |
| dcaliste | The job is done by changing the visibility flag of an uncheck notebook. | 08:01 |
| dcaliste | A previous MR in mkcal bind the visibility flag with the clearAlarm code there. | 08:01 |
| pvuorela | alright. for one i'm wondering if there's any chance that affects the synchronization side. | 08:03 |
| dcaliste | Having 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 |
| dcaliste | pvuorela, 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 |
| dcaliste | I 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 |
| pvuorela | ok good. | 08:07 |
| dcaliste | :) hopefully I did my survey properly... | 08:08 |
| flypig | dcaliste, sorry for the delay. Setting up these accounts is a bit of a laborious process :( | 08:17 |
| dcaliste | flypig, sure, I don't want to eat all your time... | 08:17 |
| flypig | It's no problem... I'll get there. | 08:18 |
| flypig | dcaliste, I created you a slideshow: https://www.flypig.co.uk/images/general/calendar-network.png | 08:37 |
| flypig | I'm not too sure what to make of it myself. | 08:37 |
| dcaliste | Wouha, looking at it. I guess each new view is a new calendar app start. | 08:38 |
| flypig | Yes, exactly. | 08:38 |
| flypig | I let the syncs complete each time before closing and re-opening. | 08:38 |
| dcaliste | You killed the timezone part of mkcal storage before the start, and only there, right ? | 08:38 |
| flypig | killed timezone, created account, opened calendar (not shown), closed calendar, deleted account, created account. | 08:39 |
| flypig | Then I opened the calendar, and that's the first screenshot. | 08:39 |
| flypig | Just as a reminder, this is with your patch, but with Chris's patch removed. | 08:40 |
| flypig | But I haven't tried it with both patches, or with neither patch. Would that help? | 08:41 |
| dcaliste | Ok. Thanks a lot for your time. If you can, you may try with master only (Chris patch alone). | 08:42 |
| flypig | Okay, I'll do that. What do you think about the network/sync? | 08:42 |
| flypig | Should I include those steps in the test, or is it a red herring? | 08:42 |
| dcaliste | Now that I perfectly follow your steps, I'll try to reproduce something similar on my device. | 08:42 |
| flypig | It 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 |
| dcaliste | Seeing it changing without network is definitely interesting, because it has nothing to do then with changes in the database. | 08:43 |
| dcaliste | flypig, mine is the same... | 08:43 |
| flypig | That's somehow reassuring :) | 08:44 |
| dcaliste | But well, trying to reproduce this in a fake calendar (SQLITESTORAGEDB=$PWD/db jolla-calendar) would be of high interest. | 08:45 |
| flypig | Yours is latest release version? Or with your patch? | 08:45 |
| dcaliste | flypig, 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 |
| dcaliste | The result is often a mess in term of what is actually running, official libs or hacked ones... | 08:47 |
| flypig | Yes, you have the same problem as me: never quite know what version is running! | 08:47 |
| flypig | Okay, 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 |
| dcaliste | flypig: not completely sure, it looks related at least. But I've no clue how for the moment. | 08:49 |
| dcaliste | I'll try to reproduce in a fake calendar first locally, without network. | 08:49 |
| dcaliste | I'll report in the kcalcore MR or create a new one if necessary. | 08:50 |
| flypig | dcaliste, 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 |
| dcaliste | Thanks. Calendar is really an area full of surprises ;) | 08:51 |
| flypig | Isn't it just :) | 08:51 |
| spoofy | I'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 |
| spoofy | Ah, bad paste - sorry. | 09:26 |
| *** vals_ is now known as tango_ | 09:29 | |
| tanriol | Does 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 |
| Smar | tanriol: it worked for me yesterday | 10:43 |
| Smar | ...I think that also means that icons worked, I didn’t spot anything unusual | 10:44 |
| tanriol | Smar: 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 |
| Smar | try to reinstall f-droid first? | 10:49 |
| *** tigeli_ is now known as tigeli | 10:50 | |
| tanriol | Too late :-) | 10:53 |
| tanriol | Now 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 |
| Smar | looks like it’s still broken | 12:27 |
| tanriol | That'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 svartoyg | 14:49 | |
| *** frinring_ is now known as frinring | 17:29 | |
| Malinux | Though, 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 |
| mal | the top menu orientation lock should work in sfos 3.3.0 even with android apps | 21:34 |
| Malinux | Seems like it only works if autorotate is activeated in the android settings | 23:50 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
