Tuesday, 2021-04-20

*** nyov is now known as Guest3881003:15
chriadamhi dcaliste, I hope you had a nice week07:01
dcalisteHello chriadam, it was allright. thanks.07:02
chriadamthat's good.  thanks very much for writing up the information about QMF and your contributions there!07:02
dcalisteWell, thanks for your hard work on the transition also, as for flypig. It would have been incomplete without your help.07:03
flypigThanks dcaliste also from me for the write-up; really great stuff. I'm looking forward to it going out.07:04
chriadam:-)  it's been enjoyable working with you, as always.  I really appreciate it.07:04
chriadamfor today's meeting, I'm not sure that there is much to discuss from my side07:05
chriadamI merged your caldav PR as bree tested it and found no regressions.  I added a bug number to the PR message (but not the commit message).07:05
chriadamQMF side I haven't had a chance to progress the outstanding PR, or merge the other one which needed review07:06
chriadamI poked MartinS again about taking a look at your timezone shift PR in jolla-calendar, but I guess he hasn't had a chance to look at that one yet still07:07
chriadamdid you have any topics for today?  or flypig?07:07
flypigNot from me.07:07
dcalisteI've seen you accepted the caldav MR, thank you.07:11
dcalisteI've worked a bit last week on the lipstick issue I faced, but in fact it has been fixed already by Andrew, but was not backported to
dcalisteI didn't have a moment to start backporting QMF back to Sailfish neither.07:13
dcalisteAnd finally, I polished my version 2 of Buteo QML bindings. It's more consise than version 1, but there are still one or two things to polish.07:13
dcalisteAnd related to this, I've started to add error handling in buteo-sync-plugins-email and also mail counting for extended log like for CalDAV.07:14
dcalisteSo various work in progress, and nothing much to ask for review at the moment.07:15
chriadamyou've been busy!07:15
chriadamfor the buteo QML bindings, I wonder how you see those being used (at least as a first step)07:16
chriadamis it: within the application itself (e.g. calendar, email), or is it: in some sync log page in settings?07:16
dcalisteI am more inclined to choose the page in setting solution. Like we have a transfer list page, we may have a sync status page. One entry per sync done on device, time ordered. Then, you can tap on the entry and see what was changed with links to actual item in the application, like you notice that there was a new event synced from server, you tap on it and it opens the event view in the calendar app.07:18
dcalisteIn case of sync error, you may have an extract from the error log if available, or at least a list of failing events.07:19
dcalisteI'm working to add this kind of feedback for mails also, to see if it's generic enough, and not too event-centred.07:20
chriadamI tend to agree, however the problem with such pages in settings is that they're not too discoverable for most users.  so in some cases, some (transient) homescreen notification might be needed also (for some repeating errors, perhaps)07:20
chriadamyes, the cross-domain applicability is a really interesting point -- especially from the UI perspective.  e.g. list of emails and folders, vs list of events and calendars, etc07:21
dcalisteAt the moment, the log entry list is generic, based only onQList<Buteo::SyncResults>, but each subpage, for each entry, will be profile-client dependant. A bit like in the document app, the list is generic, and depending on the file type, it opens a PDF viewer or a ODT one.07:22
chriadaminteresting.  I wonder if it should be a cross-app flow in that case (e.g. open the email app to the "sync errors" page or something?)07:24
dcalisteWhy not. But I don't know how to add a page in-app whithout cluttering it. Adding one entry in the main page pull-down is not an option ;)07:25
chriadamI wonder if there's some discussion we can have on our side at this early stage (e.g. with jpetrell and mschuele) about this.07:25
chriadambut perhaps we can wait until you have progressed a bit further, so that the discussion is a bit more concrete, also07:26
dcalisteAt the moment, I'm working on QML component to display the Buteo::SyncResults, and components for a CalDAV sync entry. Then, we can think of the better way to put them somewhere.07:26
chriadamsounds good :-)07:26
dcalisteBut that's a good idea to have a discussion with jpetrell and mschuele at that stage already.07:27
dcalisteIndeed, most C++ parts are done. I've ListModel to display SyncResults logs and QML bindings to profile and SyncResults.07:27
dcalisteI've also some QML demo app to see everything is interacting well.07:28
dcalisteBut the UI display is quite ugly and confused at the moment.07:28
dcalisteIt is only listing the SyncResults in a generic way and I'm going to strat to implement the CalDAV dedicated page.07:29
chriadamtype-specific views are usually necessary, I agree07:30
dcalisteSo there are different things to demo and try to see how to assemble them.07:30
chriadamwell, it sounds like it's getting really close to something which our design people can play with, that's great.07:31
chriadamthank you very much07:31
dcalisteFor the type specific view, indeed, if you remember, the per-item logging is just storing a UID. Then, it's the job of the type-specific page to know that this is a caldav-sync client log, and the UID should be interpreted that way.07:31
chriadamyeah.  another reason why I think it might be nice to implement it via a cross app flow, then the settings app won't have to link against calendar libraries etc potentially07:32
chriadambut, can discuss that later.  might not be a concern anyway07:32
dcalisteAh, yes indeed.07:33
dcalisteThere is one design hickup that is bothering me (just to mention) :07:33
dcalistethe log of each profile are limited to N (N = 5 at the moment, but that's not the point) last entries. Which is fine.07:33
dcalisteBut when listing logs of various accounts in the same list time ordered, and when the sync schedule are different (emails sync every 30 minutes, while caldav sync twice a day), the list is usually populated with the last five email sync, then comes the five CalDAV ones. And it's hard to understand why there is nomore email sync entries earlier in time.07:35
chriadamwhat's the solution?  if successes are "small" to store, maybe we can store ... a hundred of them.  and just store the most recent 5 failing syncs, since those are likely to be large (containing failure info about individual sync items)?07:37
dcalisteI don't have any solution at the moment ! The nicest one I've found is to filter the list to a specific account, which defies the centralised listing concept itself. Storing more entries could be a bit dangerous, because even successful sync may becomes large with the per item logging.07:39
chriadamah right07:40
chriadammaybe we could store just timestamps and overall success/failure of previous 100 syncs, so at least we can show them in a timeline view, even if we throw away the detailed info?07:41
chriadamwell, anyway, I guess more thought is required07:41
chriadamno doubt there will be other things needed to consider also ;-)07:41
chriadamanyway, let's take this up again at a future meeting once there's something which jpetrell can potentially demo on a device and think about with martin07:44
chriadamthanks again.  did you have anything else to discuss today?07:44
dcalisteYeh, it was mainly to mention the issue and keep it in a corner of our heads.07:44
dcalisteNothing additional I think, let see where it will be next week.07:45
chriadamsounds great :-)07:45
chriadamin that case, have a good week!07:45
* chriadam -> away, gnight07:46
Nico[m]Sometimes Qt5.6 is super annoying. Stupid moc does not understand nested namespace declarations, you need to split them up....07:51

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