| rinigus | we 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 mode | 05:12 |
|---|---|---|
| rinigus | any idea how that one is called? | 05:13 |
| rinigus | tried to find at https://sailfishos.org/develop/docs/jolla-ambient/, but couldn't (maybe just missed it) | 05:13 |
| dcaliste | Hello chriadam, how are you ? | 07:07 |
| chriadam | hi dcaliste, I'm well thanks. How are you? | 07:08 |
| dcaliste | I'm ok, thanks. | 07:08 |
| dcaliste | I've seen pvuorela and yourself merged a lot of PRs last wwek. Thank you both. | 07:09 |
| chriadam | yes, we tried to get through quite a lot, pvuorela in particular managed to get a bunch through | 07:09 |
| chriadam | according to my list, the ones we have outstanding are: | 07:09 |
| chriadam | 1) buteo sync log: https://github.com/sailfishos/buteo-syncfw/pull/1 + https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/2 | 07:09 |
| chriadam | 2) organizer attendees: https://github.com/sailfishos/mkcal/pull/1 | 07:09 |
| chriadam | 3) webcal name vs uid: https://github.com/sailfishos/buteo-sync-plugin-webcal/pull/1 | 07:09 |
| chriadam | 4) jolla-calendar PRs | 07:10 |
| chriadam | is there anything I forgot? | 07:10 |
| dcaliste | No, the list is complete. | 07:10 |
| chriadam | shall we start at (3) since that one is hopefully straightforward to discuss | 07:12 |
| chriadam | basically, 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 notebooks | 07:12 |
| chriadam | not sure what timeframe that might happen, but if we're keeping it in mind... | 07:13 |
| dcaliste | I 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 |
| dcaliste | I don't want to scatter the information around two or more XML elements. | 07:14 |
| dcaliste | The idea is to use this uid attribute with the same trick as in CalDAV if necessary doing NBUID::UID for instance. | 07:15 |
| dcaliste | The plugin reading the log is responsible for the conversion of a log item uid into something relevant to be displayed. | 07:16 |
| chriadam | right | 07:17 |
| dcaliste | Like that a target name in the log can stay as a human readable string. | 07:17 |
| dcaliste | In addition it allows to display main log information without relying on plugins to actually decipher machine target names and user display names. | 07:18 |
| chriadam | ok, 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 |
| dcaliste | Yes, 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 |
| dcaliste | s/id/idea/ | 07:19 |
| dcaliste | In 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 |
| chriadam | wait, 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 |
| dcaliste | Yes, that's a drawback. But the user may already be at pain having two notebooks with the same name ! | 07:21 |
| dcaliste | In 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 |
| chriadam | true, although at least in the calendar UI we disambiguate them with a colour bar also | 07:22 |
| chriadam | Hmm, I guess more generically: whatever we decide to do here in webcal, we should do more generally | 07:24 |
| dcaliste | But 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 |
| chriadam | yeah, that does seem very suboptimal | 07:24 |
| dcaliste | Only CalDAV and webcal are using this at the moment. | 07:24 |
| dcaliste | In CalDAV, i've decided myself for the other option : target is the display name. | 07:25 |
| chriadam | ok | 07:25 |
| chriadam | well, let's go with this way for now | 07:25 |
| chriadam | and we can revisit in future if required or whatever | 07:25 |
| dcaliste | The 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 |
| chriadam | right | 07:27 |
| chriadam | that makes sense | 07:27 |
| chriadam | ok, I'll merge that one tomorrow | 07:27 |
| chriadam | next one to discuss is maybe (1) the sync log ones | 07:28 |
| chriadam | pvuorela: did you have some outstanding concerns with those? | 07:28 |
| chriadam | oh, https://github.com/sailfishos/buteo-syncfw/pull/1 has conflicts now | 07:29 |
| pvuorela | chriadam: which ones? | 07:29 |
| dcaliste | Yes, I didn't have time last week to update it after the DaySet stuff has been accepted. | 07:29 |
| dcaliste | Not a big deal, I'll take care of it today or tomorrow. | 07:29 |
| chriadam | pvuorela: 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 contentious | 07:30 |
| chriadam | dcaliste: no rush, thanks | 07:31 |
| pvuorela | chriadam: i'll recheck if there was something | 07:32 |
| chriadam | thanks | 07:32 |
| chriadam | ok, next item (sorry for jumping around in the order) is (2): organizer attendees: https://github.com/sailfishos/mkcal/pull/1 | 07:33 |
| chriadam | was any consensus reached about the way forward, or do we want to shelve that one for now, or? | 07:33 |
| pvuorela | btw on that event-in-multiple-notebooks, it will also quite likely require api changes, not just schema in the background. | 07:33 |
| chriadam | yeah, I agree | 07:34 |
| pvuorela | on attendees i had one new comment last week. | 07:34 |
| chriadam | ah yes, reading that one now | 07:34 |
| dcaliste | pvuorela, I didn't have time neither to reply yet to your comment, sorry. | 07:35 |
| dcaliste | Mainly, I was maybe overspeaking when saying bloat code in the sync plugins. | 07:35 |
| pvuorela | oh and that syncfw seems to require a rebase | 07:36 |
| dcaliste | Let say that we currently have additional code to serialise into iCal format. | 07:36 |
| dcaliste | In my opinion, it's a pity, KCalendarCore::ICalFormat should be the only place to do it. | 07:36 |
| chriadam | hmm, 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 format | 07:36 |
| chriadam | so the PR will not change (1) but it will mean we don't need to do (2) | 07:37 |
| pvuorela | didn'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 |
| dcaliste | Yes, the idea is to avoid 2) without breaking current behaviour on device. | 07:38 |
| dcaliste | pvuorela, you're right Google format and iCal allow both. | 07:39 |
| dcaliste | But at the moment, my understanding of the code is that 2) from chriadam is always taken. | 07:39 |
| chriadam | at least in our sync plugins, that is my understanding also | 07:39 |
| chriadam | on UI side, not 100% sure, I believe I checked this in the past, before we changed to github | 07:39 |
| chriadam | but cannot remember properly | 07:39 |
| dcaliste | My 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 |
| chriadam | yep. 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 |
| dcaliste | mKCal 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 |
| dcaliste | At the moment, they are filter and transport layers. | 07:43 |
| dcaliste | And the icalconverter tool in nemo-qml-plugin-calendar used for the backup is heving this filtering code also, to be consistent. | 07:43 |
| chriadam | slowly getting closer to transport only, thanks to your efforts ;-) | 07:44 |
| dcaliste | It means that we currently have to deal with the "wrong" convention from mKCal in many places, which is not ideal. | 07:44 |
| chriadam | well, 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 |
| dcaliste | Yeh, and if you still prefer the current behaviour, I can live with these additional code here and there, no problem ! | 07:45 |
| pvuorela | well need to be careful on what is considered wrong or unnecesary. for example not sure if filtering out for UI is either. | 07:46 |
| dcaliste | The UID is the last bit to become full transport, indeed. | 07:46 |
| pvuorela | synchronization depends on the external service specification | 07:46 |
| dcaliste | I'm still thinking how to do this transparently with current mKCAl limitations, but with no avail at the moment. | 07:47 |
| dcaliste | The ideal case would be server<->iCal<->KCalendarCore::IcalFormat::from String<->device<->IcalFormat::toString()<->server. | 07:48 |
| chriadam | shall 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 provides | 07:49 |
| dcaliste | for the specific service specifications, I think we can use the incidence VOLATILE properties. | 07:49 |
| dcaliste | About bullet 4), thanks pvuorela for merging and commenting last week. | 07:50 |
| dcaliste | I think, you're right in your comments of #303. The EventTimeLabel.qml should not be exposed, only the EventListDelegate one. | 07:51 |
| dcaliste | I'll update the MR accordingly. | 07:51 |
| chriadam | then 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 |
| dcaliste | I got confused myself with the Javascript method to get dates, I indeed mean date comparisons and not day of year comparison. | 07:51 |
| chriadam | no rush on that 298 one obviously | 07:51 |
| dcaliste | I'll correct this javascript issues. | 07:52 |
| dcaliste | To 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 |
| dcaliste | This requires some additional ifs for cases when the starting date and the ending date differs or not. | 07:54 |
| dcaliste | Typically, if they are the same, we display the date and the time start - end times, | 07:54 |
| dcaliste | if they are different, we display the full date and time for start and the full date and time for the end. | 07:54 |
| dcaliste | I 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 |
| chriadam | More 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 component | 07:58 |
| pvuorela | dcaliste: 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 |
| dcaliste | I share you concern about the maintability of this change due to external usage only. | 08:00 |
| dcaliste | I 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 |
| dcaliste | With 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 |
| dcaliste | And providing this EventListDelegate as a component instead of a calendar application element will go in the direction of plateform uniformity of design. | 08:01 |
| chriadam | I 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 think | 08:02 |
| chriadam | well, maybe we can discuss this further in the PR once you have updated it with those fixes | 08:03 |
| dcaliste | For instance, having this "multi date" list delegate could be used in a possible search tool in the calendar ? | 08:03 |
| dcaliste | It 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 |
| dcaliste | Then, the UI can display the matching list easily with the same components as proposed in this #303 MR. | 08:05 |
| dcaliste | It'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 |
| chriadam | added your comments above about the search option possibility to the MR, also. something for jpetrell to think about | 08:06 |
| chriadam | I think that covers our agenda from my perspective, did I miss anything? | 08:06 |
| chriadam | flypig: 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 |
| dcaliste | No, 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 |
| flypig | Concerning 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 |
| dcaliste | Flypig, 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 |
| dcaliste | s/may/many/ | 08:10 |
| flypig | In 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 |
| dcaliste | Tomorrow at 7.00 UTC is fine for me, same place ;) | 08:12 |
| chriadam | 7 utc tomorrow is community meeting in #sailfishos-meeting | 08:12 |
| flypig | Ah, that's a good point. | 08:12 |
| chriadam | just reminding | 08:12 |
| dcaliste | On a Wednesday ? | 08:13 |
| chriadam | oh wait | 08:13 |
| chriadam | silly me | 08:13 |
| chriadam | it's thursday | 08:13 |
| flypig | Okay :) So, tomorrow 7UTC is good for me. See you then! | 08:13 |
| chriadam | (sorry for confusion) | 08:13 |
| dcaliste | Ok, settled flypig, see you tomorrow. | 08:13 |
| flypig | No worries chriadam. Always good to check these things. | 08:14 |
| chriadam | ok, thanks everyone! thanks dcaliste as always for your great efforts. much appreciated. | 08:14 |
| * chriadam -> away, good night | 08:14 | |
| dcaliste | Good night chriadam. | 08:14 |
| dcaliste | Thank you pvuorela too, have a nice day. | 08:14 |
| rinigus | lbt: in context of https://github.com/sailfishos-chum/main/issues/21, would it be possible to get https for repo.merproject.org? | 19:07 |
| rinigus | cc piggz | 19:07 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!