Hello Alvaro!
Let me reply on the technical aspects below. I've skipped over the MeeGo
direction and decision making questions, because those belong elsewhere
and I don't want to get drawn into that.
On Do, 2011-03-31 at 13:34 +0100, Alvaro Manera wrote:
> >
> > > * 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.
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.
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.
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.
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.
> 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 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.
> > 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.
> 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.
Are you saying that the MeeGo version supports non-standard behavior
that KDE upstream does not want to support? Can you give an example?
Attached is a patch which removes all KCALCORE_FOR_MEEGO ifdefs in favor
of using the code in KDE upstream. What would break if this patch was
used in MeeGo (app API, storage API, exported/imported
vCalendar/iCalendar)?
I looked briefly at commit messages to find an answer for that, but
didn't get far. One of these ifdefs (the "N900 and s60-phones need
enddate") was already in the initial commit, so the justification for
this change isn't public. Another line in that code was modified later,
but the commit message isn't helpful either:
commit b7d1d6032b5599320523d597ae2c4e84efc37bc4
Date: Sat Dec 4 16:33:55 2010 +0200
Fixes: NB#206351 - [Dali][PCCS] Special characters are not transferred
properly from device (Bugzilla)
IMHO if there are valid reasons for fixing something that is broken in
KCalCore, then these fixes should be used in KDE and MeeGo.
> 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! ;-)
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
diff --git a/src/icalformat_p.cpp b/src/icalformat_p.cpp
index e5ee5a0..6fed23c 100644
--- a/src/icalformat_p.cpp
+++ b/src/icalformat_p.cpp
@@ -264,12 +264,8 @@ icalcomponent *ICalFormatImpl::writeEvent( const Event::Ptr &event,
icaltimetype end;
KDateTime dt = event->dtEnd();
if ( event->allDay() ) {
-#if !defined(KCALCORE_FOR_MEEGO)
// +1 day because end date is non-inclusive.
end = writeICalDate( dt.date().addDays( 1 ) );
-#else
- end = writeICalDate( dt.date() );
-#endif
icalcomponent_add_property( vevent, icalproperty_new_dtend(end) );
} else {
if ( dt != event->dtStart() ) {
@@ -1154,11 +1150,7 @@ Event::Ptr ICalFormatImpl::readEvent( icalcomponent *vevent, ICalTimeZones *tzli
if ( kdt.isDateOnly() ) {
// End date is non-inclusive
QDate endDate;
-#if !defined(KCALCORE_FOR_MEEGO)
endDate = kdt.date().addDays( -1 );
-#else
- endDate = kdt.date();
-#endif
if ( d->mCompat ) {
d->mCompat->fixFloatingEnd( endDate );
}
diff --git a/src/vcalformat.cpp b/src/vcalformat.cpp
index 47f74be..4eed97a 100644
--- a/src/vcalformat.cpp
+++ b/src/vcalformat.cpp
@@ -452,12 +452,7 @@ VObject *VCalFormat::eventToVTodo( const Todo::Ptr &anEvent )
} else if ( recur->duration() == -1 ) {
tmpStr += "#0"; // defined as repeat forever
} else {
-#if !defined(KCALCORE_FOR_MEEGO)
tmpStr += kDateTimeToISO( recur->endDateTime(), false );
-#else
- tmpStr +=
- kDateTimeToISO( recur->endDateTime().toTimeSpec( d->mCalendar->timeSpec() ), false );
-#endif
}
// Only write out the rrule if we have a valid recurrence (i.e. a known
// type in thee switch above)
@@ -658,18 +653,12 @@ VObject *VCalFormat::eventToVEvent( const Event::Ptr &anEvent )
tmpStr = kDateTimeToISO( anEvent->dtStart(), !anEvent->allDay() );
addPropValue( vevent, VCDTstartProp, tmpStr.toUtf8() );
-#if !defined(KCALCORE_FOR_MEEGO)
// events that have time associated but take up no time should
// not have both DTSTART and DTEND.
if ( anEvent->dtStart() != anEvent->dtEnd() ) {
tmpStr = kDateTimeToISO( anEvent->dtEnd(), !anEvent->allDay() );
addPropValue( vevent, VCDTendProp, tmpStr.toUtf8() );
}
-#else
- // N900 and s60-phones need enddate
- tmpStr = kDateTimeToISO( anEvent->dtEnd(), !anEvent->allDay() );
- addPropValue( vevent, VCDTendProp, tmpStr.toUtf8() );
-#endif
// creation date
tmpStr = kDateTimeToISO( anEvent->created() );
@@ -803,12 +792,7 @@ VObject *VCalFormat::eventToVEvent( const Event::Ptr &anEvent )
} else if ( recur->duration() == -1 ) {
tmpStr += "#0"; // defined as repeat forever
} else {
-#if !defined(KCALCORE_FOR_MEEGO)
tmpStr += kDateTimeToISO( recur->endDateTime(), false );
-#else
- tmpStr +=
- kDateTimeToISO( recur->endDateTime().toTimeSpec( d->mCalendar->timeSpec() ), false );
-#endif
}
// Only write out the rrule if we have a valid recurrence (i.e. a known
// type in thee switch above)
@@ -1641,13 +1625,6 @@ Event::Ptr VCalFormat::VEventToEvent( VObject *vevent )
anEvent->setAllDay( true );
}
}
-#if defined(KCALCORE_FOR_MEEGO)
- if ( anEvent->allDay() ) {
- if ( anEvent->dtEnd() == anEvent->dtStart() ) {
- anEvent->setDtEnd( anEvent->dtEnd().addDays( 1 ) );
- }
- }
-#endif
// at this point, there should be at least a start or end time.
// fix up for events that take up no time but have a time associated
@@ -2125,11 +2102,7 @@ QString VCalFormat::kDateTimeToISO( const KDateTime &dt, bool zulu )
if ( zulu ) {
tmpDT = dt.toUtc().dateTime();
} else {
-#if !defined(KCALCORE_FOR_MEEGO)
tmpDT = dt.toTimeSpec( d->mCalendar->timeSpec() ).dateTime();
-#else
- tmpDT = dt.dateTime();
-#endif
}
tmpStr.sprintf( "%.2d%.2d%.2dT%.2d%.2d%.2d",
tmpDT.date().year(), tmpDT.date().month(),
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
