[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-pim
Subject: Re: [Kde-pim] ical handling library
From: Shaheed <srhaque () iee ! org>
Date: 2005-04-15 12:10:38
Message-ID: 200504151310.39157.srhaque () iee ! org
[Download RAW message or body]
On Thursday 14 April 2005 21:06, Allen Winter wrote:
> Helge, et.al.
>
> Just to let you know that we just committed the "newest" libical (version
> 0.24 RC4) which is a least 2 years old into kdepim. I backported local KDE
> mods that were less than 3 years old.. that were obviously correct fixes. I
> also ported a few mods from Lutz Rogowski's kdepimpi project.
>
> We'll find out how much breakage there is soon enough :)
If you care, I attach my line-by-line comparison of the deltas between
upstream libical 0.24 RC4 and the kdepim version of May 2004.
The problem is that the exchange between me and the maintainer petered out
after a couple of rounds, and without test data, I was reliant on that :-(.
So it might only be of limited use.
Thanks, Shaheed
["Remaining libical differences between kdepim and upstream." (text/x-diff)]
From srhaque@iee.org Sun May 30 12:16:06 2004
From: Shaheed <srhaque@iee.org>
To: Cornelius Schumacher <schumacher@kde.org>,
Reinhold Kainhofer <reinhold@kainhofer.com>,
Andrea Campi <a.campi@inet.it>
Subject: Remaining libical differences between kdepim and upstream.
Date: Sun, 30 May 2004 12:16:06 +0100
User-Agent: KMail/1.6.52
Cc: acampi@users.sourceforge.net,
kdepim@mail.kde.org
References: <200404142057.45638.srhaque@iee.org> <20040510232726.GA69021@inet.it> \
<200405121909.46309.srhaque@iee.org>
In-Reply-To: <200405121909.46309.srhaque@iee.org>
X-KMail-Link-Message: 1091916924
X-KMail-Link-Type: reply
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200405301216.06113.srhaque@iee.org>
Status: RO
X-Status: RSC
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:
Cornelius, Reinhold, Andrea,
I've been working through the libical differences between kdepim and upstream
for some time now (since I started, a couple of commits have been made to
kdepim, I have forwarded those to Andrea separately).
With Andrea's help, I have eliminated all but a few changes in three files.
Apart from a couple of big ones (removal of stpc support, and rewrite of
icaltime.c).
For the remaining differences, since it is not easy to tell what the right
thing is, I need your help to resolve these please. I have tried to attach
your names and relevant comments to them.
icalproperty.c
************
==== cschumac ====
There are a bunch of changes bracketed in
#ifdef KCAL_ADDLINEBREAKS
#endif
The changes seem to be there to add extra line breaks (or, in some cases,
spaces), but AFAICS, kdepim never defines KCAL_ADDLINEBREAKS, so these
changes seem ripe to be dropped.
The changes appeared in 1.6. The original commit comment for 1.6 was "More
concise formatting of iCalendar string output.".
icalrecur.c
*********
==== cschumac, acampi ====
This file has these changes listed by line number:
2125: The first is a difference in return value - anyone know what the
significance of that change is? I think we need to understand what the
intent is to push this upstream.
ditto: The second is an algorithmic change which I think is OK either way.
2263,2278: This is clearly a deliberate change
The changes appeared in 1.6. The original commit comment for 1.6 was "Fixed
handling of TRIGGER properties with DURATION values.".
icalvalue.c
*********
==== acampi, kainhofe ====
718: This code is attempting to wrap the line in a Unicode-sensitive manner.
==== acampi ====
794: The only significant difference here is that kdepim supports Base64
encoded values. This support does seem to originate with older libical
libraries: it was NOT added by kdepim.
==== acampi, cschumac ====
866: Suppress the time portion of a datetime. This change appeared in 1.11
with the comment "Correctly write UNTIL parameter of RRULE property if it is
a date without time.".
I'm not sure what the most efficient way to resolve these conflicts is, I hope
that it is possible to work through them somehow, and then resync before the
next kdepim release.
Also, below, you will find a set of psuedo-diffs between kdepim head and
upstream head which address just these listed differences.
Thanks, Shaheed
Encls: psuedo-diffs...
*******************************************************************
--- libical/src/libical/icalproperty.c 2004-03-17 19:06:50.000000000 +0000
+++ /home/srhaque/kdecvs/kdepim/libical/src/libical/icalproperty.c 2003-02-18
23:53:51.000000000 +0000
various to do with KCAL_ADDLINEBRERAKS.
*******************************************************************
--- libical/src/libical/icalrecur.c 2004-05-10 23:47:28.000000000 +0100
+++ /home/srhaque/kdecvs/kdepim/libical/src/libical/icalrecur.c 2003-06-26
16:00:52.000000000 +0100
@@ -2125,26 +1980,26 @@
}
static int next_year(icalrecur_iterator* impl)
{
struct icaltimetype next;
+ /* Next_year does it's own interatio in days, so the next level down is
hours */
if (next_hour(impl) == 0){
- return 0;
+ return 1;
}
if (impl->days[++impl->days_index] == ICAL_RECURRENCE_ARRAY_MAX){
impl->days_index = 0;
-
- for (;;) {
increment_year(impl,impl->rule.interval);
expand_year_days(impl,impl->last.year);
- if (impl->days[0] != ICAL_RECURRENCE_ARRAY_MAX)
- break;
}
+
+ if(impl->days[0] == ICAL_RECURRENCE_ARRAY_MAX) {
+ return 0;
}
next =
icaltime_from_day_of_year(impl->days[impl->days_index],impl->last.year);
impl->last.day = next.day;
impl->last.month = next.month;
@@ -2263,7 +2120,7 @@
break;
}
case ICAL_YEARLY_RECURRENCE:{
- next_year(impl);
+ valid = next_year(impl);
break;
}
default:{
@@ -2278,7 +2135,7 @@
}
} while(!check_contracting_rules(impl)
- || icaltime_compare(impl->last,impl->dtstart) < 0
+ || icaltime_compare(impl->last,impl->dtstart) <= 0
|| valid == 0);
*******************************************************************
--- libical/src/libical/icalvalue.c 2003-01-16 01:14:21.000000000 +0000
+++ /home/srhaque/kdecvs/kdepim/libical/src/libical/icalvalue.c 2004-03-27
15:21:40.000000000 +0000
@@ -718,65 +642,75 @@
return icalrecurrencetype_as_string(recur);
}
- /* @todo This is not RFC2445 compliant.
- * The RFC only allows:
- * TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B / %x5D-7E /
NON-US-ASCII
- * As such, \t\r\b\f are not allowed, not even escaped
- */
+char* icalvalue_text_as_ical_string(icalvalue* value) {
-static char* icalvalue_text_as_ical_string(const icalvalue* value) {
char *str;
char *str_p;
char *rtrn;
const char *p;
size_t buf_sz;
+ int line_length;
+
+ line_length = 0;
- buf_sz = strlen(value->data.v_string)+1;
+ buf_sz = strlen(((struct icalvalue_impl*)value)->data.v_string)+1;
str_p = str = (char*)icalmemory_new_buffer(buf_sz);
if (str_p == 0){
return 0;
}
-
- for(p=value->data.v_string; *p!=0; p++){
+ for(p=((struct icalvalue_impl*)value)->data.v_string; *p!=0; p++){
+ /* If length>=68, check for beginning of a unicode char. */
+ if ( ( line_length >= 65 && *p == ' ') || (line_length >= 75) ||
+ ( line_length >= 68 && ((unsigned char)(*p)>=192 || (unsigned char)
(*p)<64) ) ) {
+ icalmemory_append_string(&str,&str_p,&buf_sz,"\n ");
+ line_length=0;
+ }
switch(*p){
case '\n': {
icalmemory_append_string(&str,&str_p,&buf_sz,"\\n");
+ line_length+=3;
break;
}
case '\t': {
icalmemory_append_string(&str,&str_p,&buf_sz,"\\t");
+ line_length+=3;
break;
}
case '\r': {
icalmemory_append_string(&str,&str_p,&buf_sz,"\\r");
+ line_length+=3;
break;
}
case '\b': {
icalmemory_append_string(&str,&str_p,&buf_sz,"\\b");
+ line_length+=3;
break;
}
case '\f': {
icalmemory_append_string(&str,&str_p,&buf_sz,"\\f");
+ line_length+=3;
break;
}
case ';':
case ',':
- case '"':
- case '\\':{
+ case '\\': {
icalmemory_append_char(&str,&str_p,&buf_sz,'\\');
icalmemory_append_char(&str,&str_p,&buf_sz,*p);
+ line_length+=3;
break;
}
default: {
icalmemory_append_char(&str,&str_p,&buf_sz,*p);
+ line_length++;
}
}
+
}
/* Assume the last character is not a '\0' and add one. We could
@@ -794,29 +729,34 @@
}
-static char*
-icalvalue_attach_as_ical_string(const icalvalue* value)
-{
- icalattach *a;
+char* icalvalue_attach_as_ical_string(icalvalue* value) {
+
+ struct icalattachtype *a;
char * str;
icalerror_check_arg_rz( (value!=0),"value");
a = icalvalue_get_attach(value);
- if (icalattach_get_is_url (a)) {
- const char *url;
-
- url = icalattach_get_url (a);
- str = icalmemory_tmp_buffer (strlen (url) + 1);
- strcpy (str, url);
+ if (a->binary != 0) {
+ return icalvalue_binary_as_ical_string(value);
+ } else if (a->base64 != 0) {
+ str = (char*)icalmemory_tmp_buffer(strlen(a->base64)+1);
+ strcpy(str,a->base64);
return str;
- } else
- return icalvalue_binary_as_ical_string (value);
+ } else if (a->url != 0){
+ icalvalue *v = icalvalue_new_text( a->url );
+ char *icalstring = icalvalue_string_as_ical_string(v);
+ icalvalue_free( v );
+ return icalstring;
+ } else {
+ icalerror_set_errno(ICAL_MALFORMEDDATA_ERROR);
+ return 0;
+ }
}
-static char* icalvalue_duration_as_ical_string(const icalvalue* value) {
+char* icalvalue_duration_as_ical_string(icalvalue* value) {
struct icaldurationtype data;
@@ -866,21 +803,24 @@
void print_datetime_to_string(char* str, const struct icaltimetype *data)
{
print_date_to_string(str,data);
- strcat(str,"T");
- print_time_to_string(str,data);
+ if ( !data->is_date ) {
+ strcat(str,"T");
+ print_time_to_string(str,data);
+ }
}
_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic