| *** zbenjamin is now known as Guest76663 | 01:17 | |
| *** zbenjamin_ is now known as zbenjamin | 01:17 | |
| dcaliste | Hello chriadam, it's been a while, how are you ? | 06:58 |
|---|---|---|
| chriadam | hi dcaliste, I'm well thank you. How are you? | 06:58 |
| dcaliste | I'm ok, thank you. Let's start if you agree with QMF related matters. | 06:59 |
| chriadam | certainly | 06:59 |
| chriadam | pvuorela: flypig: available currently to discuss? | 06:59 |
| dcaliste | You may have noticed https://forum.sailfishos.org/t/email-text-disappears-with-pgp-signature/1768 | 06:59 |
| dcaliste | It's about malformed emails when signed with the QMF plugin. | 07:00 |
| chriadam | ah, not quoting the multipart correctly? | 07:00 |
| dcaliste | With the help of rozgwi, we've found that it's an issue in QMF, where some parameters of the Content-Type are not quoted when needed. | 07:01 |
| dcaliste | See https://codereview.qt-project.org/c/qt-labs/messagingframework/+/312509 for the fix. | 07:01 |
| flypig | chriadam, sure, I'm available, but a bit clueless today. | 07:01 |
| dcaliste | It seems that the '/' character was missing somehow in the list of protected characters. | 07:02 |
| dcaliste | and thus "application/pgp-signature" was not escaped. | 07:02 |
| chriadam | that is very strange, would have thought that mime types would often be of that form, and thus be hit frequently... but i guess not... | 07:03 |
| dcaliste | Looking at the commit history it seems that the slash has never been part of the protected characters. | 07:03 |
| chriadam | the PR LGTM but I've also pinged Matt in case he has some concern | 07:04 |
| dcaliste | Yes, but it's more subtile : | 07:04 |
| dcaliste | the Content-Type value should _not_ be quoted (even if with slash), but the parameter values _must_ be quoted when containing a protected character. | 07:04 |
| dcaliste | S you write Content-Type: multipart/signed; protocol="application/pgp-signature"; myParam=foo; | 07:05 |
| dcaliste | So | 07:05 |
| dcaliste | Normally the MR is chaging the quoting only for value of parameters. | 07:06 |
| chriadam | ah | 07:06 |
| chriadam | I see | 07:06 |
| dcaliste | If the MR is accepted, there is another issue at hand : the CI is now using the Qt6 to-be dev branch in one of the bot. And the code is not Qt6 ready at all :/ So Ci is always failing and the MR won't go in. | 07:08 |
| chriadam | indeed | 07:08 |
| dcaliste | As suggested by pvuorela, I've compiled locally Qt6 and begun to compile QMF on top. | 07:08 |
| chriadam | I have this problem with QtPIM also - which I hope to address within the next two weeks, by porting QtPIM to build against Qt6/dev | 07:08 |
| dcaliste | It's a lot of work, almost all files have issues. | 07:08 |
| chriadam | ouch :-( | 07:09 |
| chriadam | ooi what sort of issues are you hitting frequently? I thought qt6 was supposed to be mostly compatible, but apparently not? | 07:09 |
| dcaliste | QRegExp has been replaced with QRegularExpression but with a different API, QTextCiodec is not part of QtCore anymore… | 07:09 |
| dcaliste | Some of the QMetaType functions have disappeared (because they are handled automatically). | 07:09 |
| dcaliste | Maybe some unforseen other issues, since at the moment, it has stopped on every 5 or 6 first files. | 07:11 |
| chriadam | ouch | 07:13 |
| dcaliste | I'm afraid it will take some days to finish the transition. | 07:14 |
| chriadam | if you don't have time / inclination to finish the qmf porting, my advice would be: once the codereview PR is +2'd, make similar PR to our qmf repo, and we can just merge it on our side. | 07:14 |
| dcaliste | But if you say that you're doing the same for QtPim, I'm feeling safer. | 07:14 |
| chriadam | but if you are willing to do the work, that would be fantastic | 07:15 |
| chriadam | yes, I am definitely going to do it for QtPIM | 07:15 |
| chriadam | hopefully within next two weeks. | 07:15 |
| *** vilpan is now known as Guest91294 | 07:17 | |
| *** Guest91294 is now known as vilpan | 07:17 | |
| chriadam | dcaliste: should we discuss your calendar PRs next? I think jpetrell has some time to discuss those | 07:18 |
| jpetrell | sure | 07:19 |
| dcaliste | I will do it, I think for QMF. | 07:19 |
| chriadam | tyvm | 07:19 |
| dcaliste | Yes, we can discuss them, sure. | 07:19 |
| chriadam | you mentioned that upstream kcalcore accepted the MR related to the volatile properties from other sources (e.g. mkcal) | 07:21 |
| chriadam | flypig: did you review some of the PRs related to the volatile property support also? | 07:22 |
| dcaliste | Yes, now our KCalcore MR contains exactly what is upstream. | 07:22 |
| jpetrell | sorry am not really up-to-speed with the calendar status. the proposed time zone combo box looks good, would yeah integrate it with time picker dialog like how alarm dialogs in Clock app integrate custom UI below time picker | 07:23 |
| flypig | chriadam, if I did, it was a while ago. Are they still pending? I can take another look. | 07:24 |
| chriadam | flypig: yes, kcalcore MR#19 and nemo-qml-plugin-calendar MR#61 | 07:25 |
| chriadam | jpetrell: can you expand a bit on that regarding the time picker dialog? | 07:25 |
| chriadam | pvuorela: did you have any issues with the function naming in nemo-qml-plugin-calendar MR#51 (start time in event timezone etc exposed in event), or anything else? Or is it good to go? | 07:26 |
| flypig | MR#19 already LGTM. Sorry dcaliste for making you suffer my comments on it. | 07:26 |
| jpetrell | dcaliste mentioned time zone picker could fit nicely time picker dialog so when you pick time you can also choose the reference point / time zone | 07:27 |
| flypig | And thanks for your helpful explanation. | 07:27 |
| jpetrell | would not like to add new things to calendar event dialog, e.g. we will need to add attachment picker there at some point | 07:28 |
| dcaliste | jpetrell, yes I agree, if we can avoid to add new combo / entries in the EventEditDialog, that would be great ! | 07:28 |
| dcaliste | As you said, for the time zone MR, it would require to add a TZ combo at the bottom of the time picker. | 07:29 |
| dcaliste | But this require modifications to silica, and at first I think it was to invasive. | 07:29 |
| dcaliste | And was afraid that will make the MR rejected. | 07:30 |
| chriadam | does dcaliste have access to the appropriate silica repo for that, or is that something we would have to do? | 07:30 |
| dcaliste | Yes, I have access to theis repo. | 07:30 |
| dcaliste | There is a design issue also with this (because at home I indeed tried to modify it already…) : | 07:30 |
| jpetrell | dcaliste: TimePickedDialog is just Dialog { TimePicker {}}, can make own dialog i.e. Dialog { Column { TimePicker {} TimeZonePicker {}} | 07:30 |
| jpetrell | } | 07:31 |
| dcaliste | on landscape orientation, I don't know where to put the zone combo. | 07:31 |
| jpetrell | oh true that is a bit tricky (clock doesn't turn landscape on phone and on tablet there is plenty of space in landscape) | 07:32 |
| dcaliste | jpetrell, you're right, remembering it I hacked it like that during first tries. | 07:32 |
| dcaliste | jpetrell, yes for clock, but calendar is rotating on phone. | 07:32 |
| dcaliste | And on phone (and particularly on lastest elongated form-factor), there is no space below the time wheel. | 07:33 |
| dcaliste | At least on my JollaC, there is already no space :( | 07:33 |
| dcaliste | Moving the wheel to the left and add a combo on the right, like a two colomn thing looks ugly in my opinion. | 07:34 |
| pvuorela | pong, joined the party here. | 07:35 |
| dcaliste | flypig, thank you the review, don't worry for the comments, it's always better to ask. Questions are always relenvant. | 07:36 |
| pvuorela | don't have any complaining myself on the timezone stuff. was planning on doing a final round and then getting it in. | 07:36 |
| jpetrell | dcaliste: this is how clock does it http://www.joona.net/clock_timerdialog_landscape.png | 07:36 |
| pvuorela | the timepicker alternative could be actually tricky in the sense that event has start and end time and we probably want to keep them in the same zone. | 07:37 |
| jpetrell | so the footer content is either anchored to the bottom or right side of time picker | 07:37 |
| jpetrell | pvuorela: but event (like trip) may start in different country and end in another | 07:38 |
| dcaliste | pvuorela, thanks, but the question of adding more wdgets is still under debate it seems. Would be nice to find a way not to add too many things there. | 07:38 |
| jpetrell | if you don't specify end time time zone it could automatically follow start time time zone | 07:38 |
| pvuorela | jpetrell: yes, it's an allowed thing by the spec but supporting that might have needless complication. e.g. then we need to show both in the main calendar editor anyway. | 07:39 |
| jpetrell | pvuorela: well only if they differ | 07:39 |
| dcaliste | In QML binding, there is no problem to have different timezones for start and end, so at least on the implementation side, it's ok. | 07:39 |
| jpetrell | similarly if time zone is the same as systems no need to show time zone info | 07:40 |
| dcaliste | jpetrell, to go in pvuorela direction, there is also the issue of display in the editor: in the time picker implementation, then we need to write CEST or what ever timezone name somewhere. | 07:40 |
| dcaliste | We have space to do it, but we don't have these shorter names easily available I think ? Or do we ? | 07:41 |
| jpetrell | that is true, the current "starts/ends" item is tiny | 07:41 |
| dcaliste | And, often people don't know their meaning anyway, while with the combo it's written Paris time, which is easily understandable for everyone. | 07:41 |
| pvuorela | yep. | 07:43 |
| jpetrell | ok I am also leaning toward having it in main calendar dialog since you need an item there anyways to show differing time zone | 07:43 |
| jpetrell | and the different time zones for start and end is kind of edge case | 07:43 |
| jpetrell | looks like most platforms provide only one time zone option in event dialog | 07:44 |
| jpetrell | calendar event dialog would benefit from some landscape optimization | 07:45 |
| dcaliste | Yep, and about adding more stuff there, I've got some initial implementation of timed reminders which could be convenient for all day events to set a reminder at 18.00 two days before for instance, but this is adding yet another combo in the editor dialog… | 07:46 |
| dcaliste | There is no MR yet though, I was waiting for the previous reminder MR about displaying unsupported duration to enter first to avoid too many conflicts on my side. | 07:47 |
| chriadam | sorry which repository is that MR? | 07:49 |
| dcaliste | It's the jolla-calendar one. | 07:49 |
| dcaliste | pvuorela recently accepted it,. | 07:49 |
| chriadam | oh | 07:49 |
| chriadam | cool | 07:49 |
| dcaliste | It was MR#265 | 07:50 |
| dcaliste | You still cannot select arbitrary value though… | 07:50 |
| chriadam | ok, so what was the result from the above discussion: are we all happy with merging those two MRs (nqpc#51 + jolla-calendar#252) as-is, or are there some changes required still? | 07:51 |
| dcaliste | The timed value is easier to implement, that's why I started with this, custom reminder still need more thoughts from a design point of view at least. | 07:51 |
| dcaliste | But diverging, about the timezone MRs, I think pvuorela and jpetrell agree on the current implementation. But I let them answer ;) | 07:52 |
| chriadam | I think that was the case too. pvuorela are you happy to do the merge/tag of those ones, then? | 07:53 |
| pvuorela | yes, no complaining. i'll still do that check so cannot promise yet i'll approve it, but likely will :) | 07:53 |
| chriadam | thank you | 07:53 |
| chriadam | ok, on the other one (sync errors): I pinged MartinS again to check the comment you made on jolla-calendar PR#266 | 07:54 |
| flypig | Am I safe to merge MR#19 and MR#61 independent of all this? | 07:54 |
| chriadam | from my perspective, yes - so long as pvuorela is ok with the naming of those event start time in tz methods etc | 07:54 |
| chriadam | I was/am happy with both of those | 07:54 |
| chriadam | (haven't yet looked at the related caldav buteo PR, however, but that's separate / can wait I think) | 07:55 |
| dcaliste | chriadam, about the buteo MR, I've been using it daily without issues at the moment for several weeks. I'm adding unit tests at the moment. | 07:56 |
| chriadam | excellent | 07:57 |
| dcaliste | May take some more days / few weeks if I put the QMF migration as a priority though ;) | 07:57 |
| chriadam | indeed, thanks | 07:59 |
| chriadam | ok, were there any other PRs to discuss, or other topics? | 08:00 |
| chriadam | Oh, I saw another jolla-calendar PR | 08:01 |
| chriadam | the time span labels for multi-day events | 08:01 |
| pvuorela | dcaliste: excellent that you've started looking into qmf/qt6! | 08:02 |
| dcaliste | Yes, other MRs are mainly cosmetic but annoying me ! | 08:02 |
| chriadam | jpetrell: have you had a chance to look at that one (jollca-eldnar PR#264)? | 08:02 |
| pvuorela | hope it gets easier at some point. | 08:02 |
| dcaliste | pvuorela, yes but it could be long. | 08:02 |
| flypig | Is https://bitbucket.org/jolla/ui-jolla-calendar/pull-requests/267 still alive? | 08:03 |
| chriadam | hrm, interesting one. | 08:05 |
| chriadam | I outsource all of my focus knowledge to andrew :-P | 08:06 |
| pvuorela | as commented there, it's tricky and wouldn't necessarily want to have page specific handling. | 08:07 |
| jpetrell | chriadam: not yet, but I trust pvuorela's judgement on time formatting topic, he understands localization better :) | 08:08 |
| chriadam | definitely | 08:10 |
| chriadam | I guess that PR#264 was one which pvuorela was going to check again soon | 08:10 |
| chriadam | pvuorela: on the one hand, I agree in principle. but in practice, if this is a pain point for many users, maybe worth making an exception? | 08:11 |
| dcaliste | About the multi-day formatting, having 12.30-23.59 or 12.30- looks not nice in my opinion, but having it with text may not be convenient for every languages… | 08:11 |
| chriadam | regarding 267 here I mean ^ | 08:11 |
| flypig | For #267 is the status that the behaviour is good, but the implementation needs looking at more? | 08:12 |
| dcaliste | chriadam, yes indeed thanks ;) I'm always closing the keyboard when editing an event. | 08:12 |
| pvuorela | chriadam: also an option, but would be still nice to investigate the common solution. | 08:13 |
| chriadam | can you elaborate a bit on how you envisage such a common solution might work/look? | 08:14 |
| chriadam | is this some hint to vkb about how to react to focus changes or so? | 08:14 |
| pvuorela | from the top of my head, one option could be some page status handling for removing focus, that's at least on one place, but then again it prevents using hardware keyboards when coming back. then again do we want to support focus but no vkb requested, dunno. | 08:18 |
| pvuorela | there is already softwareInputPanelEnabled property, controlling whether focus asks for vkb, but that's for a generic case. | 08:19 |
| dcaliste | pvuorela, ah, indeed making the focus lost for hardware keyboard, is not nice inded. That's a good point making search for a better option desirable. | 08:21 |
| dcaliste | But I'm afraid it's out of my competences at the moment :/ | 08:21 |
| pvuorela | qwdiget side has focus reason passed, if we had that it could be used to alter behavior, but recall qtquick focus doesn't have such. | 08:22 |
| dcaliste | Ok, that's a valid enough reason for me (the hardware keyboard stuff) not to accept #367 as is. Indeed, I can live with closing the vkb by hand a bit more ;) | 08:24 |
| dcaliste | #267. | 08:24 |
| dcaliste | Not that far yet. | 08:25 |
| dcaliste | chriadam, jpetrell, flypig and pvuorela, thanks for the discussion today and the advance in various topics at hand. I need to go soon to the physiotherapist and will have to leave in 5 minutes. | 08:27 |
| chriadam | thank you for your time and efforts, dcaliste | 08:27 |
| chriadam | as always, greatly appreciated | 08:27 |
| chriadam | I think we made some good progress today, and will see some of those MRs being merged shortly I hope | 08:27 |
| chriadam | I hope your physio appt goes well! | 08:27 |
| chriadam | will see you next week :-) | 08:27 |
| pvuorela | dcaliste: thank you, good stuff happening! | 08:27 |
| flypig | Thanks dcaliste. | 08:27 |
| dcaliste | Thank you also for your time and considering all my MRs ! My hand is slowly but consistently recovering, so everything's fine. | 08:28 |
| chriadam | great! | 08:28 |
| dcaliste | Have a nice week. | 08:28 |
| flypig | Yeah, glad to hear it. Good recovery. | 08:29 |
| chriadam | thanks to everyone for helping also | 08:30 |
| chriadam | with PRs and reviewing etc. much appreciated. | 08:30 |
| niqos | Hi | 09:25 |
| niqos | can the autorithy (police, government) make wiretapping pushing on a jolla device using android malware or need an sailfish malware? | 09:26 |
| ggabriel | long story short: in most cases, yes | 09:27 |
| ggabriel | (you don't need any of the conditions in your OR statement) | 09:28 |
| niqos | thanks | 09:30 |
| *** frinring_ is now known as frinring | 11:15 | |
| attah | coderus: Have you seen mb2 and sdk-assistant claiming to not have any targets inside Docker? (only version shows up) | 18:57 |
| attah | Trying to split your yaml file to a named Docker step in its own repo | 18:57 |
| coderus | attah: probably you trying to use -base image instead of normal image with preinstalled targets | 20:19 |
| attah | Hmmm, but it does work locally with the same Dockerfile | 20:20 |
| attah | i.e. this https://github.com/attah/buildfish/blob/master/Dockerfile | 20:20 |
| Nico[m] | Are you sure you are running as the nemo user? I'm not sure if dockerfiles keep the same user or default to root | 20:43 |
| Nico[m] | Ah, looks like they should be | 20:45 |
| attah | Noted, will check, tomorrow | 21:09 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
