| *** nyov is now known as Guest38810 | 03:15 | |
| chriadam | hi dcaliste, I hope you had a nice week | 07:01 |
|---|---|---|
| dcaliste | Hello chriadam, it was allright. thanks. | 07:02 |
| chriadam | that's good. thanks very much for writing up the information about QMF and your contributions there! | 07:02 |
| dcaliste | Well, thanks for your hard work on the transition also, as for flypig. It would have been incomplete without your help. | 07:03 |
| flypig | Thanks 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 |
| chriadam | for today's meeting, I'm not sure that there is much to discuss from my side | 07:05 |
| chriadam | I 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 |
| chriadam | QMF side I haven't had a chance to progress the outstanding PR, or merge the other one which needed review | 07:06 |
| chriadam | I 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 still | 07:07 |
| chriadam | did you have any topics for today? or flypig? | 07:07 |
| flypig | Not from me. | 07:07 |
| dcaliste | I've seen you accepted the caldav MR, thank you. | 07:11 |
| dcaliste | I'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 4.1.0. | 07:12 |
| dcaliste | I didn't have a moment to start backporting QMF back to Sailfish neither. | 07:13 |
| dcaliste | And 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 |
| dcaliste | And 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 |
| dcaliste | So various work in progress, and nothing much to ask for review at the moment. | 07:15 |
| chriadam | you've been busy! | 07:15 |
| chriadam | for the buteo QML bindings, I wonder how you see those being used (at least as a first step) | 07:16 |
| chriadam | is it: within the application itself (e.g. calendar, email), or is it: in some sync log page in settings? | 07:16 |
| dcaliste | I 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 |
| dcaliste | In 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 |
| dcaliste | I'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 |
| chriadam | I 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 |
| chriadam | yes, 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, etc | 07:21 |
| dcaliste | At 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 |
| chriadam | interesting. 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 |
| dcaliste | Why 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 |
| chriadam | true | 07:25 |
| chriadam | I 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 |
| chriadam | but perhaps we can wait until you have progressed a bit further, so that the discussion is a bit more concrete, also | 07:26 |
| dcaliste | At 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 |
| chriadam | sounds good :-) | 07:26 |
| dcaliste | But that's a good idea to have a discussion with jpetrell and mschuele at that stage already. | 07:27 |
| dcaliste | Indeed, most C++ parts are done. I've ListModel to display SyncResults logs and QML bindings to profile and SyncResults. | 07:27 |
| dcaliste | I've also some QML demo app to see everything is interacting well. | 07:28 |
| chriadam | excellent | 07:28 |
| dcaliste | But the UI display is quite ugly and confused at the moment. | 07:28 |
| dcaliste | It is only listing the SyncResults in a generic way and I'm going to strat to implement the CalDAV dedicated page. | 07:29 |
| chriadam | type-specific views are usually necessary, I agree | 07:30 |
| dcaliste | So there are different things to demo and try to see how to assemble them. | 07:30 |
| chriadam | well, it sounds like it's getting really close to something which our design people can play with, that's great. | 07:31 |
| chriadam | thank you very much | 07:31 |
| dcaliste | For 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 |
| chriadam | yeah. 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 potentially | 07:32 |
| chriadam | but, can discuss that later. might not be a concern anyway | 07:32 |
| dcaliste | Ah, yes indeed. | 07:33 |
| dcaliste | There is one design hickup that is bothering me (just to mention) : | 07:33 |
| dcaliste | the 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 |
| dcaliste | But 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 |
| chriadam | what'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 |
| dcaliste | I 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 |
| chriadam | ah right | 07:40 |
| chriadam | maybe 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 |
| chriadam | well, anyway, I guess more thought is required | 07:41 |
| chriadam | no doubt there will be other things needed to consider also ;-) | 07:41 |
| chriadam | anyway, 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 martin | 07:44 |
| chriadam | thanks again. did you have anything else to discuss today? | 07:44 |
| dcaliste | Yeh, it was mainly to mention the issue and keep it in a corner of our heads. | 07:44 |
| dcaliste | Nothing additional I think, let see where it will be next week. | 07:45 |
| chriadam | sounds great :-) | 07:45 |
| chriadam | in that case, have a good week! | 07:45 |
| * chriadam -> away, gnight | 07: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/!