| poetaster | Thaodan, yeah, obs is really very nice to use. and stuff like managing libraries which is impossible with openrepos becomes doable. | 06:46 |
|---|---|---|
| poetaster | piggz_, rinigus I've tested libupnp6 and the c++ wrapper from chum:testing parallel to ade's libs. they don't conflict. | 06:51 |
| dcaliste | Good morning pvuorela. | 06:59 |
| pvuorela | dcaliste: good morning | 06:59 |
| piggz_ | poetaster: great | 07:03 |
| poetaster | yo, I'm requesting to push to chum. I think libupnp needs to be there first, then libupnpp then donnie | 07:04 |
| pvuorela | dcaliste: i've been waiting to get someone review my notebook prs that are needed to merge yours. unfortunately that didn't yet happen. | 07:05 |
| poetaster | piggz_, this I should probably learn to automate. I had just taken over the original approach and updated a library | 07:05 |
| dcaliste | Hello again pvuorela, sorry it seems I lost IRC connection for a while and didn't notice. | 07:39 |
| pvuorela | dcaliste: sure. in case the earlier message was lost said that i was still waiting for my notebook prs to get reviewed before merging the set. | 07:40 |
| dcaliste | Strange, looking in the logs, my questions were not there but you answer them anyway ! | 07:40 |
| pvuorela | :) | 07:41 |
| dcaliste | Ok, so let's wait for approval from someone else. | 07:41 |
| pvuorela | and also hoping to get that calendar design now some day. | 07:41 |
| pvuorela | otherwise i don't have much. was hoping to get the notebook things in before starting to look into the next ones. | 07:42 |
| dcaliste | Great. Thank you. | 07:42 |
| dcaliste | Sure. About the next one. It's actually discoupled, but to avoid painfull rebase, I've started it directly on top. | 07:42 |
| pvuorela | yea, makes sense. | 07:43 |
| dcaliste | The idea is to discoupled complitely the Sqlite handler API from extendedstorage one. | 07:43 |
| dcaliste | I was a bit wondering about how to do it for the various load*() routines but I had finally the idea to create this Filter API. | 07:44 |
| dcaliste | I find it quite nice, concise and consistent. You'll give me your opinion on it. | 07:44 |
| pvuorela | sure | 07:44 |
| dcaliste | The status of the PR at the moment, leave all the new API used by SqliteStorage in the protected: part of ExtendedSTorage, but the final idea is to move it to a new dedicated StorageBackend interface. | 07:45 |
| dcaliste | As a longer plan, this would allow to use several time the same backend under the ExtendedStorage API. Like that application could use a dedicated DB and still being shown in the calendar, without having to ask for specific permissions. | 07:50 |
| dcaliste | Discoupling the storage backend API from ExtendedStorage would also allow to create an async API suited to delegate the DB operation into a thread and let the calendar being in the main thread. | 07:51 |
| pvuorela | you mean notebooks in different database files? | 07:53 |
| dcaliste | Not necessary, I mean different DBs for different usage. The system DB with the account notebooks and the private ones, being priviledged and subject to sailjail access, and other DBs in the application directory. | 07:55 |
| pvuorela | if app specific notebook is shown in the calendar app. how would it be found? | 07:57 |
| dcaliste | In the ExtendedStorage, after discoupling from SqliteStorage, it would be "natural" to add several backends, a load / store incidences based on the association QHash<notebookUid, Backend>, keeping the current situation where several notebooks can go in the same backend. | 07:57 |
| dcaliste | The finding part is where we need a bit of addition to the current situation. | 07:58 |
| dcaliste | There should be a new permission to add declare that an app require access to be displayed in the calendar. | 07:58 |
| dcaliste | This would be safer than allowing access to the system DB. | 07:59 |
| dcaliste | In nemo-qml-plugin-calendar, the worker would initiate an ExtendedStorage and then call something like : | 07:59 |
| dcaliste | addBackend(system), | 07:59 |
| dcaliste | addBackend("app1/Calendar/mkcal/db") | 08:00 |
| dcaliste | addBackend("app2/Calendar/mkcal/db")... | 08:00 |
| pvuorela | hm. the permissions need to be understandable. generic "allow calendar access" is easy to follow. ability to create notebooks could still be understandable too but just want to keep the permission set simple enough. | 08:01 |
| dcaliste | where app1, app2... are provided by the list of applications granted the "display in calendar" permission. | 08:01 |
| dcaliste | Yes, but granting the (system) calendar access mean also being able to delete everything. A "display in calendar" or "add new notebook" permission would be less permissive. | 08:02 |
| dcaliste | And a way to get it is to have multi backends under ExtendedStorage and let ExtendedCalendar to the agregation. I think it was the original design when I looked at the documentation. | 08:03 |
| pvuorela | safer, yes. for use cases if we want to enable creating a custom calendar app the generic access needs to be there. restrictive access could make sense for "apps" that implement some account synchronization maybe. | 08:04 |
| pvuorela | does it make sense to restrict the latter to minimum, not sure. | 08:05 |
| dcaliste | From an implementation point of view, after SqliteStorage has been completely discoupled from storage and calendar, it is not a lot of work internal to ExtendedStorage to become multi storage. | 08:05 |
| dcaliste | I think the idea of permissions is to make the thing safer for user data. Having a wide calendar permission with write access would simply delegate the responsability on the user but won't make his data safer. | 08:07 |
| dcaliste | Anyway, that is some possibilities one can take or not after SqliteStorage is discoupled from ExtendedStorage API. | 08:07 |
| dcaliste | The other, as I mentioned is to be able to implement an async API behind the hood, so ExtendedStorage can be kept as it is and usable in a main thread without lagging from DB access. | 08:08 |
| pvuorela | it's a balancing act. on one hand should protect different things but on the other the permission set needs to be small and generic enough to be understandable and not too long list of permission when asked on the ui. | 08:11 |
| dcaliste | Sure. I agree. | 08:15 |
| dcaliste | Just one question about the signature icon in mail list. I wonder if one needs to cache the EmailUtils property since it's declared as CONSTANT. | 08:16 |
| pvuorela | easily tested, but think the constant just avoids connecting to change signals on qml side. | 08:17 |
| dcaliste | I tried to add a debug message in the getter to test it, but the compiled jolla-email in SDK then segfault on device in a gecko part. | 08:17 |
| pvuorela | but doubt the qml engine or anything starts caching the value automatically. | 08:17 |
| dcaliste | Ok, it make sense not to listen to the change signal only, but still call the get method each time needed. | 08:18 |
| dcaliste | So I'll add a private member with the bool value. | 08:19 |
| dcaliste | Do you think it's worth the pain to add a listener on the directory in case the file is added while the email application is still running ? | 08:19 |
| dcaliste | I don't in my opinion, but I can do it if you think it's cleaner. | 08:20 |
| pvuorela | could be enough corner case not to care now. | 08:20 |
| dcaliste | Ok. So a simple private member will do the job then. | 08:20 |
| dcaliste | I've seen flypig starting to review the noptr PRs. Thank you. I'll rebase the other mKCal PRs when merged. Thank you pvuorela for the discussion and the reviews. | 08:26 |
| pvuorela | dcaliste: thank you too :) | 08:27 |
| *** Mikaela is now known as Guest151 | 13:35 | |
| piggz | flypig: ping | 21:18 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!