| keithzg[m] | Hmm are there any alternate email GUI clients? (Trying on a PinePhone and running into the problems of Gecko crashing, too bad there's no option to just only use plaintext haha) | 04:23 |
|---|---|---|
| rinigus | keithzg: no, there is no alternative. As it is closed source as well, we can't fix it either. | 06:20 |
| keithzg[m] | rinigus: Alas! That might kill it for the use-case the friend I'm loaning the PinePhone to has, but that's how it goes. | 06:36 |
| keithzg[m] | Maybe he'll be happy just using it as a far less frustrating interface for Reddit than his failing, finicky Android phone :D | 06:37 |
| deathmist | Thaodan: mind reviewing the PR itself from yesterday? :p | 06:47 |
| keithzg[m] | Oho, on the Forum someone pointed to https://github.com/sailfishos/gecko-dev/pull/121 so this has actually been fixed, here's hoping it makes it into the next release | 07:37 |
| pekkaponi | dcaliste: g'morning | 08:08 |
| *** pekkaponi is now known as pvuorela | 08:08 | |
| dcaliste | Good morning pvuorela. | 08:08 |
| dcaliste | Thank you for the recent DST merge. I need to finish the notification part now ! | 08:09 |
| pvuorela | sure, thanks to you too. | 08:09 |
| dcaliste | I've been a bit side-tracked by https://github.com/mer-hybris/ofono-ril-plugin/pull/6 | 08:10 |
| dcaliste | Slava is reviewing it. | 08:10 |
| pvuorela | looked like a good catch | 08:11 |
| dcaliste | A funny issue about rejected calls that ring again some seconds after, depending on operator. | 08:11 |
| dcaliste | When you can reproduce, it's always easier to look after. | 08:12 |
| dcaliste | About pending MRs (almost none remain), I've addressed jpetrell comments on jolla-calendar#312 on the UI part. | 08:13 |
| dcaliste | The QML bindings are https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/16 | 08:13 |
| dcaliste | And the caldav changes in https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/10 | 08:13 |
| pvuorela | yep, still didn't manage to test that but the changes didn't look too intrusive. | 08:14 |
| dcaliste | Yeh, thanks. | 08:14 |
| pvuorela | one thing again getting my attention is this "web" on the texts :) | 08:14 |
| dcaliste | I'm open to change any phrasing in labels. There was a somehow long discussion with flypig in the initial commit introducing these as far as I remember. | 08:15 |
| dcaliste | About intrusive changes, I've finally started to rework nemo-qml-plugin-calendar to get rid of the duplication of incidence data in CalendarData::Event. It is fine if we want to use various backend, but I think KCalendarCore is there to stay. | 08:16 |
| pvuorela | there has been something but getting lost in the old activity. could comment that more on the PR again and this time not in the changed lines. | 08:17 |
| dcaliste | So I'm moving KCalendarCore::Incidence::Ptr as the main structure in the manager and related objects exposing data to QML. | 08:17 |
| dcaliste | ^ ok, I'll copy the previous comments in a visible part of the PR this afternoon. | 08:18 |
| dcaliste | About nemo-qml-plugin-calendar, these are extensive changes (but keeping the public API), so it's not ready yet and still in progress. | 08:19 |
| dcaliste | I'm tracking the elapsed time to check against any regression, | 08:19 |
| pvuorela | one immediate concern on incidence::ptr is thread safety. | 08:20 |
| dcaliste | But doing such a move allow also to remove some quircks like the problem of getting attendees async. | 08:20 |
| dcaliste | About thread safety, I've think about it a long time before to check that it will be fine, here is the reasioning : | 08:20 |
| dcaliste | - the worker thread is creating KCalendar::Incidence::Ptr and passing them to the manager, but still holding them also in its own calendar. This can work only if: | 08:21 |
| dcaliste | - the worker thread is not modifying any content of its incidences. | 08:22 |
| dcaliste | - the manager is not doing any modification either. | 08:22 |
| dcaliste | The two previous points are valid because : | 08:22 |
| dcaliste | - on database modification, mKCal is recreating new pointer for the modified incidences, so the manager is then holding a detached copy of the old version, up to the point the dataLoaded signal is received and the incidence are renewed, as before with the old struct. | 08:24 |
| dcaliste | - for CalendarEventModification, it's always cloning the manager incidence before working on them. So not any modification done in UI is propagated to the database by incidence observer system. | 08:25 |
| dcaliste | And, I'm modifying the internal API of the manager to ensure that programmatically one cannot violate the two previous assumption (i.e. it is not exposing the internal KCalendarCore::Incidence::Ptr but always QObject based on it, with or without cloning). | 08:27 |
| dcaliste | The only issue is that I don't see how to do all these changes adiabatically so the PR will be very long :/ | 08:27 |
| pvuorela | ok. but in this case "modifying any content" is roughly the same as calling any method. | 08:28 |
| pvuorela | i.e. just a getter can have internal side-effects that are not thread safe. | 08:29 |
| dcaliste | This is safe, as long as mKCal is not updating (in the sense of calling a setter on an incidence) any Ptr that are shared with the manager (so the getters on UI side always return the same value whatever happen in the worker thread). | 08:30 |
| dcaliste | And mKCal is never updating incidence. It's always creating new. | 08:31 |
| dcaliste | "Modified incidences" are actually removed from the internal calendar (so detached to the manager in that case) before the new version is added. | 08:31 |
| pvuorela | alright | 08:32 |
| dcaliste | Well, I agree that this is very theoretical at the moment, I've still one or two tests not passing. And then, I need to test on device, in real life. | 08:32 |
| dcaliste | The final objective (beside decreasing the duplication of code between QML bindings and upstream)) is to support any incidences, not only events for "free". | 08:33 |
| dcaliste | And the burden to support a new part of KCalendarCore (like attachment) will com for free also. No need to add lines to copy things from Ptr to CalendarData::Event… | 08:34 |
| pvuorela | ok, let's see. maybe one good thing with copied parts is that we are more in charge of what the qml api looks like. | 08:35 |
| dcaliste | Oh, I'm keeping the QML API intact. Just the internal storage in based on KCalendarCore instead of homemade copies. About things that are not 1to1, it's converted when needed y the objects exposed to QML. | 08:36 |
| dcaliste | So we can still expose what is convenient for the UI part without being tight to rfc5545 view of things. | 08:37 |
| pvuorela | ok, good :) | 08:37 |
| dcaliste | I think I'll publish the PR as a WIP later in the week, but I'll continue to test it for a while before removing the WIP flag. | 08:38 |
| dcaliste | Besides, I'll be on vacation newt week. If you don't mind, we can resume meetings Tuesday 22nd ? | 08:39 |
| dcaliste | s/newt/next/ | 08:39 |
| pvuorela | sure, sounds good. | 08:40 |
| dcaliste | Great, thank you very much also for the yesterday's offer. | 08:40 |
| pvuorela | sure :) | 08:41 |
| dcaliste | So to sum up, I'm going to copy the comments on labelling in jolla-calendar#312 for better visibility and renewed discussion, and publish the notification part of DST work. | 08:44 |
| pvuorela | alright. i'll comment on the calendar too. | 08:45 |
| pvuorela | guess we are otherwise done. | 08:45 |
| pvuorela | or i didn't have anything else at least. | 08:45 |
| dcaliste | Yeh, me neither thank you for the meeting today and see you in two weeks. | 08:45 |
| pvuorela | see you and have a nice vacation! | 08:46 |
| rinigus | lbt: this is that annoying daily reminder regarding OBS dod packages. Keto stated that you would have to look into it | 12:59 |
| lbt | rofl - ty | 13:00 |
| lbt | rinigus: looks done now | 13:22 |
| rinigus | lbt: indeed. thank you! | 13:23 |
| piggz | lbt: did you see my Q about obs caching? | 14:02 |
| abranson | piggz: I think tar_git does caching | 15:37 |
| piggz | abranson: thought it must ... frustrating if u accidentally set a repo to private! | 15:38 |
| abranson | It clones the repos into a local path, then just pulls when rebuilding. Could be that it's caching the failed repo. | 15:40 |
| piggz | it started working again after i renamed the repo | 15:44 |
| lbt | I didn't see. But yes - as abranson says. | 16:31 |
| nephros-nc-bridge_ | [nctalk] <nephros> Testing from bridge - is this thing on? | 18:43 |
| attah | *feedback noise* | 18:44 |
| Nico | No, I think it isn't on | 18:44 |
| nephros-nc-bridge_ | [nctalk] <nephros> Thanks - /me silent again | 18:47 |
| Nico | What is nctalk? | 18:47 |
| nephros-nc-bridge_ | [nctalk] <nephros> Nextcloud talk which can bridge all kinds of things through matterbridge. | 18:48 |
| Nico | Ah, nc == nextcloud, ty! :3 | 18:49 |
| nephros-nc-bridge_ | [nctalk] <nephros> So here I'm writing from the SFos nextcloud talk app to my private nc server which has a bridge to IRC. | 18:50 |
| Nico | and on the other end is me. On my private matrix server, bridged via the libera.chat matrix bridge | 18:50 |
| nephros-nc-bridge_ | [nctalk] <nephros> We apparently are living in the future | 18:51 |
| Nico | I'm glad the internet is allowing for such things again, at some point it looked a bit grim :3 | 18:51 |
| attah | Obligatory: https://xkcd.com/927/ | 18:52 |
| Nico | I expected https://xkcd.com/1782/ | 18:52 |
| attah | I'm not the one bridging though ;) | 18:54 |
| Nico | Close enough! | 18:54 |
| nephros-nc-bridge_ | [nctalk] <nephros> I wonder: what if one created an infinite loop of bridges? | 18:56 |
| Nico | Bad times :3 | 18:57 |
| attah | My friends dad (early IT consultant) put call forwarding in a circle on 4 phones back in the day... | 18:59 |
| Nico | I once had a bot reply loop. Was fun :3 | 19:00 |
| *** kimmoli_ is now known as kimmoli | 21:17 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!