Hello again! (I didn't press send on Friday) here it goes now...
> > That wasn't the intention. Instead the goal was to point out areas > that'll need improvements, because that is relevant for > staffing/resource planning discussions. My apologies if this necessarily > subjective summary turned out to be offending. > No apologies need. But anyway lets skip that part, as we won't go anywhere. > If you have the time to work on better change reporting, then supporting > the KCalCore CalendarObserver [1] would be useful for the QML calendar > app [2]. Right now that app does not react to changes made in the > background by some other app or process (like sync), which is an obvious > missing feature. Adding it based on the "database changed" signal was > under discussion, but then there never was time to actually implement > it. > The app doesn't react to that because the Observer that gets those modifications is the StorageObserver not the CalendarObserver. And as you mentioned before, right now there is no diff changes. So you need to reload all. > To the community: if anyone is interested in improving that part of the > app, with CalendarObserver or the already existing mKCal signal, please > shout. I'm sure such help would be welcome. I'm copying Sirisha, the > main developer of that app. > > [1] > http://api.kde.org/4.x-api/kdepimlibs-apidocs/kcalcore/html/classKCalCore_ > 1_1Calendar.html#acf6d752ffc403159f1ac8633dd07e680 [2] > http://meego.gitorious.org/meego-ux/meego-app-calendar > > > > > 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. > > Thanks for clarifying that. The "of course" part for recurring > incidences is not that obvious for users of the library :-/ I have seen > the call and suspected that it is needed for this purpose, but never > found it spelled out explicitly. As with the previous problem, I think there are two "drawbacks" of mKCal. First one, Documentation. The methods are documented but there are no clear examples on how to use the apis. And the APis can be strange at the beggining due to the inheritance of the Storage and Calendar concepts from the originall KCal and extending them. (this most likely can be overcome fixing the first problem). > > It would also have been possible that "storage->load(start, end)" loads > "relevant" recurring events. This could be implemented by calculating a > bounding box ("start time, end time", with "end time = infinity" also > allowed) for recurring events and use that to determine the "relevant" > part quickly. > I think it is not that simple. Because you need to expand the recurrences to see if something from the past happens in that range. And if you move to the future, calculating those windows can be too complicated to make right. > I don't know what the official position is for binary-only extensions > and plugin mechanisms in MeeGo middleware. My expectation is that > vendors will be allowed to modify middleware if they have specific needs > not addressed by it. > Even if it is too wide topic, some mechanisms should be available (at least something basic as in mKCal) to extend functionality to extend with services. And with that I am not including only "close" as Exchange, but if I want to use CalDav to send invitations? That should be taken into account when creating an architecture. > IMHO if there are valid reasons for fixing something that is broken in > KCalCore, then these fixes should be used in KDE and MeeGo. I agree with that. That can be taken into the other mailing list. > > Enjoy the vacation! :) > > It's not much of a vacation, just some days off because I didn't take > enough time off last year. And here I am again enjoying my vacation by > posting on meego-dev. Darn! ;-) Take it easy and read you next week :) _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
