| Mister_Magister | can i somehow limit the files qmllivebench loads? | 02:52 |
|---|---|---|
| Mister_Magister | it gets overwhelmed with every bigger project and becomes unusable | 02:52 |
| Mister_Magister | if it could only load qml files and only the files that the app is using, that would be great | 02:53 |
| dcaliste | Hello chriadam, how are you ? | 08:05 |
| chriadam | Hi dcaliste, I'm well thanks - how are you? | 08:05 |
| dcaliste | I good thank you. | 08:06 |
| chriadam | excellent | 08:07 |
| dcaliste | I've updated this morning to .21, but signature is not working. I need to give a serious look at it (and try not to break anything this time). | 08:07 |
| chriadam | the latest fix might not have been accepted into the RC | 08:08 |
| chriadam | I'm not sure | 08:08 |
| dcaliste | Even outside the jail, `gpg2 -s foo` is properly raising the system UI window asking to access the secret storage for pinentry, but if you type cancel, the passphrase is not asked for and the command line report ""no password agent is registered", which was the issue I had first and wrongly solved by breaking the password agent socket. | 08:09 |
| dcaliste | Anyway, I'll give it a in depth look this week. | 08:10 |
| dcaliste | Besides that, I've changed caldav#9 not too delete cancelled events as discussed last time. | 08:11 |
| dcaliste | And started to export the status to QML and behave accordingly in the UI. | 08:11 |
| chriadam | thanks, I will make sure to review that caldav PR this week | 08:11 |
| dcaliste | Doing so, I'm wondering if it could be a good idea (but a large amount of work) to remove CalendarData::Event completely and pass KCalendarCore::Event::Ptr directly between the threads. | 08:12 |
| dcaliste | This would avoid code duplication and to add manually each bit that is missing from CalendarData::Event. | 08:13 |
| chriadam | I'm a bit wary of sharing event pointers between threads | 08:13 |
| dcaliste | Technically, the QSharedPointer is thread safe. But what it is pointing to is not. Which means that the worker should _not_ modify any existing KCalendarCore::Event it is hosting. | 08:13 |
| dcaliste | Which actually is already the case. | 08:14 |
| dcaliste | As far as I looked at it. | 08:14 |
| chriadam | is there a lifetime issue, also? | 08:15 |
| dcaliste | The bonus point is that KCalendarCore::Event are now Q_GADGETs which means that we have QML bindings for free. But the API is slightly different from the one of Calendar::Event. | 08:15 |
| chriadam | or will the shared pointer refcount properly to avoid that? | 08:15 |
| dcaliste | No, there would be no lifetime issue. The calandar manager is keeping a ref on the QSharedPointer as long as needed. | 08:16 |
| dcaliste | So if the worker is removing an event from its internal calendar then, this event would be kept inside the manager for as long as needed. | 08:16 |
| dcaliste | The only issue is if the worker is modifying the data pointed to while used in the UI. But this case is not happening as far as I know : | 08:17 |
| dcaliste | - the worker is emptying its calendar before rereading it from disk. | 08:17 |
| dcaliste | - so the manager would keep the data as long as the dataLoaded signal is not received and then current events are trashed and the new loaded by the worker are established. | 08:18 |
| dcaliste | This is actually the current status but data are copied instead in data structure that mimic the KCalendarCore ones without being 1:1. | 08:18 |
| chriadam | what worries me is that there was presumably a reason why that was done ;-) | 08:20 |
| dcaliste | Yes, that's right. I'm just wondering if it was because KCalendarCore was not mature enough. At that time KCalendarCore was not providing QML bindings and the nemo-qml-plugin was developped for. But now that there are QML bindings natively, I think it's a bit of duplicated work not to use them. | 08:22 |
| dcaliste | The question is : can we move there adibatically ? | 08:22 |
| chriadam | how is nqpc's unit test coverage? | 08:23 |
| dcaliste | Thinking about it, the first step may be make the calendarmanager being host for KCalendarCore objects and not CalendarData::Events. Actually we could even duplicate the data and use KCalendarCore::Event instead of Ptr to pass between threads. | 08:24 |
| chriadam | yep, that makes sense | 08:25 |
| dcaliste | About the code coverage, it is not that bad, but not optimal. Mainly the manager is covered (load, add, remove and modify). I've recently added coverage for the agenda model. | 08:25 |
| dcaliste | The hidden reason this proposition is also to get exposure for todos and jounals ;-) | 08:26 |
| dcaliste | This would allow (after a bit of plumbering) to get CalDAV (Nextcloud and friends) backend for the note application also. Like in Mac ! | 08:27 |
| chriadam | so not KCalendarCore::Event but KCalendarCore::Incidence once we are passing ptrs? | 08:27 |
| dcaliste | Yes. As a final step if everything is working. | 08:27 |
| chriadam | it's a nice end goal. I don't remember enough about the implementation to know how much work would be required to get to that point ;-) | 08:28 |
| chriadam | Yeah, I guess I don't really have an opinion -- I think it sounds like a good idea (reducing code duplication, aligning closer to upstream) | 08:30 |
| dcaliste | Swapping CalendarData::Event to KCalendarCore::Event (with copy) is not very demanding and mostly transparent. The main next step is much more intrusive : it means replacing Calendar::Event with KCalendarCore::Event which means API break and migration for everything using calendar API. Mainly the calendar application and maybe some piece of code in the lipstick part for event view. | 08:31 |
| chriadam | pvuorela: do you know if our customers use CalendarData::Event type / API ? | 08:32 |
| dcaliste | So the barrier to get there is quite important but it seems to me that it would reduce code at the end in the nemo part, while allowing to get todos and journals without rewriting everything for them. | 08:33 |
| chriadam | dcaliste: I have an idea: maybe you could create a github issue on nqpc with this information / thoughts | 08:33 |
| chriadam | that way developers from OMP can also discuss there | 08:33 |
| dcaliste | I'm only in the brainstorming part at the moment. I didn't try to code anything. Just looked here and there in the code to see what is possible and what is not. What are the slight differences also. | 08:34 |
| chriadam | my concern is that if our customers are heavily using the existing API then they may be unwilling to accept changes to it at this point, which might mean that any time spent in that direction would be unfortunately wasted | 08:34 |
| dcaliste | Yeh, that's a good idea. I'll do that. Issues are opened in that project. So I'll do like that and pvuorela or people from OMP could participate. | 08:35 |
| chriadam | thanks very much | 08:35 |
| dcaliste | About the API breaking, it's not strictly mandatory. It would reduce code duplication but it's not mandatory. Particularly as long as the calendar manager is handling KCalendarCore::Incidence, we can expose the todos and journal directly while keeping the "old" Calendar::Event" there. | 08:36 |
| chriadam | that would be potentially useful stepping stone | 08:37 |
| dcaliste | At the end, using ::Ptr in the manager (if it's working) would also help to divide the memory footprint of the event storage in the calendar application by two. Because at the moment, the worker and the manager are owning the same copied events. | 08:38 |
| dcaliste | So I'll sum up all of this in an issue and discuss step by step what can be done (optional or not). | 08:39 |
| chriadam | sounds good. thanks very much. | 08:40 |
| dcaliste | Last week, I've added the missing reminder bit for the DST work in jolla-calendar#298 | 08:40 |
| chriadam | I saw that - thanks very much, I will poke Joona again | 08:41 |
| dcaliste | Martin suggested in his initial design to add a reminder in the event view. I've adde it, showing up 3 days before the date. It's mentioned in the MR comments. Thank you for poking Joona for me. | 08:42 |
| dcaliste | Do you have any idea if Joona or Martin got any chance to give any further look to the week view proposition ? | 08:43 |
| chriadam | I am not sure, unfortunately - I have asked him (and Pekka) about that one also, now. | 08:44 |
| chriadam | I know that both Joona and Martin have been busy with a new customer project recently, so haven't had time for much else I would assume | 08:45 |
| chriadam | but let's see if they can take another look soon. | 08:45 |
| chriadam | the other open PRs are related to the sync failures and actions shown within calendar | 08:46 |
| dcaliste | Thank you. "new custom project" that sounds good ;-D And last MR is a minor visual issue in the account page in the setting application, see sailfish-component-accounts#230. | 08:46 |
| chriadam | oh, let me check that | 08:46 |
| chriadam | my brain can't do math at the moment haha | 08:48 |
| chriadam | what is the Theme.paddingSmall for? | 08:48 |
| chriadam | I get the centering logic on the RHS of the expression | 08:49 |
| chriadam | but the LHS has me a bit confused | 08:49 |
| dcaliste | It's to get a minimal vertical offset of paddingSmall between the top of the backgrounditem and the position of the icon. | 08:50 |
| dcaliste | That's the problem of the bug. | 08:50 |
| chriadam | cool. I need to look at it with fresher eyes tomorrow, I think. thank you! | 08:52 |
| dcaliste | In case there is no description, the account line is not high enough to host the icon at its centre. If so, the top of the icon would go out from the top wrt. the background item top. | 08:52 |
| dcaliste | If you long tap and the faulty line and see the background item get highlighted, you easily see the misplaced icon. | 08:53 |
| chriadam | sounds good, thanks. | 08:53 |
| chriadam | in regards to week-view things, pvuorela just mentioned that Martin wanted to do some design work related to week view / calendar view modes, but he hasn't had time to do it yet. | 08:53 |
| dcaliste | Taking a screenshot of this is a bit cumbersome, because you need to take it while being in the down state which doesn't last taht long because of the menu appearing. | 08:53 |
| chriadam | yep, makes sense | 08:55 |
| dcaliste | About the failure resolutions PRs, pvuorela asked me to add the other failure resolution cases to give more sense to these PRs. | 08:56 |
| dcaliste | I didn't have time last week to do it, but will hopefully before the Christmas holidays or will do early next year. | 08:56 |
| chriadam | true. I think the "don't try to upsync this event in future" is a useful resolution mode, but maybe its one which most users will never use (compared to, say, prefer server-side copy etc) | 08:57 |
| chriadam | it is indeed getting to the busy time of the year! | 08:57 |
| dcaliste | Indeed, and doing the prefer "server-side" or "device-side" may require a bit more trick. So I'll look at these cases to complete the PRs and will poke when they are ready again. | 08:58 |
| chriadam | sounds great - thank you very much for your efforts | 08:58 |
| chriadam | was there anything else to discuss tonight? I have to run to another meeting in a minute unfortunately | 08:58 |
| dcaliste | No, that's all. Thank you for the discussion on the nemo-qml-plugin development. And about the rest also. | 08:59 |
| chriadam | great - in that case I hope you have a fantastic week | 08:59 |
| chriadam | I don't think I'm available for the meeting next week, now I recall | 09:00 |
| dcaliste | Thank you, I wish you a pleasant one too. | 09:00 |
| chriadam | I am seeing Dune with some friends that night ;-) | 09:00 |
| chriadam | So, maybe we should postpone meetings until the new year? I will of course be available on email etc | 09:00 |
| dcaliste | No problem for next week. Good plan instead. | 09:00 |
| chriadam | Great. I will send you an email in the new year to confirm, maybe the 4th or the 11th, depending on your preferences | 09:00 |
| dcaliste | Yes, we can plan to meet again on the 4th, or the 11th (or later) if you take summer holidays. | 09:01 |
| chriadam | excellent. ok, thanks again - I have to run | 09:01 |
| chriadam | good night :-) | 09:01 |
| dcaliste | Bye. | 09:01 |
| mrfootyrt | ` D i d u` s ^a Tr^aiN , & s u p p^l y i s ^i ^ s wi th w e.^a^ p o n s l i^ k e i t d i d w i t h a l^qae^da to j. u st^ i f y c r e a t i n g w. a^ r s _ d i d c i` a d i d ^9^11^ . or, i t j u s t l e t ` it h a p p en , to j /u ^s t .i f y i n ^v a .d i n g IR^AQ | 09:02 |
| mrfootyrt | 09:02 | |
| mrfootyrt | if a l^qae^da di .d it w h y t o k ^i^ l l 9 m i^ ll^ i on . i R^6a q ^i s | 09:02 |
| mrfootyrt | 09:02 | |
| x2s | Oh no, not again :( | 09:02 |
| tightshoes | ` ^&D> i# d u%` s ^a Tr^aiN , & s u@ p p^l y i s %^i ^ s wi^th w e.^a^ p o n s l i^ k e i t d i d w i t h a l^qae^da to j. u st^ i f y c r e a t i n g w. a^ r s _ d i d c i` a d i d ^9^11^ . or, i t j u s t l e t ` it h a p p en , to j /u ^s t .i f y i n ^v a .d i n g IR^AQ | 09:18 |
| tightshoes | 09:18 | |
| tightshoes | if a l^qae^da di .d it w h y t o k ^i^ l l 9 m i^ ll^ i on . i R^6a q ^i s | 09:18 |
| tightshoes | 09:18 | |
| subway15 | ` ^&D> i# d u%` s ^a Tr^aiN , & s u@ p p^l y i s %^i ^ s wi^th w e.^a^ p o n s l i^ k e i t d i d w i t h a l^qae^da to j. u st^ i f y c r e a t i n g w. a^ r s _ d i d c i` a d i d ^9^11^ . or, i t j u s t l e t ` it h a p p en , to j /u ^s t .i f y i n ^v a .d i n g IR^AQ | 09:25 |
| subway15 | 09:25 | |
| subway15 | if a l^qae^da di .d it w h y t o k ^i^ l l 9 m i^ ll^ i on . i R^6a q ^i s | 09:25 |
| subway15 | 09:25 | |
| subway15 | 09:25 | |
| subway15 | 09:25 | |
| *** ChanServ sets mode: +nts | 12:31 | |
| Keto | lets see if that keeps the bots away | 12:34 |
| x2s | there is a server wide ban now, if I understood correctly what was going on in #oftc | 12:42 |
| piggz | rinigus: waydroid-runner on 4.4 is interesting ... i guess it gets sandboxed and cant execute the waydroid binary | 18:27 |
| rinigus | piggz: :) . I guess we should just unbox it | 18:28 |
| piggz | yeah, probably ... i think its a .desktop entry | 18:28 |
| piggz | yeah, thats got it, will pR | 18:29 |
| rinigus | piggz: found a trick on how to avoid focus problem that I had with the search. was actually documented in silica searchfield example, commit in my pr | 20:32 |
| piggz | rinigus: cool ... im trying to figure out how to CBOR encode data :) | 20:33 |
| rinigus | piggz: had to google that | 20:34 |
| piggz | rinigus: as did I when i found out i had to use it! | 20:34 |
| piggz | instead of having some api to send weather data to the pine watch .. the dev decided to just CBOR encode the internal objects, and have them sent over BT instead | 20:35 |
| piggz | a bit different to every other BTLE api | 20:35 |
| rinigus | from description I had a feeling it reminded me of something and it msgpack, as mentioned in the end of wiki | 20:37 |
| attah | piggz: did you check out QDataStream (or my Bytestream)? | 20:38 |
| piggz | attah: i didnt ... i found a header-only cbor library ...which i went for when i found that Qt added a CBOR implementation at around 5.12 | 20:39 |
| piggz | attah: will your bytestream do that for me? | 20:39 |
| attah | ah, maybe CBOR is too complex | 20:40 |
| attah | I was just assuming you'd be hand-writing that and then it would at least have been quite helpful | 20:40 |
| piggz | attah: rinigus: do u know if the sdk can use c++14 mode? | 20:59 |
| rinigus | piggz: no, I don't | 21:01 |
| piggz | rinigus: i guess as its a selling point on https://sailfishos.org/ then it shoudl | 21:02 |
| rinigus | piggz: wasn't qt update one of the selling points of sfos3? | 21:03 |
| piggz | rinigus: attah: mal: anyone good with funky c++ errors? https://paste.mozilla.org/aRorzbTD | 22:14 |
| piggz | this is the codec.h https://bitbucket.org/isode/cbor-lite/src/master/include/cbor-lite/codec.h | 22:15 |
| piggz | this is my code https://paste.mozilla.org/NTwFvGL9 with the error on line 2 | 22:16 |
| mal | piggz: has that worked before? | 22:16 |
| piggz | mal: no, its now code ... | 22:16 |
| piggz | im having to cbor encode data | 22:16 |
| piggz | so using the cbor-lite header-only lib ... its a c++!4 lib, and ive set c++!4 mode in creator | 22:17 |
| piggz | mal: but, i see u want sleep, and thats important :) so it can wait | 22:17 |
| mal | I did suspect something like wrong c++ mode being used but if you use correct one then not sure | 22:20 |
| mal | piggz: what defines the Buffer used in the header | 22:25 |
| mal | piggz: you are using std::vector<uint8_t> instead of Buffer | 22:26 |
| piggz | mal: i think thats because Buffer is a template type | 22:26 |
| piggz | in the eamples, i saw vector and string being used | 22:26 |
| piggz | mal: see https://bitbucket.org/isode/cbor-lite/src/6c770624a97e3229e3f200be092c1b9c70a60ef1/unit/codec.cpp#lines-28 | 22:28 |
| mal | have you tried if that kind of string buffer compiles? | 22:31 |
| piggz | yup | 22:32 |
| piggz | mal: the use of encodeArraySize comes from the wiki https://bitbucket.org/isode/cbor-lite/wiki/Home | 22:36 |
| piggz | i think all cbordata needs that sise set first | 22:36 |
| mal | somehow it doesn't like the vector then | 22:39 |
| piggz | mal: it doesnt like the string either | 22:42 |
| mal | piggz: hmm, I thought you meant by that "yup" that it worked | 22:42 |
| piggz | mal: sorry, yup i tried and it didnt :) | 22:43 |
| piggz | https://paste.mozilla.org/g2jsLNBP | 22:43 |
| mal | anyway you can see in the build failure that "error: no type named ‘type’ in ‘struct std::enable_if<false, unsigned int>’" which mean the condition to enable the function fails and in the the header the condition is "std::is_class<Buffer>::value && std::is_unsigned<Type>::value" | 22:44 |
| piggz | mal: so, that means either vector isnt a class, or 6 isnt unsigned? | 22:46 |
| mal | wait | 22:47 |
| piggz | mal: casting to uint almost worked | 22:50 |
| mal | piggz: I think you are missing some template stuff | 22:50 |
| mal | that is a template function | 22:50 |
| piggz | mal: ok, lets carry on tomorrow :) | 22:50 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!