| *** zbenjamin is now known as Guest91928 | 01:05 | |
| *** zbenjamin_ is now known as zbenjamin | 01:05 | |
| *** frinring_ is now known as frinring | 02:44 | |
| dcaliste | Hello chriadam, how are you ? | 06:57 |
|---|---|---|
| chriadam | hi dcaliste, I'm well thanks. how are you? | 06:57 |
| dcaliste | I'm fine thank you. | 06:57 |
| chriadam | I don't have much to report since our last meeting - been busy with fixing bugs for the upcoming release | 06:59 |
| dcaliste | Sure, no problem. I've worked on a UI prototype to add web calendars. | 07:00 |
| chriadam | ah nice! | 07:00 |
| dcaliste | See my branch https://bitbucket.org/jolla/ui-jolla-calendar/branch/contributor-webcal | 07:00 |
| dcaliste | And https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/44 (but empty for the moment, I pushed the wrong branch this morning before leaving for work). | 07:02 |
| dcaliste | The main part is in the new WebCalendar.qml file in jolla-calendar. | 07:02 |
| dcaliste | From the notebook storage we have the syncProfile. With a DBus call, we ask for the XML describing the profile. | 07:03 |
| dcaliste | This XML contains the URL, the label, some options and the schedule. | 07:03 |
| dcaliste | The main bloat in WebCalendar.qml is then to convert this XML into AccountSyncOptions from sailfish-component-account, so it can be used in a SyncScheduleOptions QML object from setting-accounts. | 07:04 |
| dcaliste | There is some more bloat also to do the reverse job : export the UI content into XML, so the XML data can be sent back through DBus. | 07:05 |
| chriadam | ooi why is that needed? i thought these webcal subscriptions were "account-less" ? | 07:06 |
| dcaliste | Yes, I wanted to reuse the schedule UI parts (that are account less) but live in setting-account and component-account. | 07:07 |
| chriadam | ah UI bits, I see, of course | 07:07 |
| chriadam | right, then those are written to the sync profile | 07:07 |
| dcaliste | Exact. | 07:07 |
| dcaliste | It's not a problem, the main bloat is to come from XML and to export to XML. | 07:07 |
| dcaliste | It would make sense to put this into the AccountSyncOptions object (that is not depending on any account, whatever the name), but the code is closed and I'm not very eager to add it here :( | 07:08 |
| chriadam | indeed | 07:09 |
| dcaliste | (I know calendar code is closed also, …) | 07:09 |
| chriadam | I think it makes sense in the place you put it, as the other is more specifically for account stuff I guess, I think. | 07:09 |
| dcaliste | Yes, but it's not related to account in fact, it's related to Buteo profile. It is there because there is no component-buteo. | 07:10 |
| chriadam | ah, interesting. | 07:11 |
| dcaliste | It would make sense to write a component-buteo stuff (and I'm eager to do it), so we can access buteo log from profiel… But some parts already exists in the compoennt-account and are closed. | 07:11 |
| chriadam | the whole sailfish-components-accounts needs cleanup/rewrite IMO. but no resources for that currently unfortunately. | 07:11 |
| dcaliste | My point is not to touch the account part, but to isolate the buteo related ones. | 07:12 |
| dcaliste | Thje buteo only I mean. | 07:12 |
| chriadam | I definitely agree that exposing some buteo things (especially error codes, previous sync timestamps etc) to QML would be useful. And the sync profile stuff comes under that. | 07:13 |
| chriadam | it's not something that we have on our near-term roadmap, unfortunately | 07:14 |
| dcaliste | My problem is that some buteo parts are already written under a Account "namespace" and rewriting them in a new component-buteo would break the API and compatibility with let say the jolla-setting-account parts. | 07:15 |
| chriadam | well, could duplicate whatever is needed ot the new namespace | 07:15 |
| chriadam | then we can upgrade the jolla-settings-whatever things to the new api without strict deadline | 07:16 |
| dcaliste | As a medium term goal, do you think you would adopt a newly written component-buteo (handling profile stuff, exposing declarative Profile objects…) and accept if I provide adaptation of the above layers like setting-accounts ? | 07:16 |
| chriadam | I cannot speak for whether that work would fit into our medium term resource scheduling - jpetrell would be better to answer. I can say that I would see value in that (especially since it opens up opportunity to do things like show detailed sync log errors etc in the future), and wouldn't mind doing that porting work, but not sure whether it would be resourced by Jolla or not.. | 07:18 |
| dcaliste | Ok, if I find enough time, Jolla implication would be mainly related to reviewing (which is an important part of the work), I should provide the code for the component-buteo and the adaptation in required layers. | 07:21 |
| dcaliste | In fact, I already worked on this a long time ago : https://git.merproject.org/dcaliste/nemo-qml-plugin-buteo | 07:22 |
| dcaliste | I could start from that. | 07:23 |
| chriadam | definitely. review etc is fine, will definitely find time for that | 07:24 |
| chriadam | if the porting effort is only a day or so of work, I am fine committing to that also. if it's longer, we might need to plan it more carefully, e.g. align it with our customer priorities somehow | 07:24 |
| dcaliste | Sure. Thank you for the psoitive feedback. As I said it's more medium term project from my side. It requires some pile of work. In a shorter schedule, I'm letting the XML bloat stuff in the WebCalendar.qml file, it is working fine already. | 07:26 |
| chriadam | yep :-) | 07:26 |
| chriadam | thanks for your effort there, as always | 07:26 |
| chriadam | I also saw that the email folders PRs are progressing | 07:26 |
| dcaliste | Yes, it seems to me that it interstects with some internal target, so good ! | 07:27 |
| dcaliste | @pvuorela has done a great job sanitazing the synchronisation part. I still need to review it. | 07:28 |
| chriadam | great! | 07:28 |
| dcaliste | Another topic : I've seen in a MR that you would like to have a key-value map available for notebooks in mKCal. I share your view. I need to store an etag for web calendar, currently abusing the account field. | 07:28 |
| chriadam | generic metadata storage would be helpful for a variety of reasons | 07:29 |
| dcaliste | It makes sense to create a calendar-properties new table in storage I think and add the API for it. | 07:29 |
| chriadam | notebook-specific? or generic key/value? | 07:30 |
| dcaliste | I think, I'm going to work on that in the next weeks. | 07:30 |
| chriadam | just not sure what the api would look like | 07:30 |
| dcaliste | No, notebook specific only. | 07:30 |
| chriadam | ok | 07:30 |
| chriadam | sounds good, thanks | 07:30 |
| dcaliste | We already have the custom-properties for the events. | 07:30 |
| chriadam | except they don't outlive deletion ;-) | 07:31 |
| dcaliste | (except that they are deleted when the event is marked as deleted) | 07:31 |
| dcaliste | ;)) | 07:31 |
| chriadam | but yes that can be addressed separately I suppose :-) | 07:31 |
| dcaliste | This rework will come after, with the rework of purge vs. marked as deleted. | 07:31 |
| dcaliste | I really think the current delete should be separated into two: | 07:32 |
| dcaliste | - a marked as deleted using the current dateDeleted field. but without deleting anything. | 07:32 |
| dcaliste | - a purge action which remove every bit of the event and relation from the database. | 07:33 |
| chriadam | I agree | 07:33 |
| dcaliste | My problem is that, I'm not completely sure how to handle this in term of API with respect to kcalcore vs. mkcal, Calendar vs. extendedCalendar or calStorage vs. ExtendedStorage. | 07:33 |
| chriadam | ah, indeed | 07:33 |
| dcaliste | That's why, I will put this after the calendar-properties evolution, I still need to think about this. | 07:34 |
| chriadam | sounds like a good plan. | 07:35 |
| dcaliste | For this calendar specific API, I was going to add a QString mKCal::Notebook::customProperty(const QString &) API to get and ::setCustomProperty(const QString &, const QString &). | 07:37 |
| dcaliste | Than, add a new sql table (int id, string key, string value) | 07:38 |
| chriadam | looks sensible. foreign key constraint to ensure delete when the notebook is deleted, too, I guess | 07:38 |
| dcaliste | Exactly. | 07:39 |
| dcaliste | It's not a big addition, just some code to handle the sql addition if not exists. (and add an optional QString = QString() default if not found in the getter). | 07:40 |
| chriadam | would definitely be useful | 07:41 |
| dcaliste | We could transition in the caldav plugin to store the server URL instead of appending it to the syncProfile. | 07:41 |
| chriadam | definitely. a few things in the google calendar plugin could be fixed also | 07:42 |
| dcaliste | Ok, so I'll see if I can prepare this for next week or the week after if not enoygh time. | 07:43 |
| chriadam | no rush, but that would be great - thank you | 07:43 |
| chriadam | anything else to discuss for this week? | 07:46 |
| dcaliste | chriadam, ok, so let's see what we have next week. In between, have a nice week. | 07:46 |
| chriadam | sounds good! thanks again for your work and proactivity. I hope you have a nice week also! | 07:46 |
| dcaliste | Thanks, see you. | 07:48 |
| svip | Can anyone recommend a SailfishOS TOTP/HTOP app? | 09:36 |
| svip | I've found one called SailOTP, but is that any good? | 09:36 |
| tadzik | I use it all the time, it works | 09:37 |
| tadzik | only for totp though, not sure if it does hotp | 09:37 |
| svip | It's mostly TOTP I am interested in. | 09:38 |
| svip | Great! | 09:38 |
| svip | I'll try it. | 09:38 |
| Nico[m] | I'm using Foil Auth. It basically works the same as SailOTP and both worked well for me, but Foil encrypts your keys and prompts you for a password on first use, so it feels more secure | 09:42 |
| svip | Hm, OK. | 09:47 |
| tadzik | ah, nice | 10:48 |
| oozbooz | Good morning, Im traveling in EU in couple months and will stop in Barcelona. Is there a physical store to buy a pre-loaded ready-to-go sailfish phone there? | 13:32 |
| fledermaus | https://together.jolla.com/question/136143/wiki-available-devices-plus-rumored-and-legacy-devices-running-sailfish-os/ | 13:39 |
| fledermaus | my guess is not unless those few phones listed as preinstalled are available in that area | 13:40 |
| oozbooz | fledermaus, thanks... | 13:46 |
| *** SpeedEvil is now known as Guest63641 | 20:22 | |
| *** BitEvil is now known as SpeedEvil | 22:03 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!