| dcaliste | Good morning pvuorela, I hope you're well. | 07:59 |
|---|---|---|
| pvuorela | dcaliste: hey, i'm good, thanks. | 08:00 |
| dcaliste | Thank you for the mkcal merge and the related ones on deprecating loadSeries(). | 08:01 |
| dcaliste | On another topic, do you have objections on jolla-calendar#330 ? About displaying the recurrence end in the event view. | 08:02 |
| ViGe | Blumenkraft, mal: lastlog is a sparsefile, it's not really that big | 08:03 |
| pvuorela | dcaliste: on 330 last time left pondering how it behaves with the "edit this and later" if that doesn't mark the recurrence end to the main event. | 08:04 |
| ViGe | on my device ls -l says lastlog is 141MB, du -h says it's really 32kB | 08:04 |
| dcaliste | pvuorela, well I think it's slightly independant : #330, covers current recurring possibilities, while it will require a necessary tweak with #328. But the tweak would belong to #328. | 08:08 |
| dcaliste | I agree that it doesn't answer what to display in case of this and future exception. | 08:08 |
| dcaliste | Or more explicitly it doesn't solve how to display the this and future end, since I agree with you that it should display the next change (the end being a change too). | 08:09 |
| pvuorela | dcaliste: but maybe it's clearer if we then just set the recurrence end on the main event. would make this UI work properly and then if later editing the main event it shows what the user could expect. | 08:09 |
| pvuorela | guess i could just merge the 330 at some point now. | 08:10 |
| dcaliste | Yes, it is adding another constrain for #328 but well, it's for the best ;) | 08:10 |
| dcaliste | Actually, at the moment, with #330, the recurrence end is displayed for all recurring occurrences, but not for any exception (the recurring icon is even not present). | 08:11 |
| pvuorela | think that's good. | 08:12 |
| dcaliste | Indeed. With this and future, it should behave the same, treating the this and future as a "new parent", ending the previous recurrence, at display level, I mean. | 08:14 |
| dcaliste | Saying this, it raises a question in my mind : what should the "modify all series" display when calling it on an occurrence later than a this and future ? From a user point of view, I guess it should use the this and future as a base and not the true parent, right ? | 08:16 |
| pvuorela | uh :) | 08:17 |
| pvuorela | might make sense, but good reminder that these have tricky details involved. | 08:18 |
| pvuorela | on other things, were you planning on removing the mkcal extra load methods? | 08:20 |
| dcaliste | Yes, after the search PR will be discussed. Because, most of them look like search methods and I would like to keep them while discussing this new API. Having them in mind, ideally, it would require just a bit of change to the search method to allow them again. Or do you think, it's irrelevant, and we can adjust the API later when the need arise for such methods ? | 08:23 |
| pvuorela | they could fit some similar purposes but since nothing uses the old loaders i wouldn't think there's anything preventing deletion. so could consider the search as a separate feature. | 08:25 |
| pvuorela | for the search, just had time for a brief look on the PRs. without testing yet the first thing i was pondering is whether the calendar main pulley menu gets too full. we should have some better container for big amount of items/actions. | 08:26 |
| dcaliste | Ok, I'll prepare a PR then for removal (I guess there is no need for deprecation, just removal, right ?). | 08:27 |
| pvuorela | yea, let's just get rid of those. | 08:27 |
| dcaliste | Ok, good ! | 08:27 |
| dcaliste | Yeh, about the pull down menu, I've no idea at the moment. While actually it's still doing its job effectively. | 08:31 |
| pvuorela | yea think at least the email app is having the same amount of items as the pr. not necessarily ideal, but at least not breaking the record. | 08:33 |
| dcaliste | I still need to add a loading property, as mention in the comment, because searching for 'a' for instance (returning mostly the full database content) is currently displaying the placeholder while searching… Besides, it's still quite fast for such a silly query. | 08:36 |
| pvuorela | if that has some problems, could also consider some minimum length for search string. | 08:39 |
| dcaliste | Well, beside the initial loading time, there is no issue when using SilicaListView, since only some of the items are instanciated. It's still quite fluid. It is occupying memory though, since all incidences are loaded into the memory calendar. Luckily, the next sync will flush the memory calendar if the database is touched. | 08:43 |
| pvuorela | added comment on the mkcal, suppose that's not filtering out disabled notebook now. | 08:44 |
| dcaliste | And anyway, I need to add this loading property to the model since the search is async and even for valid queries, it may take some hundreds of milliseconds. | 08:44 |
| dcaliste | Yeh, about filtering, I'm wondering at which level doing it. I'm not sure it should be done at DB level, even if it would simplify things. Maybe more at nemo-qml-plugin-calendar level… | 08:45 |
| dcaliste | Because load methods don't care about disabled calendars. | 08:46 |
| pvuorela | right. | 08:46 |
| dcaliste | The date range method method in mkcal for instance is loading everything in range. | 08:46 |
| dcaliste | The filtering out is done in calendarworker. | 08:46 |
| dcaliste | Here, it would require a bit more code, since it would require to filter out the instance identifier list as returned by the worker. | 08:47 |
| dcaliste | Not a bit deal though. | 08:47 |
| piggz | rinigus: have you tried building chum gui in sdk? | 08:52 |
| dcaliste | That raises the question of optimisation : should we actually filter out at mKCal level in general ? This requires a bit of profiling to see what could be gained. We would gained on the number of created incidences, but the join in the query to get the notebook visibility may be more expensive than creating useless incidences and trash them after. | 08:56 |
| dcaliste | Since actually, disabled calendars should be the minority case. | 08:57 |
| dcaliste | I mean, a range query (or a search one) should return much more incidences for enabled calendars than for disabled ones. | 08:58 |
| pvuorela | dcaliste: overall it wouldn't harm doing some profiling on how long different operations take. maybe related on those recent reviews was commenting on nemo-calendar worker going through all the events it knows etc. | 08:58 |
| dcaliste | I did some profiling a while ago on a real case calendar (mine…) at nemo-qml-plugin-calendar level. In the worker, the bottle neck is currently not the rawEvent() call and the loop that goes with it, but actually the OccurrenceIterator when calculating the occurrences for the given ranges. There was a factor 10 between the two as far as I remember. | 09:01 |
| dcaliste | But doing it again, to be sure and save it as a test would be good. | 09:01 |
| dcaliste | The main culprit in OccurrenceIterator, as far as I remember (but don't completely sure now), were the birthdays, because they are creating a lot recurring events that the iterator need to create occurrences for, even if the ranges have month granularity. | 09:03 |
| dcaliste | Thank you pvuorela for your time and for the discussion. I'll create a PR purging the unused load methods from mKCal. And try to develop the performence test in mKCal and add one in nemo-qml-plugin-calendar. I mean besides current PRs ;) | 09:28 |
| pvuorela | dcaliste: cheers :) | 09:29 |
| mal | ViGe: good to know, thanks | 11:50 |
| rinigus | piggz: not recently. when writing it, yes | 16:48 |
| piggz | rinigus: i figured out the issues | 16:49 |
| piggz | the sdk was adding Ninja as the build system | 16:49 |
| piggz | and, by default the ram in the sdk is 1gb, and the builds were exhausting it! | 16:49 |
| rinigus | :) | 16:50 |
| piggz | rinigus: b.s.o seems to be fixed ... | 16:54 |
| piggz | lbt: Keto ^^ can you confirm of some work has been done? | 16:55 |
| rinigus | piggz: noooh, how is that possible... I was expecting a switch to `nemo` as a defaultuser name in the future SFOS release as well | 16:56 |
| piggz | lol :D | 16:57 |
| piggz | L0lapu55 | 17:02 |
| piggz | ignore that, i now have a password to change! | 17:03 |
| Blumenkraft | ViGe, Thank you for the info. | 17:07 |
| Keto | piggz: yes, build.sailfishos.org domain should work for now | 17:08 |
| piggz | Keto: what does "for now" mean? | 17:10 |
| Keto | until it breaks :) | 17:10 |
| piggz | Keto: forgive my missunderstanding of the situation ... but is it more complex than a dns setting? | 17:14 |
| Keto | yes | 17:19 |
| Keto | it now points to the same place as build.merproject.org, so both should work the same. but it's all still on the old hardware | 17:23 |
| piggz | yeah, thats what i found confusing ... as one worked, but the other didnt, but it was just the name that didnt work, and i cant figure out if its not a dns issue, that what is it! :D | 17:25 |
| lbt | it was that the mer domain went through a reverse proxy on a good machine, the reverse proxy handling sfos had some weird undiagnosable issue | 18:00 |
| piggz | lbt: ah ok | 18:08 |
| tanriol | Is it possible to somehow remove the emergency call option from the lock screen? | 18:42 |
| pherjung[m] | Perhaps with commenting the part which control that | 18:43 |
| pherjung[m] | but I wouldn't do it | 18:43 |
| tanriol | Do you mean that it's dangerous from the Sailfish POV or that it should be there "for safety"? | 18:44 |
| pherjung[m] | I meant for the stability of the system | 18:45 |
| pherjung[m] | It may breaks some stuff if you don't know what you exactly do | 18:45 |
| tanriol | Yeah, I suppose I should look into doing that via patchmanager | 18:46 |
| pherjung[m] | You should look for qml files | 18:47 |
| pherjung[m] | grep is your friend. Perhaps search for a patchmanager which changes the dialler | 18:48 |
| tanriol | And ensure I've got root ssh access before trying that :-) | 18:48 |
| pherjung[m] | I do a copy of the modified file | 18:48 |
| pherjung[m] | s/I/Do/, s/do// | 18:53 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!