Tuesday, 2021-05-18

*** jrt is now known as Guest2663702:14
*** frinring_ is now known as frinring04:29
ViGerubdos[ma]: Sorry, my backlog doesn't go that far, so you have to give me more hints. What are you talking about? :-/04:45
rubdos[ma]<ViGe "Ruben De Smet: Sorry, my backlog"> About the web port of the application sdk, which defaults to 8080. I changed it to 18080 in qtcreator, but sfdk still fails with a 'port already in use'06:34
ViGeIt does change the port even on docker engine, at least for me it does06:58
chriadamhi dcaliste, I hope that your week has been good07:00
dcalisteHello chriadam, thanks it was fine. I wish the same for you.07:00
chriadamyeah, I had a fine week too, thanks07:01
dcalisteI've seen yesterday evening that Martin gave a detailed feedback on the time shift MR. Thank him much for me.07:01
chriadamoh, nice, I didn't see it yet07:02
chriadamyes, I will07:02
dcalisteI'll work on his suggestions later this week or the week after.07:02
chriadamI am currently taking a quick look at mkcal#63 - interesting case07:03
chriadamI think in general, the organizer of an event does NOT have to be an attendee, but they MAY be07:03
ViGerubdos[ma]: I think I found a bug. If I change the port in Qt Creator, and close the Qt Creator immediately, the port does not change. But pressing the "Start Virtual Machine" button in the Build Engine Settings dialog after changing the port caused the change to actually happen.07:04
chriadamI wonder if the "organizer is explicitly also an attendee" case is handled "transparently" with that change (i.e. it's just "another attendee") or whether it introduces some change (due to email match etc?)07:04
chriadamcertainly, I agree that the current mkcal code is wrong ;-)07:04
rubdos[ma]<ViGe "Ruben De Smet: I think I found a"> Aha, that sounds like a thing I should try07:04
ViGerubdos[ma]: Please do07:04
chriadamI just wonder whether this change might introduce some subtle regression for some cases involving invitations etc07:04
chriadamI will add a comment to the PR anyway in case Pekka has some thoughts also07:06
rubdos[ma]Ha, it jumped back to 8080 ViGe :P07:06
dcalisteIndeed, that's my concern. When I look at all the places I know it is used, _everytime_ the organizer is removed from the attendee list.07:06
rubdos[ma]But it actually listens on 18080 when I check netstat, ViGe, so "all good" now07:06
dcalisteWithout thinking if this is right or wrong, this push me to remove adding it initially in mKCal.07:07
dcalisteBut there are surely places that I don't know about or that I missed somehow. Thus the difficulty to say if the MR is valid or not.07:07
ViGerubdos[ma]: I'm filing an internal bug report about this07:09
rubdos[ma]Thanks, and thanks! :-)07:09
chriadamdcaliste: well, my thinking is: we should fix the incorrect/broken mkcal code.  and then if that introduces a regression we should later fix that regression ;)  of course, we should try to avoid regressions by carefully checking whether possible etc.07:10
chriadamI guess the "likely" regression would be: if we currently DON'T explicitly set the organizer to be an attendee, when creating an invitation event (because we're relying on mkcal adding the organizer automatically)07:11
dcalisteAt the moment the MR is simple by just not adding the organizer in the attendee list and taking care of existing data in already running databases.07:11
dcalisteIndeed, good point about event creation... But syncing code will remove it, at least for Google sync and CalDAV one.07:12
dcalisteSo if there's a regression it's in the UI code.07:12
dcalisteBut this will not happen since the organizer is always readded in nemo-qml-plugin-calendar when listing attendees.07:13
chriadamhmm, do we remove from e.g. Google sync because Google server-side already assumes that the organizer is an attendee?  or for some other reason?07:13
dcalisteI'm sorry my limited knowledge in that field stops here. I've no idea why we remove the organizer from the attendee list when syncing.07:15
dcalisteThat's why I tried to create a MR with mechanical changes, trying to simplify the current code without touching the behaviour, assuming the current behaviour is the right one ;)07:16
chriadamthere are very helpfully zero comments around that line of code haha07:16
chriadamI will check git commit history07:16
dcalisteGood idea, let's have a look in CalDAV also in case there is a bug id...07:16
chriadam98196a9e [sociald] Organizer of the event shouldn't be in the attendees list. Fixes JB#4302907:19
*** vilpan is now known as Guest1976207:19
*** Guest19762 is now known as vilpan07:19
chriadamBug 43029 - [BUG] Own events in Google calendar turn into invitations07:20
chriadamrelated to https://together.jolla.com/question/189920/google-calendar-sync-auto-invites-me/07:20
chriadamadded comment to mkcal MR for us to consider/discuss07:22
dcalisteIndeed, thanks. In CalDAV it's a commit from blam : 9554557f5e8b34f69190c0304085888e072c62c707:24
dcalisteSame commit message : we don't want this behaviour as it turns the event into an invitation for the organizer.07:24
dcalisteFrom April 2014.07:24
chriadaminteresting, makes me think that it's probably something like: for most cases, "own event" has only a single attendee: the automatically generated (by mkcal) organizer attendee07:26
chriadamif we get rid of the automatic generation, then that should no longer be a problem07:26
chriadamand then, for the case where the event IS actually an invitation, well, we just need to be sure to MANUALLY add the organizer as an attendee if required07:27
dcalistechriadam, so if we put the organizer in the attendee list, the organizer will be pinged for acceptance. In 99% of the cases that's not the desired behaviour indeed.07:27
chriadami.e. for "normal" own-event case, there should be zero attendees07:27
chriadambut for "invitation" cases there should be non-zero attendees07:27
dcalisteNot exactly : adding attendees will send invitation (current behaviour)07:27
dcalisteBut if you put the owner of the event (the one who choose the attendees, i.e. the organizer) to this list, he / she will also receive an invitation.07:28
dcalisteWhich is not desired of course.07:28
chriadamwhat if we pre-set the participation status07:28
chriadamof the organizer attendee07:28
dcalisteYou mean how to know about the participation status of the organizer ?07:30
dcalisteWell, I think anyway that the attendees don't know about the participation of others, only the organizer is notified by email, right ?07:30
chriadammost likely, but I mean that the server won't generate an invitation email for an attendee which already has a PARTSTAT set for it07:31
chriadam(I'm guessing)07:31
chriadami.e. the organizer shouldn't receive an invitation email, in that case, if we pre-set the PARTSTAT for "ourself" when manually adding ourself as an attendee.07:32
chriadam(well, maybe I'm wrong)07:32
dcalisteWell, at the moment, my understanding of the current behaviour is this one :07:33
dcaliste- boss creates an event and set a list of attendees, alice and bob.07:34
dcaliste- alice and bob will receive an invitation and will reply (or not), answers will be sent to boss.07:34
dcaliste- if boss is not adding himself in the attendee list, mKCal is doing it and boss appears as a participant in the UI, but up-syncing is removing him from the attendee list for him not to receive an invitation, it's his event after all.07:35
dcaliste- if boss actually is adding himself in the attendee list, he will be listed in the UI as a participant but up-syncing will remove him from the list and he will not receive an invitation neither.07:37
dcalisteSo basically, both last bullets are equivalent.07:37
dcalisteLet me find the line in nemo-qml-plugin-calendar where I think that the organizer is always added to the attendee list that is sent to QML.07:37
dcalisteAh yes, it is in calendarutils.cpp, see CalendarUtils::getEventAttendees(), line 170.07:39
dcalisteI think we can keep the exact same behaviour as the current one (which seems fine since there has been no bug related to this for a long time) by shunting the mKCal automatic addition and systematic removal in sync code.07:40
dcalisteThe QML binding line in utils is ensuring that UI will continue to display the organizer as an attendee, while the organizer will never receive any invitation, because mKCal has this UNIQUE constraint meaning that the organizer cannot be added as an attendee on save even if we actually put the organizer as an attendee explicitely.07:42
dcalisteWhat we actually not support and that this mkcal!63 will not help, is if we actually desire the organizer to be in the attendee list and receive an inivtation. But I think this is a very peculiar case that doesn't really need to be supported.07:44
dcalisteWhat we actually don't support neither and the mkcal!63 with not help is if we don't want to display in the UI the organizer as an attendee.07:45
chriadamyeah, that's the case I was thinking of, but given that no-one has complained about it yet, I figure that no-one is making use of it.07:45
chriadamwhat did you mean about the UNIQUE constraint?  is it really the case that we cannot store the organizer as an attendee, separately?07:46
dcalisteIndeed, the organizer is stored in the attendee table, and this table as UNIQUE contraint on (event uid, email).07:47
dcalisteThat's why the MR is only modifying the reading part, avoiding to add the organizer as an attendee.07:47
dcalisteThere is a bool in the table to distinguish between a row is an organizer or a row is an attendee.07:48
dcalisteBut since the constraint is on the email only, then well, the organizer cannot be added also as an attendee.07:48
dcalisteBut that's good !07:48
dcalisteThat's actually the desired behaviour (I mean the most common case).07:49
dcalisteJust that we cannot support to have the organizer in the attendee list (RFC wise not UI wise), which is a corner case as discussed before.07:50
chriadamI would prefer they were completely separate, and we just managed the attendee list "properly" as required.  but shrug, like you say, handling this corner case is probably not necessary anyway07:50
dcalisteWe could do it separately since the organizer is a single information for a component (it is there or not, but not duplicated), it should be stored in the component table and not in the attendee table.07:52
chriadambut, out of scope for this particular MR I suppose07:52
dcalisteThere are still some spare string fields in the component table, so we may store the organizer there.07:52
dcalisteYes, it's for later in case we would like to have a clean support for organizer could be an attendee or not.07:53
chriadamlet's not be too quick to do that, in case there is some higher-priority thing which needs this.  as you rightly point out, this "organizer not attending" case is super-corner-case07:53
dcalisteI agree.07:53
chriadamok, well, I will poke flypig and pvuorela to take a look at the MR and the new discussion points added there07:54
chriadamin regards to the Buteo sync log stuff: I asked jpetrell to take a look, last week07:54
chriadamI am not sure if he has had the time to do so yet, or not07:54
chriadamoh actually, he did say this: "I guess normal transfers page still should not show successful syncs, but we could provide pulley menu action to open advanced view with the full transfer and sync listing. Also I wonder what kind of sync logs do Android and iOS provide. If we show some kind of sync failure notifications they could potentially take you to the sync log page with actions and more info."07:55
chriadambut no concrete feedback yet, he was just thinking about things from UI perspective I guess07:55
dcalisteThanks about the comment he made. Maybe a minor misundertsanding, I'm not thinking to merge the transfer page with sync activity.07:57
dcalisteI was more thinking about a new page, with a list layout, taking the transfer page as a reference or an inspiration let say.07:57
chriadamyeah, I agree that a separate page makes more sense07:57
chriadamI'm not sure that Joona is yet convinced :-P07:58
chriadamwell, anyway, it shouldn't affect the QML interfaces07:58
dcalisteAnd additionally, if the idea is also to inform the user of possible errors with possibly log extract from server, the main point is to give a feedback for succesful cases of what has been transfered from and to the phone in term of items (event, mails...) more than in term of server log.07:59
chriadamyeah, the "success" cases are just as important as the "error" cases in many ways, and I agree that this fact necessitates a separate sort of view08:00
dcalisteAnd last argument ;) the UI part must not necessary be part of the OS itself. It can be a separated application as soon as middlearwe allow it. Except that it will have to live in openrepo because of priviledged acess and not be integrated in calendar view, will duplicate code for showing events... But it can be a strating point.08:02
chriadamyeah, I agree.  long term, I think it should be integrated into settings app, personally.08:04
dcalisteMe also, but if intermediate steps could help, no problem.08:05
chriadamyep :-)08:05
chriadamdid we cover all the topics for this week, or have I forgotten something from last week etc which needs attention?08:05
dcalisteNo that's all, one related MR is https://git.sailfishos.org/mer-core/mkcal/merge_requests/6508:06
dcalisteBut it's not directly related to what we're discussing. More for information.08:06
dcalisteI don't know much about their usecase, it started from this MR https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/8608:07
dcalisteFrom the discussion there, it seems that they will mean additional parameters that are not supported yet in KCalendarCore, but it's not completely clear for me.08:08
chriadamseems like a useful thing.  maybe we can leave that one until next meeting.  I agree that better attachments support would be nice.08:10
dcalisteSure, of course, no need to rush, it was more for information.08:10
chriadamthanks again for your efforts and time spent.  it is much appreciated!08:11
chriadamI hope you have a great week!08:11
* chriadam -> away, gnight08:12
dcalisteHave a good week.08:12
Nico[m]Wow, the 10 II is a lot faster than my compact o.o15:12
*** frinring_ is now known as frinring17:20
attahHmm... trying to fix svg scaling with an image provider... but what path do i prepend my image name to find it on disk out in c++ land?18:08
attahSailfishApp::pathTo(id).toLocalFile() apparently :)18:20

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