mhl wrote:1. You have to define new the correct Akonadi-Ressources you will need, e.g. the addressbook component. -> start any of these akonadi scripts but not the "console". Funny why the console is a developers tool and funny that especially this step, to tell you which program to use, is so difficult.

I am afraid I don't understand any of this. To use KAddressBook you run KAddressBook or use the address book module of Kontact.

mhl wrote:2. You have to tell the system (=KDE) to use these ressources. -> KDE control center -> ressources -> add the ressources you will need.

This is only if application using the old KResource framework should be accessing the data in Akonadi.
Which applications did you need this for?

mhl wrote:E.g. in the situation of kaddressbook you define new akonadi-addressbooks (why are they "new"?) and convert your old addressbooks into new "akonadi-ones", a typical step for the wizard!!! Very nice step because you as a user will have to know what the technical type of your old addressbook is and where it is located - things that users normally are not interested in!

This is done automatically by the KResource migrator tool. Unless the user has deactivated it, of course.

mhl wrote:Then you can tell KDE to use these ressources.

In case you want non Akonadi programs to go through Akonadi and not access the files directly.

mhl wrote:In this step, e.g. you can define that kmail can look in either the old addressbook file and the new one.

One doesn't have to create a new address book files, there are Akonadi resource which can work on the same files KResource using applications can.
E.g. using a VCard file resource to work on KDE's standard address book file.

After all Akonadi is just a proxy between the data source (in this case the file) and the application.

I think the KAddressBook migrator might convert the address book file to a directory of address book entries. In which case I would assume it creates a KResource plugin for that directory as well.

Cheers,
_

I use KDE4 and I like it. For me most of the stuff works. But I gave up using KMail & co. It's not exactly unusable but Thunderbird (which is also annoying sometimes) with addons and plugins works better for me.
Perhaps you should give it a try. Fortunately one is not tied to use KDE-programs-only.
It may be regrettable but it is perhaps not realistic to expect that KDE is able to provide always the best available solution.

Best

B.

anda_skoa wrote:

mhl wrote:E.g. in the situation of kaddressbook you define new akonadi-addressbooks (why are they "new"?) and convert your old addressbooks into new "akonadi-ones", a typical step for the wizard!!! Very nice step because you as a user will have to know what the technical type of your old addressbook is and where it is located - things that users normally are not interested in!

This is done automatically by the KResource migrator tool. Unless the user has deactivated it, of course.

Sorry, Anda but this is wrong! It just does not work!

mhl wrote:In this step, e.g. you can define that kmail can look in either the old addressbook file and the new one.

anda_skoa wrote:One doesn't have to create a new address book files, there are Akonadi resource which can work on the same files KResource using applications can.
E.g. using a VCard file resource to work on KDE's standard address book file.
_

Ok, this is "wrong" either! A conversion of old addressbooks to the new one would work for sure!

But, as I already explained before the new "Akonadi" addressbook is stripped down in so many ways that you annot simply convert it! Converting will result in loss of data!

1. There are no categories in the new addressbook

2. there are no filters in the new adressbook

3. Distribution list? Yes the new addrressbook has this functionality but

a. old DLIs will not be converted
b. there is no drag and drop or cut-and-paste functionality to quickly move old to new.


4. Some adddress fields are eliminated!

Conclusion: This is the awful reality: As functionality was stripped down and there is no working conversion concept the operation will lead to a dying patient! (hopefully this can be said in English)

This scenario shows exactly what never should have happened! This must happen if you do not ask users before releasing a new component.

Sorry but this is not userfriendly! Martin

Thank you MHL. I would also like to add that inside the distribution list, you have to click from one field (name) to the other (address). Neither tab nor enter works. Also, cannot select names from your address book, nor is there fill-in.

My biggest fear is the devs try and do to Amarok and Kopete what they did to KMAIL. There was nothing wrong with the KResource back end to KMail. The new features, while cool in theory, do not work and are system resource hogs.

There seems to be something strange in the way you are adding to your distribution lists. If you start to type in a name you should find all partial matches offered. You simple move your mouse onto the one you require and it is added.

@Martin: You do not need categories, or any other information. All you are doing is creating a pointer to an existing record. If you are trying to add records that do not already exist you are bound to fail - it makes no sense at all. The reality is that it works well, but you have to understand what it is doing, and at the moment you clearly have some very wrong ideas.

Anew;

Thank you for your reply, but unfortunately, it is not working that way. To test whether it was my installation I tried it on a VM as well, with the same results. Fill-in does not work, I cannot tab to the second field, nad it has to start up the MySQL instance for Akonadi every time I open my address book.

I noticed there is not a program for Kontact/KMail under the KDE usability projects. How would I go about starting one?

Hey Annew

annew wrote:@Martin: You do not need categories, or any other information. All you are doing is creating a pointer to an existing record. If you are trying to add records that do not already exist you are bound to fail - it makes no sense at all. The reality is that it works well, but you have to understand what it is doing, and at the moment you clearly have some very wrong ideas.

Nice to hear about wrong ideas. Most of my ideas come out of using KDE PIM for about 10 years and of having been involved in IT projects for more than 20 years!

If there is a solution, the better! That is what I am talking about: How to make the users understand the concept and give them tools to make it work. Currently this does not work in KDE PIM.

Let us see: Please look at the following scenario:

a) About 350 contacts in old addressbook, 20 specific contacts for one project
b) these 20 are "categorized"
c) using filters to get a view
d) using export options to export the addresses
e) using Open Office DB features to create serial letters / mailings

Question 1: How to move these contacts together with 100 others to the new addressbook? Not to forget: without loosing any data! -> category setting is data! For sure there must be a way to move the addresses, because the old address book is "read-only" after switching to the new one

Question 2: Alternative way to filter these contacts plus the rest of the scenario above

If you can answer how to handle this without programming a Linux script or something like that I would be very glad - thank you!

Martin

mhl wrote:

anda_skoa wrote:

mhl wrote:E.g. in the situation of kaddressbook you define new akonadi-addressbooks (why are they "new"?) and convert your old addressbooks into new "akonadi-ones", a typical step for the wizard!!! Very nice step because you as a user will have to know what the technical type of your old addressbook is and where it is located - things that users normally are not interested in!

This is done automatically by the KResource migrator tool. Unless the user has deactivated it, of course.

Sorry, Anda but this is wrong! It just does not work!

In which sense does it not work? Is is not being run? Is it not creating the resources? Is it not configuring the resources?

mhl wrote:But, as I already explained before the new "Akonadi" addressbook is stripped down in so many ways that you annot simply convert it! Converting will result in loss of data!

Interesting.
As far as I know it is using the same code for reading/writing vcard data.
What kind of data source are we talking about? vcard file? directory of vcard files?

Can you specify an example of the data loss you've experienced?

mhl wrote:3. Distribution list? Yes the new addrressbook has this functionality but

a. old DLIs will not be converted

Sounds like a bug to me. Did anyone report it?

Cheers,
_

Hi Anda!

anda_skoa wrote:In which sense does it not work? Is is not being run? Is it not creating the resources? Is it not configuring the resources?

After the conversion everything should work as before. But this is not the case. Functionality is gone and Akonadi will make KDEPIM instable!

mhl wrote:But, as I already explained before the new "Akonadi" addressbook is stripped down in so many ways that you annot simply convert it! Converting will result in loss of data!

Interesting.
As far as I know it is using the same code for reading/writing vcard data.
What kind of data source are we talking about? vcard file? directory of vcard files?

Can you specify an example of the data loss you've experienced?

Categories are gone! DLIs are gone! Fields are gone! All of these are data in the sense of an address database. (See my other posting)

mhl wrote:3. Distribution list? Yes the new addrressbook has this functionality but

a. old DLIs will not be converted

Sounds like a bug to me. Did anyone report it?

Yes, interesting aspect! I not even know if I myself reported this! But anyway who will report this as a bug when beeing teached that loosing functionality was planned with the switch to the new addressbook?

Regards, Martin

mhl wrote:Hi Anda!

anda_skoa wrote:In which sense does it not work? Is is not being run? Is it not creating the resources? Is it not configuring the resources?

After the conversion everything should work as before. But this is not the case. Functionality is gone and Akonadi will make KDEPIM instable!

Maybe a misunderstanding on my part, I had the impression that the migrator did not or wrongly migrate the data.

mhl wrote:

mhl wrote:But, as I already explained before the new "Akonadi" addressbook is stripped down in so many ways that you annot simply convert it! Converting will result in loss of data!

Interesting.
As far as I know it is using the same code for reading/writing vcard data.
What kind of data source are we talking about? vcard file? directory of vcard files?

Can you specify an example of the data loss you've experienced?

Categories are gone! DLIs are gone! Fields are gone! All of these are data in the sense of an address database. (See my other posting)

Strange. I knew that some parts of the data is currently not visible in the user interface, but it is new to me that it got removed from the actual storage.
Especially when reusing the same file as the read/write code is identical.

Would it be possible for you to double check that it is not just not displayed but really not stored anymore?

mhl wrote:

mhl wrote:3. Distribution list? Yes the new addrressbook has this functionality but

a. old DLIs will not be converted

Sounds like a bug to me. Did anyone report it?

Yes, interesting aspect! I not even know if I myself reported this! But anyway who will report this as a bug when beeing teached that loosing functionality was planned with the switch to the new addressbook?

Temporary unavailability of certain UI features due to code freeze constrains is a totally different thing than not migrating data correctly.

The new address book application is not yet capable of providing access to all data, but it should not remove anything as the internal data structures stayed untouched.

Cheers,
_

I've rarely read so much FUD in one thread. For a start, the KAddressBook migration does not destroy data. This is easily checked by opening any record from ~/.local/share/contacts in a text editor.

I can see my old categories, but this is a fairly recent development.

Using filters to get a view - tell us what you are trying to achieve and we'll try to help you.

What problems are you seeing in exporting records? You have to give details if you want help.

OpenOffice database - OOo does things quite differently from ordinary databases so you will have to ask them. I have found them helpful in the past.

Every time someone says 'it doesn't work' they just waste bandwidth. Please understand that without specific details help is impossible.

@Tuxman3458: You should not be aware of MySQL at all, so something is very wrong with your install. The fact that it doesn't work in two instances on your computer merely shows that they are experiencing the same problem. The fact is that it works perfectly, not only for me, but for many others. As I explained, you should not need to tab to the second field. That is the wrong way to add the record.

You might find some answers by reading the relevant pages on UserBase, start with http://userbase.kde.org/Akonadi_and_AddressBook - but also http://userbase.kde.org/Akonadi_4.4/Troubleshooting and the pages linked from there.

Unfortunately not! Now virtuoso blocks KMail. Last time it was Akonadi and so on. This is what makes me believe, there is a lack of coordination. The KDE team has a problem in this area and in quality management. Again the question: How can we improve this situation?

I'm using KDE but honestly I'm not using the KDE-PIM programs. I tried them serveral times. In the end I found them to be presemtöy much inferior to what I can get from recent versions of Thunderbird/Lightning (together with several plugins).
I'm also not using the KDE office suite. There are also (much much) better alternatives. And if you want to do serious work with it, it will betray you.
Probably one should not be impatient. The situation may and will improve in the future. Please note that I'm not complaining. But I would appreciate if the KDE folks would be a bit more realistic about their achievements. I'm not saying that their achievements are rather modest. But at the end of the day, it has to admitted that in many cases they lag behind of what is offered by commercial software. (If you don't believe me, just take the example of pdf related software).
The KDE desktop works relatively smooth and that's ok. But beyond that KDE is offering is just alpha software for toying, for hunting bugs and for getting puzzled about missing functionality. Nothing that is really rocking. Still better than Gnome (my personal opinion). But altogether much inferior to what is available on Windows and Apple. It's actually only ideological reasons (free software) that make me use it.
Sorry folks, but this once had to be said.
Kriss

The only thing that we want back is to organise our contacts again. We dont ask for a hi-tech revolution but one simple thing that have all the other email client....