| *** jrt is now known as Guest26637 | 02:14 | |
| *** frinring_ is now known as frinring | 04:29 | |
| ViGe | rubdos[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 |
| ViGe | hmm | 06:57 |
| ViGe | It does change the port even on docker engine, at least for me it does | 06:58 |
| chriadam | hi dcaliste, I hope that your week has been good | 07:00 |
| dcaliste | Hello chriadam, thanks it was fine. I wish the same for you. | 07:00 |
| chriadam | yeah, I had a fine week too, thanks | 07:01 |
| dcaliste | I've seen yesterday evening that Martin gave a detailed feedback on the time shift MR. Thank him much for me. | 07:01 |
| chriadam | oh, nice, I didn't see it yet | 07:02 |
| chriadam | yes, I will | 07:02 |
| dcaliste | I'll work on his suggestions later this week or the week after. | 07:02 |
| chriadam | great! | 07:03 |
| chriadam | I am currently taking a quick look at mkcal#63 - interesting case | 07:03 |
| chriadam | I think in general, the organizer of an event does NOT have to be an attendee, but they MAY be | 07:03 |
| ViGe | rubdos[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 |
| chriadam | I 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 |
| chriadam | certainly, 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 try | 07:04 |
| ViGe | rubdos[ma]: Please do | 07:04 |
| chriadam | I just wonder whether this change might introduce some subtle regression for some cases involving invitations etc | 07:04 |
| chriadam | I will add a comment to the PR anyway in case Pekka has some thoughts also | 07:06 |
| rubdos[ma] | Ha, it jumped back to 8080 ViGe :P | 07:06 |
| dcaliste | Indeed, 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" now | 07:06 |
| dcaliste | Without thinking if this is right or wrong, this push me to remove adding it initially in mKCal. | 07:07 |
| dcaliste | But 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 |
| ViGe | rubdos[ma]: I'm filing an internal bug report about this | 07:09 |
| rubdos[ma] | Thanks, and thanks! :-) | 07:09 |
| chriadam | dcaliste: 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 |
| chriadam | I 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 |
| dcaliste | At 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 |
| dcaliste | Indeed, good point about event creation... But syncing code will remove it, at least for Google sync and CalDAV one. | 07:12 |
| dcaliste | So if there's a regression it's in the UI code. | 07:12 |
| dcaliste | But this will not happen since the organizer is always readded in nemo-qml-plugin-calendar when listing attendees. | 07:13 |
| chriadam | hmm, 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 |
| dcaliste | I'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 |
| dcaliste | That'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 |
| chriadam | there are very helpfully zero comments around that line of code haha | 07:16 |
| chriadam | I will check git commit history | 07:16 |
| dcaliste | Good idea, let's have a look in CalDAV also in case there is a bug id... | 07:16 |
| chriadam | 98196a9e [sociald] Organizer of the event shouldn't be in the attendees list. Fixes JB#43029 | 07:19 |
| *** vilpan is now known as Guest19762 | 07:19 | |
| *** Guest19762 is now known as vilpan | 07:19 | |
| chriadam | Bug 43029 - [BUG] Own events in Google calendar turn into invitations | 07:20 |
| chriadam | ahah. | 07:20 |
| chriadam | related to https://together.jolla.com/question/189920/google-calendar-sync-auto-invites-me/ | 07:20 |
| chriadam | added comment to mkcal MR for us to consider/discuss | 07:22 |
| dcaliste | Indeed, thanks. In CalDAV it's a commit from blam : 9554557f5e8b34f69190c0304085888e072c62c7 | 07:24 |
| dcaliste | Same commit message : we don't want this behaviour as it turns the event into an invitation for the organizer. | 07:24 |
| dcaliste | From April 2014. | 07:24 |
| chriadam | interesting, 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 attendee | 07:26 |
| chriadam | if we get rid of the automatic generation, then that should no longer be a problem | 07:26 |
| chriadam | and 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 required | 07:27 |
| dcaliste | chriadam, 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 |
| chriadam | i.e. for "normal" own-event case, there should be zero attendees | 07:27 |
| chriadam | but for "invitation" cases there should be non-zero attendees | 07:27 |
| dcaliste | Not exactly : adding attendees will send invitation (current behaviour) | 07:27 |
| dcaliste | But 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 |
| dcaliste | Which is not desired of course. | 07:28 |
| chriadam | what if we pre-set the participation status | 07:28 |
| chriadam | of the organizer attendee | 07:28 |
| dcaliste | You mean how to know about the participation status of the organizer ? | 07:30 |
| dcaliste | Well, I think anyway that the attendees don't know about the participation of others, only the organizer is notified by email, right ? | 07:30 |
| chriadam | most likely, but I mean that the server won't generate an invitation email for an attendee which already has a PARTSTAT set for it | 07:31 |
| chriadam | (I'm guessing) | 07:31 |
| chriadam | i.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 |
| dcaliste | Well, 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 |
| chriadam | right | 07:35 |
| 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 |
| chriadam | right | 07:36 |
| 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 |
| dcaliste | So basically, both last bullets are equivalent. | 07:37 |
| dcaliste | Let 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 |
| dcaliste | Ah yes, it is in calendarutils.cpp, see CalendarUtils::getEventAttendees(), line 170. | 07:39 |
| dcaliste | I 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 |
| dcaliste | The 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 |
| dcaliste | What 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 |
| dcaliste | What 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 |
| chriadam | yeah, 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 |
| chriadam | what did you mean about the UNIQUE constraint? is it really the case that we cannot store the organizer as an attendee, separately? | 07:46 |
| dcaliste | Indeed, the organizer is stored in the attendee table, and this table as UNIQUE contraint on (event uid, email). | 07:47 |
| dcaliste | That's why the MR is only modifying the reading part, avoiding to add the organizer as an attendee. | 07:47 |
| chriadam | agh... | 07:48 |
| dcaliste | There is a bool in the table to distinguish between a row is an organizer or a row is an attendee. | 07:48 |
| dcaliste | But since the constraint is on the email only, then well, the organizer cannot be added also as an attendee. | 07:48 |
| dcaliste | But that's good ! | 07:48 |
| dcaliste | That's actually the desired behaviour (I mean the most common case). | 07:49 |
| dcaliste | Just 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 |
| chriadam | yeah... | 07:50 |
| chriadam | I 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 anyway | 07:50 |
| dcaliste | We 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 |
| chriadam | indeed | 07:52 |
| chriadam | but, out of scope for this particular MR I suppose | 07:52 |
| dcaliste | There are still some spare string fields in the component table, so we may store the organizer there. | 07:52 |
| dcaliste | Yes, it's for later in case we would like to have a clean support for organizer could be an attendee or not. | 07:53 |
| chriadam | let'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-case | 07:53 |
| dcaliste | I agree. | 07:53 |
| chriadam | ok, well, I will poke flypig and pvuorela to take a look at the MR and the new discussion points added there | 07:54 |
| chriadam | in regards to the Buteo sync log stuff: I asked jpetrell to take a look, last week | 07:54 |
| dcaliste | Thanks. | 07:54 |
| chriadam | I am not sure if he has had the time to do so yet, or not | 07:54 |
| chriadam | oh 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 |
| chriadam | but no concrete feedback yet, he was just thinking about things from UI perspective I guess | 07:55 |
| dcaliste | Thanks about the comment he made. Maybe a minor misundertsanding, I'm not thinking to merge the transfer page with sync activity. | 07:57 |
| dcaliste | I 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 |
| chriadam | yeah, I agree that a separate page makes more sense | 07:57 |
| chriadam | I'm not sure that Joona is yet convinced :-P | 07:58 |
| chriadam | well, anyway, it shouldn't affect the QML interfaces | 07:58 |
| dcaliste | And 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 |
| chriadam | yeah, 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 view | 08:00 |
| dcaliste | And 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 |
| chriadam | yeah, I agree. long term, I think it should be integrated into settings app, personally. | 08:04 |
| dcaliste | Me also, but if intermediate steps could help, no problem. | 08:05 |
| chriadam | yep :-) | 08:05 |
| chriadam | did we cover all the topics for this week, or have I forgotten something from last week etc which needs attention? | 08:05 |
| dcaliste | No that's all, one related MR is https://git.sailfishos.org/mer-core/mkcal/merge_requests/65 | 08:06 |
| dcaliste | But it's not directly related to what we're discussing. More for information. | 08:06 |
| dcaliste | I don't know much about their usecase, it started from this MR https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/86 | 08:07 |
| dcaliste | From 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 |
| dcaliste | s/mean/need/ | 08:08 |
| chriadam | seems like a useful thing. maybe we can leave that one until next meeting. I agree that better attachments support would be nice. | 08:10 |
| dcaliste | Sure, of course, no need to rush, it was more for information. | 08:10 |
| chriadam | :) | 08:11 |
| chriadam | thanks again for your efforts and time spent. it is much appreciated! | 08:11 |
| chriadam | I hope you have a great week! | 08:11 |
| * chriadam -> away, gnight | 08:12 | |
| dcaliste | Have a good week. | 08:12 |
| Nico[m] | Wow, the 10 II is a lot faster than my compact o.o | 15:12 |
| *** frinring_ is now known as frinring | 17:20 | |
| attah | Hmm... 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 |
| attah | SailfishApp::pathTo(id).toLocalFile() apparently :) | 18:20 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!