Tuesday, 2019-10-01

*** zbenjamin is now known as Guest9192801:05
*** zbenjamin_ is now known as zbenjamin01:05
*** frinring_ is now known as frinring02:44
dcalisteHello chriadam, how are you ?06:57
chriadamhi dcaliste, I'm well thanks.  how are you?06:57
dcalisteI'm fine thank you.06:57
chriadamI don't have much to report since our last meeting - been busy with fixing bugs for the upcoming release06:59
dcalisteSure, no problem. I've worked on a UI prototype to add web calendars.07:00
chriadamah nice!07:00
dcalisteSee my branch https://bitbucket.org/jolla/ui-jolla-calendar/branch/contributor-webcal07:00
dcalisteAnd 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
dcalisteThe main part is in the new WebCalendar.qml file in jolla-calendar.07:02
dcalisteFrom the notebook storage we have the syncProfile. With a DBus call, we ask for the XML describing the profile.07:03
dcalisteThis XML contains the URL, the label, some options and the schedule.07:03
dcalisteThe 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
dcalisteThere 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
chriadamooi why is that needed?  i thought these webcal subscriptions were "account-less" ?07:06
dcalisteYes, I wanted to reuse the schedule UI parts (that are account less) but live in setting-account and component-account.07:07
chriadamah UI bits, I see, of course07:07
chriadamright, then those are written to the sync profile07:07
dcalisteIt's not a problem, the main bloat is to come from XML and to export to XML.07:07
dcalisteIt 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
dcaliste(I know calendar code is closed also, …)07:09
chriadamI 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
dcalisteYes, 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
chriadamah, interesting.07:11
dcalisteIt 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
chriadamthe whole sailfish-components-accounts needs cleanup/rewrite IMO. but no resources for that currently unfortunately.07:11
dcalisteMy point is not to touch the account part, but to isolate the buteo related ones.07:12
dcalisteThje buteo only I mean.07:12
chriadamI 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
chriadamit's not something that we have on our near-term roadmap, unfortunately07:14
dcalisteMy 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
chriadamwell, could duplicate whatever is needed ot the new namespace07:15
chriadamthen we can upgrade the jolla-settings-whatever things to the new api without strict deadline07:16
dcalisteAs 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
chriadamI 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
dcalisteOk, 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
dcalisteIn fact, I already worked on this a long time ago : https://git.merproject.org/dcaliste/nemo-qml-plugin-buteo07:22
dcalisteI could start from that.07:23
chriadamdefinitely.  review etc is fine, will definitely find time for that07:24
chriadamif 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 somehow07:24
dcalisteSure. 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
chriadamyep :-)07:26
chriadamthanks for your effort there, as always07:26
chriadamI also saw that the email folders PRs are progressing07:26
dcalisteYes, 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
dcalisteAnother 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
chriadamgeneric metadata storage would be helpful for a variety of reasons07:29
dcalisteIt makes sense to create a calendar-properties new table in storage I think and add the API for it.07:29
chriadamnotebook-specific?  or generic key/value?07:30
dcalisteI think, I'm going to work on that in the next weeks.07:30
chriadamjust not sure what the api would look like07:30
dcalisteNo, notebook specific only.07:30
chriadamsounds good, thanks07:30
dcalisteWe already have the custom-properties for the events.07:30
chriadamexcept they don't outlive deletion ;-)07:31
dcaliste(except that they are deleted when the event is marked as deleted)07:31
chriadambut yes that can be addressed separately I suppose :-)07:31
dcalisteThis rework will come after, with the rework of purge vs. marked as deleted.07:31
dcalisteI 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
chriadamI agree07:33
dcalisteMy 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
chriadamah, indeed07:33
dcalisteThat's why, I will put this after the calendar-properties evolution, I still need to think about this.07:34
chriadamsounds like a good plan.07:35
dcalisteFor 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
dcalisteThan, add a new sql table (int id, string key, string value)07:38
chriadamlooks sensible.  foreign key constraint to ensure delete when the notebook is deleted, too, I guess07:38
dcalisteIt'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
chriadamwould definitely be useful07:41
dcalisteWe could transition in the caldav plugin to store the server URL instead of appending it to the syncProfile.07:41
chriadamdefinitely.  a few things in the google calendar plugin could be fixed also07:42
dcalisteOk, so I'll see if I can prepare this for next week or the week after if not enoygh time.07:43
chriadamno rush, but that would be great - thank you07:43
chriadamanything else to discuss for this week?07:46
dcalistechriadam, ok, so let's see what we have next week. In between, have a nice week.07:46
chriadamsounds good!  thanks again for your work and proactivity.  I hope you have a nice week also!07:46
dcalisteThanks, see you.07:48
svipCan anyone recommend a SailfishOS TOTP/HTOP app?09:36
svipI've found one called SailOTP, but is that any good?09:36
tadzikI use it all the time, it works09:37
tadzikonly for totp though, not sure if it does hotp09:37
svipIt's mostly TOTP I am interested in.09:38
svipI'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 secure09:42
svipHm, OK.09:47
tadzikah, nice10:48
oozboozGood 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
fledermausmy guess is not unless those few phones listed as preinstalled are available in that area13:40
oozboozfledermaus, thanks...13:46
*** SpeedEvil is now known as Guest6364120:22
*** BitEvil is now known as SpeedEvil22:03

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!