A step ahead (Mail now integrated in KDE-Pim/Pi)

[ulf1]

I m posting this from my Z - so dont mind the layout

I think i know where the "other" thing comes from

KaPi on windows users upper case for HOME  -  CELL  -  WORK  etc

KaPi on zaurus uses lower case

once you copy your std.vcf from one to another, the numbers are all marked as "other" and if you save, the HOME, etc are gone

chero

Hello Chero,

it looks like you found something. I could verify that the Zaurus stores the types in lowercase, while the Windows desktop version uses uppercase letters.
And as a result of that, the zaurus interprets the types (lowercase letters) of copied files incorrect, and displays "other".

This will be fixed in one of the next versions.
thanks,
Ulf

[Chero]

no thanks !

I should thank you guys I simply love KoPi and KaPi so far.
Keep on going !!

chero

[slocaus]

I think i know where the "other" thing comes from

KaPi on windows users upper case for HOME  -  CELL  -  WORK  etc

KaPi on zaurus uses lower case

chero

Please don't assume that we all use Windows.  
I had the same issue when I imported directly from a Linux KAB, and when I used an old Palm and converted to CSV format to import.

Anyway, I still have the "Other" for all phone numbers, and I see my existing phone numbers with no labels and then all the other labels with no phone numbers;  Ulf's explanation a few messages back makes sense, I just wonder where it changed between 1.9.0 and 1.91??  No matter really, I have chosen to go through and manually edit and correct in KA/Pi using vncviewer and the keyboard on my desktop.  (Did I mention I love linux?    

This version 1.9.2a/b is very useable for me.  Fastload works fine with KO & KA;  I can do almost everything with Zaurus menu and keyboard buttons.  (I'd still like to have more Menu control of KA, but I know it is coming, right?)

Cheers again to your fantastic work, zautrix and ulf!  In about 1/2 week we have gone from a new alpha with some glitches to an alpha that I trust 90% (I make daily backups to my SD and then use rsync to make a complete directory tree of my Z on my desktop, along with 14 days of backup files.)

Carry on, each release just gets more excting in what you can do!

[slocaus]

Hello Chero,

it looks like you found something. I could verify that the Zaurus stores the types in lowercase, while the Windows desktop version uses uppercase letters.
And as a result of that, the zaurus interprets the types (lowercase letters) of copied files incorrect, and displays "other".

This will be fixed in one of the next versions.
thanks,
Ulf

Ulf, something changed between 1.9.0 (displayed fine for me), and 1.9.1/2/a that showed this behavior.  I have most of my editing done (as stated on the Z via vncviewer) so I don't think I want to go back to 1.9.0  and look or test, unless it might help you in some way??

[ulf1]

Ulf, something changed between 1.9.0 (displayed fine for me), and 1.9.1/2/a that showed this behavior.  I have most of my editing done (as stated on the Z via vncviewer) so I don't think I want to go back to 1.9.0  and look or test, unless it might help you in some way??

Hello slocaus,

there is no need to go back to older versions of Ka/Pi.
I created the bugentry 987525 on sourceforge, and we will fix this.

Ulf

[b2bpro]

I've been using KO/PI 1.7.5 on my 860.  What is the difference between that and KDE/PIM 1.9.2 ?

Are these different programs or different versions of the same program?

If different - what are the main differences?

[zautrix]

I've been using KO/PI 1.7.5 on my 860.  What is the difference between that and KDE/PIM 1.9.2 ?

Are these different programs or different versions of the same program?

If different - what are the main differences?

KDE/PIM 1.9.2 = KA/Pi (KAddressbook) + KO/Pi + OM/Pi (Opiemail).

With integrated access from KO/Pi and KA/Pi to OM/Pi  and with access from KO/Pi to KA/Pi addresses.
KO/Pi 1.9.2 is KO/PI 1.7.5 with some enhancements/bugfixes.


z.

[Cyril92]

A question for you zautrix : I tried to import an ics file of French (?!) holidays in KO/Pi (1.7.5): I was said that importation failed (structure pb) : Is it possible to import such a file  : what are the restrictions on structure ?

[ulf1]

Hello all Ka/Pi and KAddressbook users,

The "other" phonenumber problem will be fixed within 1.9.3.

But let me explain shortly what it is all about the formats we are using currently with Ka/Pi. If you are confused, skip the following, or open your std.vcf file in a texteditor and try to verify my writing with help of the content of the file.

1) The changes between 1.9.0 and 1.9.1 in Ka/Pi were probably the result of a change in the code we made in the vcard parser in order to be more complient with the current KDE implementation.

2) In general there are two different releases of the vcard spec. v2.1 and v3.0

Both specs support the following phone formats:

TEL;PREF;WORK;MSG;FAX:+1-800-555-1234
(where the parameter values pref, work, msg, fax are caseinsensitive)
or
TEL;TYPE=PREF;TYEP=WORK;TYPE=MSG;TYPE=FAX:+1-800-555-1234
(where the parameter values pref, work, msg, fax are caseinsensitive)


The problem with the KDE implementation in general is that the parser for vcards of version 2.1 recognized only uppercase parameter values, and for vcards of version 3.0 only lowercase parameter values. This is what I fixed in the upcoming version. The parser will check for the parameter values in a caseinsensitive way.

The parsers are also very picky about the format.
They do not allow the first format (TEL;PREF;WORK;MSG;FAX:+1-800-555-1234)
at all. If you have to import or to open an external vcf file, make sure it does not include the above format for phonenumbers.

thanks,
Ulf

[Alwin]

holy shit.

well, I'll never understand why guys splitting programmers resources in this way.

There are reasons why opie-mail written by me is integrated into OPIE itself. This is one point. But the next and bigger point: You wrote that you did some enhancements to it. Which? Why? Why not giving back to the authors of opie-mail (eg, me) what you did? Why do you just participating on MY job but not giving back something?

Then some others, you broke the licence some points:
1. you put openssl as binary into your cvs. Read the OPENSSL licence carefully - you make a link to the sources.
2. You don't have any licence model - but opie-mail is GPL. It means - you must put every software depending on it under GPL, too! Do it or I'll get real angry.
3. You don't have any changelog about differences to opie-mail - read the GPL and the licence.
4. You must put sources at the same place like the binary - read the GPL again. Not CVS, but generate a source-archiv and put it at the same place the binary resides.

May be, that it would a ... nice idea having some mailclients not depending on opie. but opiemail is the mailer of the OPIE system. And as it is written under GPL you have to respect something. And not depending on GPL you should respect that it would be nice when you inform the developers of a software that you'll reuse this software and cancel some of their ideas, read the GPL about what it says about splitting software and inform about the base software - i didn't found anything in your documentation about opie-mail. This isn't a wish, it is a must be of the GPL.

Alwin
a little bit sicked.

[elvis]

well, I'll never understand why guys splitting programmers resources in this way.

People do this for a hobby. It isn't a job. If you want concentrated programmer resources, hire people. Don't whine and complain they do whatever they feel like doing.

Then some others, you broke the licence some points:
4. You must put sources at the same place like the binary - read the GPL again. Not CVS, but generate a source-archiv and put it at the same place the binary resides.

The GPL doesn't require you to put anything online. In fact, strictly speaking it only requires you to make the source available on request. It doesn't say you have to put it online or even in the same distribution as the binary.

Anyways, why are you Opie guys always so angry and pissed off at everyone else?

[zautrix]

holy shit.

well, I'll never understand why guys splitting programmers resources in this way.

There are reasons why opie-mail written by me is integrated into OPIE itself. This is one point. But the next and bigger point: You wrote that you did some enhancements to it. Which? Why? Why not giving back to the authors of opie-mail (eg, me) what you did? Why do you just participating on MY job but not giving back something?

I am sorry about that you did get no information.

I wrote on 5th of July a mail to opie-devel and wrote, what I did and where the modifications are available and that I hope, that I can merge my enhancements back.

There was no "about" dialog in Opiemail, such that I did not know, who was the developer.

Then some others, you broke the licence some points:
1. you put openssl as binary into your cvs. Read the OPENSSL licence carefully - you make a link to the sources.

I removed the binaries there.

2. You don't have any licence model - but opie-mail is GPL. It means - you must put every software depending on it under GPL, too! Do it or I'll get real angry.

I removed no licence message or about dialog in OpieMail.
There was none.
I did not change ANY headers of the sources.


So, please tell me, what to do?

3. You don't have any changelog about differences to opie-mail - read the GPL and the licence.

Ok, I will do it.

4. You must put sources at the same place like the binary - read the GPL again. Not CVS, but generate a source-archiv and put it at the same place the binary resides.

That was the case for version 1.9.3a-
But I removed the Opiemail binaries from the release files of version 1.9.3a and 1.9.2.

May be, that it would a ... nice idea having some mailclients not depending on opie. but opiemail is the mailer of the OPIE system. And as it is written under GPL you have to respect something. And not depending on GPL you should respect that it would be nice when you inform the developers of a software that you'll reuse this software and cancel some of their ideas, read the GPL about what it says about splitting software and inform about the base software - i didn't found anything in your documentation about opie-mail. This isn't a wish, it is a must be of the GPL.

As I wrote, I wrote an email to opie-devel already some days ago.

z.

[Alwin]

I removed no licence message or about dialog in OpieMail.
There was none.
I did not change ANY headers of the sources.

As opie-mail is part of opie which is under GPL it is under GPL, too.
there is a licence file within the opie source tree (LICENCE.GPL).

Put your stuff depending on OPIE software under GPL, too.

As I wrote, I wrote an email to opie-devel already some days ago.

Ok, then I had not seen it. My failure.

To the other guys (and you, too):
Well, I had worked 5 month 4 hours every day on opiemail. I had wished, that someone will help. I know there are a lot of bugs must getting fixed. Thats why I'll never understand that guys using my work aren't able to send patches, fixes and so on back. At this moment I'm feeling real sicked. That is the point I can not understand why resources are splitted that way.

And it is a job. I'll make it on goodwill, of course, but it is a job. And someone using it in them own projects is able to send back something. Than it is shared development in the idea of an open community. But taking it and not sending back something to the origin is participating. Nothing else. The hint that kmicromail is based on opie-mail (not just the ideas, most code is from opiemail) I had found just on this thread. But when I reuse software from others - I'll put a link to that software direct into my documentation. The gpl request such - and I think it is a must be not depending on gpl that I tell who has made the base. So like I tell that opiemail (and kmicromail, too) is using libetpan. Did you gave feedback back to the etpan-authors?

Once again - may be there are reasons for a mail client using the design of opie-mail but not using opie. It isn't a problem. The problem is in which way it was done. Our resources aren't the best. So I think it should be self-evident that someone using MY resources and spare time work send back fixes, patches, ideas and so on.

btw.: removing opie support is meanwhile the same like loosing some nice features. But this isn't real my problem.

Alwin

[zautrix]

I removed no licence message or about dialog in OpieMail.
There was none.
I did not change ANY headers of the sources.

As opie-mail is part of opie which is under GPL it is under GPL, too.
there is a licence file within the opie source tree (LICENCE.GPL).

Put your stuff depending on OPIE software under GPL, too.

As KDE-Pim/Pi is under GPL and K-OPieMail is part of KDE-Pim/Pi,
K-OPieMail is under GPL, too.
There s a licence file within the  KDE-Pim/Pi source tree (copying.txt).

As I wrote, I wrote an email to opie-devel already some days ago.

Ok, then I had not seen it. My failure.

To the other guys (and you, too):
Well, I had worked 5 month 4 hours every day on opiemail. I had wished, that someone will help. I know there are a lot of bugs must getting fixed. Thats why I'll never understand that guys using my work aren't able to send patches, fixes and so on back. At this moment I'm feeling real sicked. That is the point I can not understand why resources are splitted that way.

And it is a job. I'll make it on goodwill, of course, but it is a job. And someone using it in them own projects is able to send back something. Than it is shared development in the idea of an open community. But taking it and not sending back something to the origin is participating. Nothing else. The hint that kmicromail is based on opie-mail (not just the ideas, most code is from opiemail) I had found just on this thread. But when I reuse software from others - I'll put a link to that software direct into my documentation. The gpl request such - and I think it is a must be not depending on gpl that I tell who has made the base. So like I tell that opiemail (and kmicromail, too) is using libetpan. Did you gave feedback back to the etpan-authors?

Once again - may be there are reasons for a mail client using the design of opie-mail but not using opie. It isn't a problem. The problem is in which way it was done. Our resources aren't the best. So I think it should be self-evident that someone using MY resources and spare time work send back fixes, patches, ideas and so on.

btw.: removing opie support is meanwhile the same like loosing some nice features. But this isn't real my problem.

Alwin

I wrote this mail to opie-devel:

Hi!

I have forked the current Opie mail cvs version to use it in my project KDE-Pim/Pi.
(Pi stands for platform independent).

Please let me introduce this project:

The goal is to have a complete PIM and syncing framework available on the Sharp Zaurus, Linux Desktop and Windows.
Independent from the whole KDE framework or other libraries.
For that reason it provides a so called microKDE library, which delivers the needed functionality.

The links are:
http://sourceforge.net/projects/kdepimpi/
www.pi-sync.net

It consists currently of a full functional version of KOrganizer/Pi (KO/Pi) and a just ported version of KAddressbook/Pi (KA/Pi). KA/Pi has still some bugs.

To get an email program connected to KA/Pi and KO/Pi I have taken over the last weekend the source code of Opie mail cvs and integrated it in the microKDE framework.
I removed all dependencies of libopie.

And, that is the reason I am writing to this mailing-list, I added some features I was missing.
This is a (minimize-) splitter and sorting of the mail-header list.
And it will be probably more, which I will add later... in some weeks or so.

All changes are available in the cvs at
http://sourceforge.net/projects/kdepimpi/
modul name: kdepim.

I hope we can find out together, how we can manage it, to get my changes back to Opie.

I)
The first topic is the (minimize-) splitter:

I think, a splitter is very useful and is even more useful on a PDA!
I am using it in KA/Pi and KO/Pi as well.
This splitter is an enhancement of the usual Qt splitter and can be used easily in every Qt programm written in Qt2 or Qt3. (It is renamed and provides its own layout engine). It is an additional class and provides the splitter functionality even to programs, which depend on the reduced  Qt2 lib with the Qt splitter disabled.

May I suggest, that this is used in the OPie framework in all programs, where a splitter makes sense?
It should be easy to add it to the Opie core library.
Check out the code of KDE-Pim/Pi and look for KDGanttMinimizeSplitter.cpp/h and qlayoutengine_p.h.


II)
The second topic are my changes to the UI of Opiemail:
I would suggest, that I let you know about my changes via this list.
E.g. I write something like :
I have made enhancements of "blabla", please check out current cvs at
http://sourceforge.net/projects/kdepimpi/
and look at the files XYZ.



I hope we will find a way, where all can benefit of enhancements I will add to OPiemail.


*****
End of Mail.

Sorry, that I cannot really see your problem, Alwin, with that, what I have done.

z.

[Stubear]

Yes, they were wrong not to have the source on the same page and not to have a copy of the GPL in the CVS tree, but the project is clearly listed as GPLed on the Sourceforge page.

3. You don't have any changelog about differences to opie-mail - read the GPL and the licence.

Actually they don't need a changelog - they just have to state that they changed a file and when it was changed NOT what was changed

2.  You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

    * a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

read the GPL about what it says about splitting software and inform about the base software

The GPL says nothing about them notifying the previous developer in any way, I agree that it is the best thing to do, but there is no obligation to do so.

There is also no obligation under the terms of the GPL for anybody using your work to send you patches, diffs etc. I agree that it would be very poor form not to send patches upstream, but there is nothing in the GPL that forces it

Stu