| *** frinring_ is now known as frinring | 01:34 | |
| *** zbenjamin_ is now known as zbenjamin | 01:49 | |
| *** SpeedEvil is now known as Guest17949 | 05:08 | |
| dcaliste | Hello chriadam, how are you ? | 06:45 |
|---|---|---|
| chriadam | hi dcaliste, I'm well, thank you. How are you? | 06:47 |
| dcaliste | I'm ok, thanks. | 06:47 |
| dcaliste | I've continue working on per item logging UI this week. The UI can easily list the UID of changed items for each log now. | 06:49 |
| chriadam | nice one | 06:49 |
| dcaliste | I've thus begun to implement the calendar parts to display events and not UIDs. | 06:49 |
| dcaliste | Work is not complete yet, it implies : | 06:49 |
| dcaliste | - to implement an event model in nemo-qml-plugin-calendar that provides the same roles than the agenda model, but for a given list of events. | 06:50 |
| chriadam | could the agenda model be parametrised somehow for that purpose, maybe? | 06:51 |
| dcaliste | - to be able to load events from UIDs from the database. | 06:51 |
| chriadam | whereas it currently loads from date range, or? | 06:51 |
| dcaliste | for the model, I think it's much simpler to create a new one than to add a property that is exclusive with the range one. | 06:52 |
| chriadam | ok | 06:52 |
| dcaliste | Then, internally, it can reuse part of the code to load event for eventqueries. | 06:52 |
| chriadam | can name it appropriately too, so that it's clear what it is for. specificity has advantages ;-) | 06:53 |
| dcaliste | Because it's just a bunch of event queries packed in a list model actually. | 06:53 |
| dcaliste | I've started with CalendarEventListModel. | 06:53 |
| dcaliste | Instead of CalendarAgendaModel for the range one. | 06:53 |
| chriadam | seems reasonable. I wonder if there is a reason to keep the List part, instead of just CalendarEventModel maybe? | 06:54 |
| chriadam | anyway, the name doesn't matter too much | 06:54 |
| dcaliste | As you prefer indeed. The current issue is that, CalDAV is logging event UIDs using Incidence::instanceIdentifier(). | 06:55 |
| dcaliste | The latter is a nice wrapper to get a string identifying single events or occurrences of a recursive one. | 06:55 |
| dcaliste | It's part of KCalendarCore. | 06:56 |
| dcaliste | So far so good. | 06:56 |
| chriadam | so, for uniformity, we should do the same in google/exchange/etc? | 06:56 |
| dcaliste | Yes, if the experimentation is conclusive with CalDAV, it can be done exactly the same in Google and Exchange. | 06:56 |
| chriadam | sounds good | 06:57 |
| chriadam | I can do that | 06:57 |
| chriadam | when we get to that point | 06:57 |
| dcaliste | See these lines : https://git.sailfishos.org/mer-core/buteo-sync-plugin-caldav/blob/master/src/notebooksyncagent.cpp#L184 | 06:57 |
| dcaliste | In the plugin, you need to get a list of modified / added / deleted incidences, so you can add their instanceIdentifiers to the target results. | 06:59 |
| dcaliste | This is already in 4.1.0 for CalDAV and is working well, as far as I can tell. | 06:59 |
| dcaliste | Now, it raised an issue, because KCalendarCore is not providing a reverse way, to get the UID and recId for a given identifier. I think it's done like that by design. So I don't want to change it. | 07:00 |
| dcaliste | What I'm trying to do at the moment is to add another load method in mKCal to load incidences based on their instanceIdentifier. | 07:01 |
| chriadam | when you say "by design" -- is there some reason why it might not be nicely roundtrippable? e.g. why parseUidAndRid(instanceIdentifier(uid, rid)) might not work? | 07:02 |
| chriadam | (where parseUidAndRid() is some hypothetical, currently-nonexistent, function) | 07:04 |
| dcaliste | It's used as a key to get the incidence from a memoryCalendar. So if you already store the incidences, you can easily get the UID and recID. I guess that's why there is no reverse function. | 07:06 |
| dcaliste | But here, the incidence are in the storage and not yet in memory. Thus my idea to add a method to get the incidence loaded from the instanceIdentifiers. | 07:06 |
| dcaliste | Like one can get the incidence from memory with Calendar::instance(identifier) from KCalendarCore. | 07:07 |
| dcaliste | I've implemented that in mKCal yesterday, but it still under tests at the moment... | 07:09 |
| chriadam | I think I understand, and I have no objections to adding such API to mkcal. I guess the "true" round-trip function, is (like you mention) to read the uid/rid from the event itself, after loading it (via the new API) from the instanceIdentifier | 07:10 |
| dcaliste | After these two middleware pieces are done (mKCal load based on instanceIdentifier and QML list model for a given list of instanceIdentifiers), one can reuse for free the QML items used to display event delegates from the calendar application, like in the evet list in month view. | 07:10 |
| chriadam | yep | 07:11 |
| chriadam | makes sense. may need some extension for clearly denoting failed events vs succeeded ones or something (background colour etc maybe) | 07:11 |
| dcaliste | Yes, currently, I'm listing only those in success for demonstrating purposes, but adding the ones in error are also planned (they are already loggued at least). | 07:12 |
| dcaliste | Looking at these middleware parts, I stubbled on some minor issues for which I've separated MRs, see: | 07:13 |
| dcaliste | - https://git.sailfishos.org/mer-core/nemo-qml-plugin-calendar/merge_requests/83 | 07:13 |
| dcaliste | - https://git.sailfishos.org/mer-core/mkcal/merge_requests/58 | 07:13 |
| dcaliste | - and https://git.sailfishos.org/mer-core/mkcal/merge_requests/59 | 07:13 |
| dcaliste | The last one is not really a fix to an issue, but a factorization of the code preparing the addition of a loadIncidenceIdentifier() function. | 07:14 |
| chriadam | sailfish os gitlab is running super slowly for me today, not sure why | 07:15 |
| *** vgtw_ is now known as vgtw | 07:15 | |
| *** mp1072 is now known as mp107 | 07:17 | |
| dcaliste | Well, if not working today, you can look at them later, no problem. It's working ok from my place actually. So an issue with the pipes somewhere ! | 07:18 |
| chriadam | interesting, might be I need to restart machine or clear some cookies or something | 07:18 |
| chriadam | well, yes, I will look into those probably tomorrow | 07:18 |
| chriadam | thank you very much | 07:18 |
| chriadam | the first one loaded - unit test issue plus an optimisation in nqpc | 07:19 |
| chriadam | interesting, so is setCalendarUid now required? | 07:20 |
| dcaliste | Yes, the database does not allow event without notebook anymore, pvuorela made validateNotebook property to true by default recently if I'm not wrong. | 07:22 |
| dcaliste | In mKCal I mean. | 07:22 |
| dcaliste | It's commit https://git.sailfishos.org/mer-core/mkcal/commit/85ebd08328b298b170964de822a0aeeb15bb4021 | 07:23 |
| dcaliste | Related to JB#53601 as far as I can tell. | 07:23 |
| chriadam | ah that's right | 07:23 |
| chriadam | hmm, an interesting thing. pvuorela ^ | 07:24 |
| chriadam | well, I hope it was just an issue with the unit test, and not something we relied in elsewhere in code using nqpc | 07:24 |
| chriadam | *relied on | 07:24 |
| dcaliste | Normally I don't think it should have propagated into normal runing code on device, I would say. All event should have a notebook actually. | 07:25 |
| chriadam | great | 07:27 |
| chriadam | what was the mkcal#58 related to? it refuses to load in my browser | 07:27 |
| dcaliste | The second MR is about the same notebook-less issue for mKCal itself. | 07:27 |
| chriadam | ah | 07:27 |
| dcaliste | Indeed ! | 07:27 |
| chriadam | cool | 07:27 |
| chriadam | well, I will check those tomorrow, and poke pvuorela also | 07:28 |
| chriadam | thank you very much | 07:28 |
| chriadam | I spoke to MartinS about the DST timezone shift PR yesterday, and he has started to take a look, and to start thinking about it. He hasn't yet commented on the PR from what I can see, but he should do so, soonish. | 07:28 |
| chriadam | his initial thoughts was to use some custom icon (like a clock with a hand sweeping from 2->3) | 07:29 |
| chriadam | but I guess he will post his thoughts in the near future once he's had a chance to think about it a bit | 07:30 |
| dcaliste | Thanks a lot. I was first thinking to a dedicated icon, but I didn't want to burden the design team with my own fantasy, that's why I fallback on this +1 idea. Let see what he will propose. | 07:31 |
| chriadam | yep :-) | 07:31 |
| chriadam | thank you for your patience | 07:31 |
| chriadam | unfortunately given that MartinS is the only full-time designer, he tends to be busy all the time, so can be hard to push things onto his already full plate sometimes haha | 07:32 |
| dcaliste | I've started also to look how to log email reception also (for the UI logging capability), but it will take more time than I expected first, since I need to add more entries in the Service class to get feedback from action like transmit or retrieve. So nothing solid at the moment (maybe I'll post a MR in buteo-sync-plugin-email to report errors because handles already exist but the plugin is always logging success at the momen | 07:34 |
| dcaliste | t). | 07:34 |
| chriadam | I can't remember anything about buteo-sync-plugin-email -> I had thought it was just a simple wrapper which then triggered the real sync process (either sailfish-eas or qmf)? or does it actually report actual statistics (added/modified/removed and errors etc)? | 07:36 |
| chriadam | or do you mean: you are adding support for the latter, now? | 07:36 |
| dcaliste | Indeed it's a wrapper for the email agent. But there is no stat report. I would like to do it. Currently it is always reporting success even if the server cannot be contacted... | 07:42 |
| chriadam | indeed. | 07:43 |
| chriadam | sounds good, let me know what needs to be added to e.g. qmf layers or so, as I guess we will need to add something similar to exchange side | 07:45 |
| chriadam | well, I don't remember how any of that works, but flypig_ probably does ^ | 07:45 |
| dcaliste | There is no report provided from QMF as far as I investigated it. So I'll need to add it. But this part of QMF is quite complex with the server/client architecture. It will take time actually for me to see where to insert the stat report. | 07:47 |
| chriadam | makes sense. | 07:47 |
| dcaliste | It was just to mention actually. To go with the logging work. | 07:47 |
| chriadam | indeed, thanks very much for looking into it. of course if there's anything that flypig or I can do to help, please let us know | 07:48 |
| chriadam | was there any other items for today? or things I forgot to follow up on, from previous meeting? | 07:48 |
| dcaliste | No, I think it's fine. Thanks for the discussion about the instance identifier. | 07:50 |
| chriadam | thank you very much for your time and effort | 07:51 |
| chriadam | I hope you have a great week! | 07:51 |
| * chriadam -> away, gnight | 07:51 | |
| rinigus | hi! is there a way to ask `mb2` to install dependencies with vendor change allowed? for example, if I have ohm in the shared output RPMS dir and want to use that instead of the system-provided one. | 08:29 |
| rinigus | right now, if the package in shared RPMS folder has vendor set to none and tries to replace the system one (vendor meego), mb2 will choke on zypper install of dependencies | 08:30 |
| *** vilpan is now known as Guest70628 | 14:38 | |
| *** Guest70628 is now known as vilpan | 14:38 | |
| Thaodan | I don't think that is possible | 15:45 |
| Thaodan | In a way it is on purpose since you could try the user into installing rpm from a different source | 15:46 |
| pketo | rinigus: in zypp.conf there is option solver.allowVendorChange | 16:03 |
| rinigus | pketo: yes, that one I found and changed. then all worked nicely. | 16:42 |
| rinigus | Thaodan: indeed, it is on purpose. problem is that when we have those shared RPMS folder during a build of many packages, there is no way to let mb2 to use those new packages if there is something like that already available in the system | 16:44 |
| Thaodan | Well if those are no the same level they should have the same vendor | 16:55 |
| rinigus | Thaodan: example: when I recompile ohm for tama port, vendor would change from meego (as was set on Jolla's OBS) to unset (as on my build). as a result, I get a package that will not be pulled into build target automatically, but I have to somehow force it | 17:02 |
| rinigus | which defeats the purpose of automatic build system :) | 17:02 |
| Thaodan | Yes that is why set vendor to meego for those packages | 17:09 |
| rinigus | OK, I'll file feature request and we can discuss + / - over there at the forum | 17:25 |
| Thaodan | mb2 build --define 'vendor foobar' | 17:50 |
| Thaodan | rinigus ^ | 17:50 |
| rinigus | Thaodan: nice, that may work. except I have sony as a vendor for some packages, I think | 18:19 |
| rinigus | let me try | 18:19 |
| *** flx is now known as mflux | 18:28 | |
| rinigus | Thaodan: not sufficient, unfortunately. we have packages as `droid-config-hxxxx` which have vendor "sony". so, they will not be able to replace other configs :( | 18:33 |
| rinigus | but I will try to run it, to see what will happen | 18:34 |
| rinigus | so far, it is mainly a guess | 18:34 |
| Thaodan_ | You are not supposed to do that globally at least not for droid- packages | 18:34 |
| rinigus | Thaodan_: yes, that I am doing for all of them by setting vendor defined. but, configs have vendor defined already | 18:41 |
| rinigus | https://github.com/sailfishos-sony-tama/droid-config-sony-tama-pie/blob/master/droid-config-common.inc#L2 | 18:41 |
| Thaodan_ | I know | 18:42 |
| rinigus | issue opened at forum | 19:20 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!