Configuration of a Khalkhi service’s parameters: check!

Grepped some time to finally add a missing feature to the Khalkhi framework (say [χalχi]): the option to make the parameters of a Khalkhi service configurable. The configuration of three of the four hooks hardcoded in KAddressbook have already got a Khalkhi substitution, only that of the maps is yet to be done, before I can nuke them all from KAddressbook. I just didn’t find a quick’n'dirty solution to merge it with the “Open in Google maps” service for now. Obligatory screenshot:

I only hope that those (who?) working on the config subsystem for KDE4 will add change signals to it. For Khalkhi I just added a DCOP signal from the control module to the Khalkhi manager class which then looks up the service and triggers it to reload it’s config. But I really would expect the config system to do this for me

Khalkhification of KAddressbook

As reported here recently, Khalkhi (say [χalχi]), a framework around persons and services on them, moved in the experimental kdepim branch for KDE 3.5. The obvious first target to make use of it is KAddressbook, and thus it has already been patched in the branch a little.

While the priority is on substituting things without loosing old features, some new ones, besides those gained by the plugins for the framework, are getting in, too. Like seeing the states of a person by emblems in the icon view (screenshot using some random KDE characters ):

Thanks to Khalkhi delivering such an icon for this only a few lines needed to be added. The Kicker applet (old stable version here) uses the same, cmp. e.g.

Another candidate for making use of this is the face display in KMail’s email view (the one in the header to the right). But before I am going to contact the KMail authors about this I need to make sure that Khalkhi will be able to get into the 3.5.7 release at all. These are the things most needed:

• get a KDE4 version into trunk - there is some code in the works, it is even more enhanced than the KDE3 version, but right now stuck in a design problem that needs some thinking
• add configuration of service plugins - some services need to be configurable, see e.g. the configuration of phone call, fax sending and map lookup in KAddressbook. This is the last hurdle to make KAddressbook free of hardcoded services.

Lots to do

Say hi to ხალხი!

Finding a name for a project seems difficult. Especially one for a worldwide audience. With so many of the terms already used/registered as trademarks. And should the name be build from terms semantically connected to the topic of the project or made up out of the blue?

The nice people on the mailinglist kde-promo tried to help, but we could not find one that was really kicking IMHO. Well, after all there are companies specialised in this (see for the creation of the name Kodak or all the car names).

So I followed a recent tradition in the KDE PIM department and grepped a term from some more or less random language/culture located on our beloved planet earth. Even one with a none-latin script, for the fun of it.

ხალხი (say [χalχi]) it is. The Georgian term for people, as in group of persons.

As the english language is the KDE lingua franca, the referencing name may be one of the transciptions, that is Khalkhi.

Having chosen the name, the experimental kdepim branch for KDE 3.5 now got the commit of the former Contacts framework from trunk/playground/pim as the new libkhalkhi.

KAddressbook already got a first patch to make use of Khalkhi, so the time of hard coded property types and services on them might come to an end some time.

Old:

New: