Tuesday, 2021-08-17

riniguswe have icon-m-autocaps, icon-m-capslock available. but can't find a shift key icon that is shown on the keyboard before switching to caps mode05:12
rinigusany idea how that one is called?05:13
rinigustried to find at https://sailfishos.org/develop/docs/jolla-ambient/, but couldn't (maybe just missed it)05:13
dcalisteHello chriadam, how are you ?07:07
chriadamhi dcaliste, I'm well thanks.  How are you?07:08
dcalisteI'm ok, thanks.07:08
dcalisteI've seen pvuorela and yourself merged a lot of PRs last wwek. Thank you both.07:09
chriadamyes, we tried to get through quite a lot, pvuorela in particular managed to get a bunch through07:09
chriadamaccording to my list, the ones we have outstanding are:07:09
chriadam1) buteo sync log: https://github.com/sailfishos/buteo-syncfw/pull/1 + https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/207:09
chriadam2) organizer attendees: https://github.com/sailfishos/mkcal/pull/107:09
chriadam3) webcal name vs uid: https://github.com/sailfishos/buteo-sync-plugin-webcal/pull/107:09
chriadam4) jolla-calendar PRs07:10
chriadamis there anything I forgot?07:10
dcalisteNo, the list is complete.07:10
chriadamshall we start at (3) since that one is hopefully straightforward to discuss07:12
chriadambasically, while I agree that in the UI, the display name makes more sense than the UID, I think we were discussing with pvuorela the possibility that mkcal schema might change in future to allow a single event to belong in multiple notebooks07:12
chriadamnot sure what timeframe that might happen, but if we're keeping it in mind...07:13
dcalisteI agree with your concern. When I thought about the additions for per item logging, I was thinking to use the uid attribute of an item XML element to uniquely designed an item.07:14
dcalisteI don't want to scatter the information around two or more XML elements.07:14
dcalisteThe idea is to use this uid attribute with the same trick as in CalDAV if necessary doing NBUID::UID for instance.07:15
dcalisteThe plugin reading the log is responsible for the conversion of a log item uid into something relevant to be displayed.07:16
dcalisteLike that a target name in the log can stay as a human readable string.07:17
dcalisteIn addition it allows to display main log information without relying on plugins to actually decipher machine target names and user display names.07:18
chriadamok, so you're saying that the target name is not the thing which we should be using for the "qualified lookup" of the item, since that information (nbuid+uid) is stored in a different element?07:18
dcalisteYes, that's the general id : the per-item lookup should be possible, just with the item element information and not by gathering information from another parent element.07:19
dcalisteIn term of log, it makes the information quite redundant, but it's not a big issue size-wise and it makes the usage of the log information easier. Well, I think so !07:20
chriadamwait, so the per-item element information is unambiguous, but potentially the parent element could be ambiguous (e.g. if two notebooks had the same notebook name)?07:20
dcalisteYes, that's a drawback. But the user may already be at pain having two notebooks with the same name !07:21
dcalisteIn fact, I'm not opposed to the parent element being computer friendly by providing the real target UID. That would be great in fact.07:22
chriadamtrue, although at least in the calendar UI we disambiguate them with a colour bar also07:22
chriadamHmm, I guess more generically: whatever we decide to do here in webcal, we should do more generally07:24
dcalisteBut it means that displaying the log in an overview way (all profiles, all entries with just the added/modified/deleted figures) would require to actually relies on the plugins to get display names for targets.07:24
chriadamyeah, that does seem very suboptimal07:24
dcalisteOnly CalDAV and webcal are using this at the moment.07:24
dcalisteIn CalDAV, i've decided myself for the other option : target is the display name.07:25
chriadamwell, let's go with this way for now07:25
chriadamand we can revisit in future if required or whatever07:25
dcalisteThe real way forward, in case it is necessary would be to add another attribute in the target XML element to store the machine readable id.07:26
chriadamthat makes sense07:27
chriadamok, I'll merge that one tomorrow07:27
chriadamnext one to discuss is maybe (1) the sync log ones07:28
chriadampvuorela: did you have some outstanding concerns with those?07:28
chriadamoh, https://github.com/sailfishos/buteo-syncfw/pull/1 has conflicts now07:29
pvuorelachriadam: which ones?07:29
dcalisteYes, I didn't have time last week to update it after the DaySet stuff has been accepted.07:29
dcalisteNot a big deal, I'll take care of it today or tomorrow.07:29
chriadampvuorela: specifically https://github.com/sailfishos/buteo-syncfw/pull/1, and also https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/2 but I think that one was less contentious07:30
chriadamdcaliste: no rush, thanks07:31
pvuorelachriadam: i'll recheck if there was something07:32
chriadamok, next item (sorry for jumping around in the order) is (2): organizer attendees: https://github.com/sailfishos/mkcal/pull/107:33
chriadamwas any consensus reached about the way forward, or do we want to shelve that one for now, or?07:33
pvuorelabtw on that event-in-multiple-notebooks, it will also quite likely require api changes, not just schema in the background.07:33
chriadamyeah, I agree07:34
pvuorelaon attendees i had one new comment last week.07:34
chriadamah yes, reading that one now07:34
dcalistepvuorela, I didn't have time neither to reply yet to your comment, sorry.07:35
dcalisteMainly, I was maybe overspeaking when saying bloat code in the sync plugins.07:35
pvuorelaoh and that syncfw seems to require a rebase07:36
dcalisteLet say that we currently have additional code to serialise into iCal format.07:36
dcalisteIn my opinion, it's a pity, KCalendarCore::ICalFormat should be the only place to do it.07:36
chriadamhmm, maybe I am misunderstanding the comment, but my understanding is that we always treat the data the same way: 1) we assume that the organizer is an attendee, 2) we have to manually filter out the organizer from the attendee list, to avoid issues when upsyncing / converting to iCal format07:36
chriadamso the PR will not change (1) but it will mean we don't need to do (2)07:37
pvuoreladidn't go reading the RFCs but to me it feels like ical/calendarcore allows both kind of cases, and if so we'll need to cope with that on places that translate the event data to external sync services or the UI.07:38
dcalisteYes, the idea is to avoid 2) without breaking current behaviour on device.07:38
dcalistepvuorela, you're right Google format and iCal allow both.07:39
dcalisteBut at the moment, my understanding of the code is that 2) from chriadam is always taken.07:39
chriadamat least in our sync plugins, that is my understanding also07:39
chriadamon UI side, not 100% sure, I believe I checked this in the past, before we changed to github07:39
chriadambut cannot remember properly07:39
dcalisteMy proposition is thus to remove 2) from the sync plugins, so the sync plugins don't assume any position for the organizer, just pass the serialised data to the servers.07:40
chriadamyep.  by the way, when we _didn't_ filter out the organizer from the attendees list when upsyncing to Google, we had strange bugs (google treated it as an invitation rather than a "normal" event, even if the organizer was the ONLY attendee, etc)07:41
dcalistemKCal is deficient to allow the two possibilities for the organizer and it is choosing the convention with the less often used behaviour. The proposition is to switch this, like that the buggy code will only be in mKCal and sync plugins will just be transport layers.07:42
dcalisteAt the moment, they are filter and transport layers.07:43
dcalisteAnd the icalconverter tool in nemo-qml-plugin-calendar used for the backup is heving this filtering code also, to be consistent.07:43
chriadamslowly getting closer to transport only, thanks to your efforts ;-)07:44
dcalisteIt means that we currently have to deal with the "wrong" convention from mKCal in many places, which is not ideal.07:44
chriadamwell, pvuorela, maybe you would prefer to think about this one further still.  maybe we can come back to it again at next meeting.07:44
dcalisteYeh, and if you still prefer the current behaviour, I can live with these additional code here and there, no problem !07:45
pvuorelawell need to be careful on what is considered wrong or unnecesary. for example not sure if filtering out for UI is either.07:46
dcalisteThe UID is the last bit to become full transport, indeed.07:46
pvuorelasynchronization depends on the external service specification07:46
dcalisteI'm still thinking how to do this transparently with current mKCAl limitations, but with no avail at the moment.07:47
dcalisteThe ideal case would be server<->iCal<->KCalendarCore::IcalFormat::from String<->device<->IcalFormat::toString()<->server.07:48
chriadamshall we move onto (4) the jolla-calendar PRs?  pvuorela merged one of those, thanks for that.  PR#303 has some comments from Pekka, one about date comparison, the other about what date formatting the component provides07:49
dcalistefor the specific service specifications, I think we can use the incidence VOLATILE properties.07:49
dcalisteAbout bullet 4), thanks pvuorela for merging and commenting last week.07:50
dcalisteI think, you're right in your comments of #303. The EventTimeLabel.qml should not be exposed, only the EventListDelegate one.07:51
dcalisteI'll update the MR accordingly.07:51
chriadamthen I noticed that there's still PR#298 open, I think mschuele provided some sketches but not sure if you're still waiting on something from our side?07:51
dcalisteI got confused myself with the Javascript method to get dates, I indeed mean date comparisons and not day of year comparison.07:51
chriadamno rush on that 298 one obviously07:51
dcalisteI'll correct this javascript issues.07:52
dcalisteTo be clear on the changes proposed in EventTimeLabel :07:52
dcaliste- currently, it is assuming a common date for every events in the list, thus only displaying the time.07:52
dcaliste- I'm proposing to extend it a bit by allowing it to display event time and date if we're not in the common date case.07:53
dcalisteThis requires some additional ifs for cases when the starting date and the ending date differs or not.07:54
dcalisteTypically, if they are the same, we display the date and the time start - end times,07:54
dcalisteif they are different, we display the full date and time for start and the full date and time for the end.07:54
dcalisteI think, pvuorela, that you notice an issue in my use of date formatter in the latter case. I'll correct it, to display not only dates, but also times.07:55
chriadamMore generally, I read his comment as a question: is that "extended behaviour" (i.e. ability to show events in the not-common-date-case) something which can be done by something else, rather than this component07:58
pvuoreladcaliste: sure, though if the component is not shared but it's app-specific there might be point in just dates. or not, don't know.07:58
chriadam(Personally, I don't see any problem with having it in this component, but there is a "code locality" issue - e.g. some code change might unintentionally break it and the author might not know, given that the only user of that component is "outside" of the app etc)07:59
dcalisteI share you concern about the maintability of this change due to external usage only.08:00
dcalisteI think that sharing EventListDelegate is a good direction, because nemo-qml-plugin-calendar is providing list models to display events, and this is public.08:00
dcalisteWith the arrival of Sailjail, external application may access calendar data (or not).08:01
chriadam(regarding maintainability: maybe add a comment to each of the if/elseif/else branches to explain what it's returning and why, just to make it super obvious/clear)08:01
dcalisteAnd providing this EventListDelegate as a component instead of a calendar application element will go in the direction of plateform uniformity of design.08:01
chriadamI agree, it's a step in the right direction, for sure.  Let's not open it up to third parties / harbour too soon, of course, but moving in that direction is good I think08:02
chriadamwell, maybe we can discuss this further in the PR once you have updated it with those fixes08:03
dcalisteFor instance, having this "multi date" list delegate could be used in a possible search tool in the calendar ?08:03
dcalisteIt would be quite easy to add a method fetching incidence from DB in mKCal matching a substring in summary or location or description, returning a list model of UIDs, like I'm doing at the moment for the logs.08:04
dcalisteThen, the UI can display the matching list easily with the same components as proposed in this #303 MR.08:05
dcalisteIt's not in a hurry, so we can still think about it further. I'll correct the mistakes that pvuorela noticed and add the comments as you rightfully suggested.08:05
chriadamadded your comments above about the search option possibility to the MR, also.  something for jpetrell to think about08:06
chriadamI think that covers our agenda from my perspective, did I miss anything?08:06
chriadamflypig: did you wish to speak to dcaliste about anything, maybe related to the newsletter?  we have been merging a whole bunch of contributions from dcaliste this past week.08:07
dcalisteNo, I think, that's all. I thank Martin for the design mockups, I'll come back soon to the associated MR to update it accordingly.08:07
flypigConcerning discussing contributions, I would love to, but I'm currently in another meeting. dcaliste is there any other convenient time we could do this?08:08
dcalisteFlypig, it's summer vacations here, so I don't have so may working meetings myself at the moment. Tell me when you would prefer this week, avoiding Thursday.08:10
flypigIn an hour, or tomorrow at the same time as your meeting today? Otherwise we could do it during your usual meeting next week?08:11
dcalisteTomorrow at 7.00 UTC is fine for me, same place ;)08:12
chriadam7 utc tomorrow is community meeting in #sailfishos-meeting08:12
flypigAh, that's a good point.08:12
chriadamjust reminding08:12
dcalisteOn a Wednesday ?08:13
chriadamoh wait08:13
chriadamsilly me08:13
chriadamit's thursday08:13
flypigOkay :) So, tomorrow 7UTC is good for me. See you then!08:13
chriadam(sorry for confusion)08:13
dcalisteOk, settled flypig, see you tomorrow.08:13
flypigNo worries chriadam. Always good to check these things.08:14
chriadamok, thanks everyone!  thanks dcaliste as always for your great efforts.  much appreciated.08:14
* chriadam -> away, good night08:14
dcalisteGood night chriadam.08:14
dcalisteThank you pvuorela too, have a nice day.08:14
riniguslbt: in context of https://github.com/sailfishos-chum/main/issues/21, would it be possible to get https for repo.merproject.org?19:07
riniguscc piggz19:07

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