Another suggestion, not sure if it is of help though:
You could try to use a vCard file resource instead of a vCard dir. Maybe that would work better for you?

wolfi323 wrote:Another suggestion, not sure if it is of help though:
You could try to use a vCard file resource instead of a vCard dir. Maybe that would work better for you?

Sorry for my late reaction, but I have to do other things also. In fact I do not have enough time to spend on this Kaddressbook problem. Kaddressbook is to me only a mere tool in day to day work, that simply should function. It should not ask for all sorts of attendance when the developers think they should provide a new version.

I am glad with all advice from people that try to help to solve this problem. But I am afraid that I did still not explaiin claer enough the real cause. Thus I will now try to reformulate it not from the vewpoint of the Kaddressbook user, by from the viewpoint of the maintainer of the addressbook itself.

There is an addressbook in the form of a directory with vCard files. This addressbook is made available to several people so they can use it: consult it, change address, add addresses, remove addresses. IMHO, I do not think that that is such a strange application.

The users use the tools/applications they like. As long as that tool is able to use a directory of vCard files as addressbook resource. And again IMHO That is a pretty standard format.

Now one of those users switched to using new Kaddressbook and what happens?
To begin it has the brutality to place a file in that addressbook claiming the he and his instance of Kaddressbook has the sole right to do any changes in that resource. No other Kaddressbook users allowed, let alone users of other addressbook tools/applications.

And this is only a intimidating message in that file, because in practical life, it shows that changes made by that Kaddressbook user are directly put into the resource, thus other users "see" those changes immediatly. But the changes other people make are not synced into the poor Kaddressbook users view of the world. Thus it seems that the Kaddressbook user has (by using Kaddressbook) ruled himself out from using this resource.

While this does not touch the other users of the resource, but only the Kaddressbook user, IMHO Kaddressbook should be repaired and that is why I try to discuss the phenomenon here and on the mailing list.
There is no way that we are going to change the resource to another format (what would of course include the changeover of all other users, including testing of their tools/applications). It is Kaddressbook that stopped supporting this format of resource. It is Kaddressbook that should be repaired, or being banned from usage.

is Kaddressbook that should be repaired, or being banned from usage.

It is a missing feature due to lack of manpower / time / people willing, not an explicit fault (like Kevin's mail explains at the start of the thread).

Yes, I know. And like I also said earlier, I am feeling with those that are frustrated because of the lack of manpower. But we, the users, have to live with the fact that functionality that was there for years, isn't there anymore. That is, what I think dvelopers call, a regression. And I, as dumb end-user, call it something that should be repaired. When you do not like me using the word "repaired", then maybe you like me to say that it is unusable until something is done about this. But I do mean the same.

Did you file a wishlist bug? Developers don't check this thread, also an open bug may attract potentially new contributors willing to fix it.

Not until now. I am told to do this earlier and in fact I am still busy to gather my courage and to find the time. I do not want to spoil such a wish/bug by throwing to much frustration in it. I know that would be counterproductive

I hope my reminder wasn't offensive, as it was not my intention. It was just to point out that (unfortunately) not many developers read the forums and even if no one can fix things *now*, others may in the future as long as this wish is properly recorded somewhere. Many new contributors start by fixing existing bugs.

You were certainly not offensive and I appreciate what drives you to do this: love of the KDE product and being fan of FOSS

That is about the same that urges me to start these discussions and answering to those who bother to take part. It would have been easier to leave KDE-PIM (and KDE) to it's own and search for another solution silently.

Ok, finally posted the bug to the kde bugtracker...

https://bugs.kde.org/show_bug.cgi?id=321343

Much appreciated if you can go there and vote it up!


Jose

It's being worked on:

http://git.reviewboard.kde.org/r/111149/

einar wrote:It's being worked on:

http://git.reviewboard.kde.org/r/111149/

That is applaudable! Thank for this encouraging message.

Good news, KDE PIM 4.11 will have this feature:

http://quickgit.kde.org/?p=kdepim-runti ... 1eb3a5c118

Thanks for reporting back. Eagerly waiting

Hello einar,
I'm very interested in the solution to this topic.
Unfortunately I cannot open your link and wonder in which version it will be implemented.
I currently user Kontact Version 4.8.5 (on Ubuntu-Linux: 3.2.0-30-generic #48-Ubuntu) and experience this same challenge described here.

One other question: I noticed another problem (deleting a contact does not delete the vcard file and reopenin of the directory creates the contact again from the not deleted file), which I submitted as a comment to Bug 320022.
But I wonder if this is the right way to do. Or should I rather report a new bug?

Bug 320022 was never confirmed and still has been worked on, so I wonder what the best way to proceed is.

Best regards
Charly

The issue has been fixed in 4.11 (the one from the parent post of this thread): unfortunately 4.8 is quite old and as far as I know no longer supported upstream.
If you have a separate issue w/vcard files, you should open a new bug (but bear in mind your KDE PIM version, as the issue may be fixed in newer versions without your knowledge).