> > > * Only one coarse change method. There is not fine "diff" notifications. > > I agree, this can be improved, and I think it would be quite easy to > > implement. But was it requested anywhere? > > No. I was merely comparing the current status.
Then it is quite unfair to do so unless you want to bias the readers. > > > * iCal support was faulty. Well yes it had some bugs, but most of them > > are closed only two are open and one assigned to you. Is the bug history > > a reason to ditch a project? > > It certainly leaves a bad impression that fixing bugs like > https://bugs.meego.com/show_bug.cgi?id=6050 took 8 months and several > false "bug closed" status changes > (https://bugs.meego.com/show_activity.cgi?id=6050) before the fix > eventually arrived in MeeGo. > > Now we all know that the situation for fixing bugs in MeeGo was > difficult in the past. But can we be sure that it will be better in the > future? I also believe that many things can be done to improve that. > > > I'm not saying that EDS is necessarily better. It's better understood, > we know how to fix it if we run into problems. That's all, but that > matters. > Quite understandable, but isn't it that we are trying to create a platform? Why then are we sticking to a solution that is not the best one? Wouldn't it be better trying to get a nice solution? And with this I am not saying that mKcal is the best one. If there is a better option, taking into account functionality and time, lets go for it. > > About the partial loading of mKCal. Is it faulty? Please provide the bug > > number. > > It was faulty: https://bugs.meego.com/show_bug.cgi?id=6061#c5 > > I still find it hard to use correctly. For example, which events need to > be loaded to get a correct response for "events falling into the time > range 2011-03-31 00:00 Europe/Berlin until 2011-03-31 23:59 > Europe/Berlin"? Which API calls, which parameters? You need to create a KDateTime with those start and end times. Make sure that the storage has that range loaded storage->load(start, end); and the recurringIncidences also of course. You can query the calendar, for those dates also. calendar->incidences(start, end); And then you ExtendedCalendar::ExpandedIncidenceList expanded = calendar->expandRecurrences(&newNotes, KDateTime(start), KDateTime(end), numberDays, &hitLimit); To get the full expanded set. > > > mKcal also has a quite flexible plugin invitations handling. How do you > > plan to integrate the "new" backend with exchange or any other service? > > Valid point, but not relevant yet. There is no Exchange support in > MeeGo. The UIs on meego.com are barely able to handle basic calendar and > email tasks. Handling meeting invitations is out of scope right now. > Yes, it is a pity that the more capable UIs taking full advantage of > mKCal and QMF capabilities are not in meego.com or the situation would > be a lot different. > Well I think it is quite relevant, that even if there is no Exchange in MeeGo we want to have the enablers so vendors can extend the core features. And the same goes to the next "question". How is it planned to enable vendors to extend the current solution? I think it is a very valid point that should be addressed. > I beg to disagree here. The MeeGo version of KCalCore is compiled > differently than the upstream version: > > #if !defined(KCALCORE_FOR_MEEGO) > endDate = kdt.date().addDays( -1 ); > #else > endDate = kdt.date(); > #endif > Go to the kde git, and you will see those there. So the code, as I said, is from upstream. And most of them are IOP issues that we have found that are not 100% standard but we believe that need to be supported anyway. There are only two as the one you have pointed, and most likely can be fixed somewhere else. > > Yes, and the ifdef above is part of the fix for one of these bugs. My > hope is that once upstream KCalCore is used, it'll have no iCalendar > handling issues. > Wishful thinking. And you can easily try building your own copy of KcalCore without that flag and see for yourself. But at least the two open bugs, won't be affected at all. > Minor correction: EDS was not invented at Intel or for Moblin/MeeGo. I'm > also not trying to hide a political decision. I was told to investigate > EDS for MeeGo, and that's what I am doing. If you disagree with that > direction, then please talk to those who decided to go that way. That > decision was made way above my head, so talking with me about it will > gain you nothing except some clarifications about technical aspects. > I know that wasn't you, and I think it is a waste of time to try to talk to the one who made the change. But I believe that in an Open Project, doing the changes how they have been done it is not the way to go. And the technical aspects is what I want to hear. But so far, except very few based complaints about mKCal, everything else was far from technical (the same as with what is said on the wiki). > <rant>In case folks on the list still haven't noticed, I'm sticking my > neck out here because I believe that discussions should be open. So far > the result is definitely not going to encourage others to do the same. > Oh, and I'm on vacation today, I shouldn't even be reading your emails, > much less responding to them.</rant> Yes the discussion should be open, but also the decision making. Enjoy the vacation! :) _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
