Hi,
> -----Original Message-----
> From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com]
> On Behalf Of ext Patrick Ohly
> Sent: 18. huhtikuuta 2011 12:21
> To: Manera Alvaro (Nokia-SD/Helsinki); Muppavarapu, Sirisha; Goddard
> Michael (Nokia-SD-Qt/Brisbane)
> Cc: meego-dev@meego.com
> Subject: [MeeGo-dev] KCalCore API changes (was: Re: migration (back) to
> EDS - contacts and calendar)
>
> Hello!
>
> I believe MeeGo KCalCore API semantic differs from upstream KDE in the
> interpretation of the endDate value. See below for the details.
>
> I would like to have this fixed *before* releasing MeeGo 1.2 with the
> modified API semantic. It's not part of the official platform API, but
> does get used and thus fixing it later just means more code will have
> been written against the modified API.
>
> Alvaro, can you comment on why the API semantic was changed? If I
> misunderstand the situation or lack certain information, then let's
> better resolve such a misunderstanding. ;-}
>
> Sirisha, you would have to adapt the MeeGo UX calendar app. Doable?
>
> Michael, how about QtMobility Organizer?
including myself and Mika Tikkakoski, current tech lead for mobility PIM area
into the discussion. Mika, could you comment on Patrik's question here.
Tero Äijälä
PM / Qt Mobility
>
> Anyone else depending on the KCalCore end date semantic?
>
> Bye, Patrick
>
> On So, 2011-04-03 at 21:18 +0100, Patrick Ohly wrote:
> > On Fr, 2011-04-01 at 11:29 +0200, Patrick Ohly wrote:
> > > > > 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.
> > >
> > > My point is that the MeeGo version of KCalCore is functionally
> different
> > > from the one in KDE. That the code is upstream is irrelevant as
> long as
> > > ifdefs are used for more fundamental changes than merely getting
> the
> > > code to compile on a different platform.
> >
> > My suspicion all along was that these defines around end date change
> the
> > semantic of KCalCore. To verify that, I modified the test program
> from
> > BMC #6050 such that it imports an iCalendar 2.0 all-day event and
> prints
> > its start/end date after importing into KCalCore.
> >
> > Code attached, compile/run with:
> > rm -rf ~/.calendar && \
> > g++ -g test-allday-semantic.cpp `pkg-config --cflags --libs
> libmkcal ` && \
> > ./a.out
> >
> > In MeeGo with KCalCore 4.1.18 I get
> > start QDate("Wed Apr 5 2006") end QDate("Thu Apr 6 2006")
> >
> > After recompiling that version without KCALCORE_FOR_MEEGO I get:
> > start QDate("Wed Apr 5 2006") end QDate("Wed Apr 5 2006")
> >
> > In other words, the patch changes the semantic of dtEnd() for
> > applications. Upstream KDE uses "dtEnd() is inclusive", the MeeGo
> > version uses "dtEnd() is exclusive".
> >
> > The latter is closer to iCalendar 2.0, but is that a good enough
> > justification to break compatibility with apps ported from KDE? I
> don't
> > think so.
> >
> > Another possible justification would be that the original semantic
> > cannot express an "empty" all-day event (start == end). Again I would
> > consider not modifying the API as more important than this cleanup.
> >
>
>
> _______________________________________________
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
