| pvuorela | dcaliste: hey | 06:58 |
|---|---|---|
| dcaliste | Hello pvuorela. | 06:58 |
| dcaliste | I'm still working on creating new multi-notebook API for mKCal. I'm quite happy with the separation introduced in mkcal#60 providing a class that handle the DB part without assuming memory storage. | 07:00 |
| dcaliste | The single notebook class introduced in mkcal#61 seems to work well (in term of API), when used in Buteo CalDAV sync plugin for instance. | 07:01 |
| dcaliste | I'm now creating a multicalendarstorage class to be used in nemo-qml-plugin-calendar. | 07:02 |
| pvuorela | nice. | 07:02 |
| dcaliste | The idea in this one is to drop the CalStorage inheritance, because there is no upstream Calendar that can handle multi-notebook cases. | 07:02 |
| dcaliste | Instead there is a calendar(notebookUid) method that returns a MemoryCalendar handling the incidence for this given notebook. | 07:03 |
| pvuorela | alright, sounds good so far. | 07:03 |
| dcaliste | If we want to drop Extended* classes in the end, we will need mkcal#39 that I revamped yesterday. | 07:04 |
| dcaliste | It is dropping useless Extended* from the service API. | 07:04 |
| dcaliste | I said useless, because I think they are better replaced by providing the notebook directly. | 07:05 |
| dcaliste | But it's yet another API break… | 07:05 |
| pvuorela | i'll check that again. still not sure how much we should be removing Ptr from existing interfaces, but that's just one aspect now. the less it depends on mkcal classes the better, i suppose. | 07:08 |
| dcaliste | I can rephrase the PR and the commit message to emphase that the important point is to drop Extended* from the API. | 07:09 |
| dcaliste | Indeed, dropping ::Ptr is now a by-product. | 07:09 |
| pvuorela | yea. for good or bad, it's on upstream apis quite consistently used. | 07:15 |
| dcaliste | But here, since we need to revamp the service API to drop the Extended* arguments, why not dropping also the ::Ptr when it makes sense (we don't store the data pointed to, and they just need to be alive for read access the time of the call). | 07:17 |
| dcaliste | For the DST issue with alarm definition like at xx:yy the day before, it's a good question. I need to (re-)reread the RFC5545 about the duration definition for an offset. I'm not sure that is something that can be easily tackled though :/ | 07:31 |
| pvuorela | hm, there is some code already for reminder datetime instead of duration. maybe that could fit the use. not as simple change as just duration options with different texts. | 07:37 |
| dcaliste | Yes, but for recurring incidence, this datetime needs to be updated by the mkcaltool, which is not something that can be defined… | 07:38 |
| pvuorela | darn :) | 07:40 |
| dcaliste | Yes, these ones are a bit annoying… I'm even not sure it's something that can be defined by RFC5545. If not, then we can't really store it. We can use well-tuned datetime for non recurring, definitely. But for recurring, duration seems to be broken and datetime is not an option since there is no way to "update" it for the next occurrence, in a RFC compatible way, I mean. | 07:43 |
| pvuorela | some part of me ponders whether to just ignore the dst problem and live with those being off by one hour on certain dates. | 07:45 |
| dcaliste | That would be simpler, indeed ;-) | 07:45 |
| dcaliste | So, let's do like that first. I'll create the PR using datetime to store the alarm, proposing consistent alarm time as you suggested (before and after the start of the all day event). | 07:51 |
| pvuorela | or just using duration with specific values? checking kf5-calendarcore alarm it has only startoffset and datetime. and if the latter doesn't work nice for recurring events, it could be that even the upstream doesn't support too well these "9 o'clock the previous day" regarding dst. | 07:57 |
| dcaliste | RFC5545 defines only datetime and duration for alarm triggers anyway. But since datetime is DST proof, why not using it, at least for non-recurring events ? Ok, it may make the code more complicated with a special duration treatment for recurring events. So, we may drop DST support in that case for all and use durations for all case, that's what you mean ? | 07:59 |
| pvuorela | option for non-recurring but if we need to support the duration anyway, maybe that would be the first thing to implement. | 08:00 |
| dcaliste | Ok, I see. Let's do like that (it will require a bit of modifications in nemo-qml-plugin-calendar, as far as I remember to support positive offsets). | 08:03 |
| *** rdr_ is now known as rdr | 22:26 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!