| *** zbenjamin is now known as Guest59633 | 02:18 | |
| *** zbenjamin_ is now known as zbenjamin | 02:18 | |
| *** frinring_ is now known as frinring | 03:12 | |
| *** jrt is now known as Guest64913 | 03:42 | |
| *** nyov is now known as Guest91029 | 04:44 | |
| *** askolsam_ is now known as askolsam | 07:42 | |
| dcaliste | Hello chriadam, how was your day ? | 08:03 |
|---|---|---|
| chriadam | hi dcaliste, could be better - I'm a bit sick at the moment unfortunately | 08:04 |
| chriadam | how are you? | 08:04 |
| dcaliste | Too bad, I hope you'll recover soon. | 08:04 |
| chriadam | yeah, it's just a head cold. all good ;-) | 08:05 |
| chriadam | not sure if you saw, but I had a couple of comments on some QMF PRs | 08:06 |
| dcaliste | Yes, I've seen them. I need to address these few points. But I'm a bit concern with the modifications I've done to the Codec part, as pointed out by flypig. | 08:09 |
| dcaliste | QTextStream is UTF8-only in Qt6. | 08:09 |
| chriadam | yes, so output will be utf8, you mean? | 08:10 |
| dcaliste | We cannot call setCodec() on it anymore for translating on the fly. | 08:10 |
| dcaliste | When I migrate this part of the code, I tried to move away all transcoding from qmailmessage and rewrote part of it. | 08:11 |
| dcaliste | But as flypig pointed out, I may have broken some transcoding code by reading chunk in the middle of an encoded character or things like that. | 08:13 |
| dcaliste | I think, I need to fix this properly before we can proceed further. | 08:13 |
| chriadam | ah, interesting. is that because the MaxCharacters limit might be reached? thus splitting a multi-byte character? hrm. | 08:14 |
| chriadam | what is the solution? actually check whether the final chunk is "complete" or not? will that require validating all of the characters starting from the beginning of the buffer, or is there a simple way to do it from the other end? | 08:16 |
| dcaliste | I've no idea at the moment. It's kind of things I'm not familiar with. For reference, this is this patch : https://codereview.qt-project.org/c/qt-labs/messagingframework/+/313875 | 08:17 |
| chriadam | yeah | 08:21 |
| chriadam | it's not possible to set a codec on the QTextStream in Qt6, is it? or am I misunderstanding? | 08:21 |
| chriadam | flypig: have you had a chance to think about any possible solutions to that one ^ | 08:21 |
| dcaliste | Yeh, that's the problem. | 08:21 |
| flypig | I vaguely recall there being some advice in the docs about it. Maybe I can find it, I'll have a look. | 08:22 |
| dcaliste | Hello flypig, thanks. I'll try this week myself to go back to this patch and have a new look at it. Your remark, flypig, about the missing charset argument at one place is also relevant. I think I broke something there. | 08:23 |
| flypig | Here's the advice from the Qt6 docs. Looking at the example, it looks like their solution is to use a QTextDecoder. | 08:25 |
| flypig | https://doc.qt.io/qt-6/qtextcodec.html#details | 08:25 |
| flypig | From here: "The approach to use in these situations is to create a QTextDecoder object..." | 08:26 |
| flypig | I'm just scanning quickly, so this may not be appropriate. | 08:26 |
| chriadam | looks like it should be. but unless I'm misunderstanding, it means that the string needs to be built up in the while loop, and output after the while loop as finished | 08:28 |
| chriadam | not a problem, just a slight difference. | 08:28 |
| flypig | I'm not sure whether that's necessarily implied from the example; that wasn't clear to me. | 08:28 |
| flypig | If it's the case, that wouldn't be ideal. | 08:28 |
| dcaliste | Well, it looks promising. We may send back the partially decoded string into the next QTextStream now that it is UTF-8. | 08:29 |
| chriadam | depends on what toUnicode(chunk) does in the split multibyte case, I suppose | 08:29 |
| dcaliste | Well, I suppose in that case that it is waiting for the next chunk to deliver the last character. | 08:30 |
| chriadam | ah right, does that mean that toUnicode() will return the "complete" part only? | 08:30 |
| chriadam | cool, makes sense | 08:30 |
| dcaliste | I think so. | 08:30 |
| chriadam | well, excellent. | 08:30 |
| chriadam | thank you flypig | 08:30 |
| flypig | np | 08:30 |
| dcaliste | Yeh, it's explained in the toUnicode() doc of QTextDecoder. | 08:31 |
| chriadam | flypig: also, if you get a chance, can you take a quick look at my QMF PRs again - I updated according to your comments (or explained why I didn't) for all of those | 08:31 |
| dcaliste | I'll rework this patch with this then, and hopefully don't break anything this time. | 08:31 |
| chriadam | tyvm dcaliste | 08:31 |
| flypig | chriadam, sure, happy to. I was planning to go through them all in one go once everything is resolved, but if your changes are self-contained then I'll can take a look already. | 08:32 |
| chriadam | they should be self contained, yes | 08:32 |
| flypig | Okay, then I'll do that. Thanks! | 08:32 |
| chriadam | dcaliste: am I correct to assume that we only need to look at (and eventually merge) the commits in the relation chain for https://codereview.qt-project.org/c/qt-labs/messagingframework/+/337291 | 08:33 |
| chriadam | i.e. that relation chain has no "outdated" or "merge conflict" warnings in it, currently, because i rebased everything in that chain | 08:33 |
| chriadam | but there are some other commits e.g. https://codereview.qt-project.org/c/qt-labs/messagingframework/+/334754/4 which have a bunch of "not current" or "indirect ancestor" or "merge conflict" warnings, I guess because they're not properly part of the rebased chain? | 08:34 |
| dcaliste | Yes the 337291 chain is the valid one. | 08:35 |
| dcaliste | The 334754, yes you can abandon it, I've merged it into another commit as suggested by flypig and is not part of the correct chain anymore. | 08:36 |
| chriadam | cool | 08:36 |
| chriadam | well, I won't touch any other PRs just yet, I will close/abandon those other ones, once we've dealt with the "proper" relation chain | 08:36 |
| chriadam | (it'll be easier, I think, and safer ;-) | 08:36 |
| chriadam | um, on the caldav PR with setLastModified() and the extendedcalendar api addition, I created a PR for the google plugin, but there was only one point in the code which did the lastModified()/setLastModified() thing | 08:38 |
| chriadam | whereas in the caldav PR there were 3 or 4 different cases which did that | 08:38 |
| chriadam | wondering whether I missed some cases in the google calendar code, or whether we did something slightly different between those two, or what | 08:38 |
| dcaliste | I reviewed the Google MR, I think you didn't miss any. Flypig created a function some MR ago to put all property change in one place. | 08:39 |
| chriadam | ah! great | 08:40 |
| chriadam | thank you for looking at that one. (I have been sick at home friday, monday, today, so didn't see any PR comments over that time, sorry) | 08:40 |
| chriadam | in that case, I will merge the caldav and google one asap (hopefully tomorrow, maybe thursday). | 08:41 |
| chriadam | flypig: did you get a chance to look at the buteo-syncfw accounts enablement PR? | 08:41 |
| flypig | I did take a look. I have one last comment to add, but am just still trying to work something out in relation to it. | 08:41 |
| flypig | It looks good. I just want to check that Accounts stuff. But it's all fine otherwise as far as I'm concerned. Nice. | 08:42 |
| flypig | By "that Accounts stuff", I mean the enabled signals. | 08:42 |
| chriadam | indeed ... should we wait a bit for your work before merging that buteo one? | 08:43 |
| dcaliste | Ok, thank you flypig. I'm waiting for your remark. I don't know if you see some comments I made about the difference between the enabled signal for an account and the enabled signal from a manager. | 08:43 |
| dcaliste | It's this comment : https://git.sailfishos.org/mer-core/buteo-syncfw/merge_requests/59#note_73239 | 08:44 |
| flypig | Yes, it's exactly those comments dcaliste. What you say sounds correct, but when I looked through the libaccounts code, frankly, I couldn't figure it out. So I'm creating an example now just to be sure. Mostly for my own understanding. | 08:44 |
| dcaliste | Ok, great then. That's good you check also, I may be wrong indeed. | 08:45 |
| flypig | Honestly, I'm happy to accept your word on it, so do feel free to merge. But, as I say, I'd like to test it for my own understanding anyway. | 08:45 |
| flypig | I just didn't feel comfortable adding a "LGTM" until I'd properly checked. | 08:46 |
| dcaliste | That's wise :) | 08:46 |
| dcaliste | It can definitely wait for your approval. | 08:46 |
| chriadam | I agree | 08:46 |
| chriadam | were there any other PRs to discuss? | 08:47 |
| dcaliste | I don't think so, for information, I'm discussing with dyraig to solve his problem with caldav from https://forum.sailfishos.org/t/3-4-0-24-4-0-1-48-caldav-sync-with-nextcloud-server-fails/5259 | 08:49 |
| dcaliste | It seems to me that it's related to cookies not passed back. | 08:50 |
| flypig | Is there something specific to the setup? I use a NextCloud calendar and it seems to work okay. | 08:53 |
| chriadam | cookies?! I didn't know that dav was session-based | 08:53 |
| flypig | Ah, sorry, this is CalDav, not using the NextCloud account plugin. | 08:54 |
| chriadam | the other interesting thing I see in that thread is that the .well-known discovery requests seem not to be occurring according to his server logs - that's weird! | 08:54 |
| chriadam | nextcloud account plugin just uses caldav plugin under the hood | 08:54 |
| dcaliste | Yes, I'm quite surprise. It's an issue with Nextcloud being installed in a subpath of the server. | 08:54 |
| chriadam | ah | 08:55 |
| flypig | I also use a subpath here. Odd. | 08:55 |
| dcaliste | Maybe a security setting the person switched on. | 08:55 |
| dcaliste | He gave me yesterday an account on his server so I can now test freely on it. | 08:56 |
| chriadam | thank you for looking into that with him. hopefully the cookie thing is the culprit, and it can be easily fixed? | 08:56 |
| dcaliste | Yes, I've a MR not public yet that I want to test. | 08:57 |
| dcaliste | Qt is doing cookie handling in one liner if called. So if it's this, the fix is simple. | 08:57 |
| chriadam | ah great | 08:57 |
| dcaliste | I'm going to test further this week. But next week, I cannot attend our meeting, I need to go to the hospital (one last time). | 08:58 |
| dcaliste | But you may see an MR before if I'm right on the cookie fix ! | 08:59 |
| chriadam | ah! I hope all is well (is this for your finger?) | 08:59 |
| chriadam | but sounds good, thanks :-) | 08:59 |
| dcaliste | Yes, it will be a final check with the surgeon that everything is fine. | 09:00 |
| chriadam | cool. well, I hope that he can give good news. | 09:00 |
| chriadam | and I hope that you have a good two weeks - see you on the 6th of April! | 09:01 |
| chriadam | thank you as always for your effort and time and proactive help! | 09:01 |
| chriadam | it is greatly appreciated. | 09:01 |
| flypig | +1 | 09:01 |
| dcaliste | Yeh, thank you both flypig and chriadam and see you in this meeting in two weeks. Or in a MR comment before ! Enjoy your week. | 09:01 |
| * chriadam -> away, good night :-) | 09:02 | |
| flypig | By the way, dcaliste, would you have anything to add to the community news this week? | 09:02 |
| flypig | Not obligatory of course, but if you do, that'd be great. | 09:03 |
| dcaliste | flypig, no not really. QMF is still far from user land at the moment and still not ready. As a continuation of the last entry, pvuorela accepted the calligra MR, so converter will be in next-next version, as for the fix for ApB file. | 09:04 |
| flypig | Okay, I can mention about those as a follow-up. That's nice. | 09:04 |
| flypig | But okay, in that case, let's leave more news for a future update when it's all merged :) | 09:05 |
| flypig | Just finally, for info, I still have your fingerterm PR to review. Consider this a self-nudge that I need to check it. I've not forgotten about it. | 09:07 |
| *** vilpan is now known as Guest79441 | 09:07 | |
| dcaliste | flypig, no problem. | 09:08 |
| flypig | Okay; thanks again. I'll prod you for more news in a couple of weeks. | 09:09 |
| dcaliste | Exactly. Thank you flypig for these summary of what is happening around SailfishOS development. | 09:10 |
| flypig | They're quite fun to compile. It's hard to keep up with all the activity on the forum, but at least it gives me a solid reason to try :) | 09:12 |
| *** Guest79441 is now known as vilpan | 10:57 | |
| *** vilpan is now known as Guest21853 | 15:44 | |
| *** Guest21853 is now known as vilpan | 15:46 | |
| deloptes | hi, how can I understand qtcontacts-sqlite in the context of buteo-syncfw the easy way? | 22:43 |
| deloptes | I want to understand | 22:43 |
| deloptes | /home/nemo/.local/share/system/Contacts/qtcontacts-sqlite/contacts.db | 22:43 |
| deloptes | and | 22:43 |
| deloptes | /home/nemo/.local/share/system/privileged/Contacts/qtcontacts-sqlite/contacts.db | 22:43 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!