In my last blog entry I said:

Adding the Khalkhi services and all the other goodies as known from the Khalkhi applet for Kicker of KDE 3 is left for the next time reserved for hacking, even if it is simple code (the purpose of the Khalkhi framework).

And jospoortvliet in the comments asked:

Now ensure that if I drop a file on a face, it gets transferred to that person, ok?

Does this look like simple code for ensuring jos’ wish? It took me more time to fix the Plasma libs to not burn away some of the drop events meant for plasmoids, actually

((Is there no better way to embed code examples then <blockquote><code>?))

Update:Tried <pre> and things looks better.

void KhalkhiPlasmoid::dragEnterEvent( QGraphicsSceneDragDropEvent *event )
{
    if( !mMenuFiller )
        mMenuFiller = new Khalkhi::EntityDataActionServicesMenuFiller();

    mMenuFiller->setEntity( mEntity );
    mMenuFiller->setData( event->mimeData() );

    event->setAccepted( mMenuFiller->serviceAvailableForData() );
}

void KhalkhiPlasmoid::dragMoveEvent( QGraphicsSceneDragDropEvent *event )
{
    mMenuFiller->setData( event->mimeData() );

    event->setAccepted( mMenuFiller->serviceAvailableForData() );
}

void KhalkhiPlasmoid::dragLeaveEvent( QGraphicsSceneDragDropEvent *event )
{
    delete mMenuFiller;
    mMenuFiller = 0;
}

void KhalkhiPlasmoid::dropEvent( QGraphicsSceneDragDropEvent *event )
{
    mMenuFiller->setData( event->mimeData() );

    if( mMenuFiller->serviceAvailableForData() )
    {
        event->accept();

        QMenu menu;
        mMenuFiller->fillMenu( &menu, true );
        menu.exec( event->screenPos() );
    }

    delete mMenuFiller;
    mMenuFiller = 0;
}

What I don’t like is that event->mimeData() is expected to not be valid outside the event handlers. And QMimeData objects seem to be uncopyable. I don’t like it because Khalkhi services are active and might have a different state depending on the client and it’s properties they are offering their service to. So if a system a service uses changes its state the service checks all clients whether the individual availability is lost, which might also depend on the drop data, which might just be a dangling pointer, doh.
Example: the Open-homepage-in-browser service works only for intranet homepage addresses if the connection to the internet got lost. So all clients requesting services for homepage urls are queried if the url is an internet one and in case get informed that the service is unavailable now, so our menufiller, which is a client, can grey out the option “Open homepage in browser” (which it does). No data here involved, but you see the pattern.

For now this is a problem left to solve

So with the two data action service plugins currently installed I get this menu if I drop a bundle of files onto Konqui’s plasmoid:

It’s the same menu you know from the Khalkhi services for KDE 3 (as seen in the Kicker applet or the cards server). After all the algorithms are the same, too

There is some work by the Plasma people to add action overlays to the corners of icons. I would like to use them, but then there are only four corners and that does not scale with the unlimited amounts of property types and service plugins… So far I will stay with the plain old list menu here and rather focus now on the status services. After all Khalkhi for KDE4 still has some way to go before it is time to fiddle with some usage details unrelated to the framework.

Oh those little mistypes. Searched three hours for a bug due to adding one “=” too many when calling the subclass function in a operator=() function. There cannot be enough unit tests, obviously. But those need to be tested, too. Sigh. Or I need better languages.

Khalkhi for KDE 4 is still pretty a lot like vapourware, but some code is already working again, after I redesigned things a little again as I missed 4.0 anyway.

To motivate myself I hacked things through the vertical layers and did one more use case, a little plasmoid showing individual Khalkhi entities. Now, those three hours later hunting this *** one letter bug, it finally works by at least showing the picture of the entity. Adding the Khalkhi services and all the other goodies as known from the Khalkhi applet for Kicker of KDE 3 is left for the next time reserved for hacking, even if it is simple code (the purpose of the Khalkhi framework). I definitely need to go to bed now, as some 4 hours later I am scheduled to get up again, silly me… At least it is only travelling waiting for me, but still.

It all looked so promising and prospering, but then real life came in between and has stalled my plans with Khalkhi (say [χalχi]), both for KDE 3.5.7 and KDE 4. So I had to cancel all coding and the talk at aKademy and feel sad for this. Oh life, you suck. A little.

The last two weeks I managed to grep some time and tried to keep up with KDE development again, doing some little things. Like polishing the header includes of the KHexEdit lib and kpart, after that renaming the part to Okteta. Played a little with the design of the Okteta program still developed out of KDE’s repository. And today declared the release candidates from march of Khalkhi for KDE 3 to be final, as there were no bug reports in the meantime. Next will be to improve the API documentation of the KHexEdit interfaces in kdelibs which is pretty much hidden in the docs right now.

Really little things, but better than none No idea, how often I will be able to do this, though.

Go and get the tarballs of Khalkhi at KDE-Apps.org:

• Khalkhi framework 0.2.2
• Khalkhi applet for Kicker 0.5.3
• Khalkhi cards server 0.2.2

I am still interested in how the event notification system of the applet works for you. Thanks for any report!

Now that the code of the Khalkhi (say [χalχi]) framework for KDE 3 has settled again and the Kicker applet and cards server are ported to it, it is time for another release. Missing the time to organize a proper one currently, for now the code is just declared to be a release candidate. But you are still welcome to go and test it now!

I just uploaded some tarballs for your convenience to KDE-Apps.org:

• Khalkhi framework 0.2.2 rc1
• Khalkhi applet for Kicker 0.5.3 rc1
• Khalkhi cards server 0.2.2 rc1

I am especially interested in how the event notification system works for you. Thanks for any report!

Let’s just add this little feature, and then… oh, not so easy, wait a moment. Hm, some more moments…
Got hit by that this week. But I really wanted this feature to be done, because I needed it. And so I just had to give in.

But now it’s almost done, and now one can control how status changes are reported by the Khalkhi applet. I could not reuse the KNotify framework, as it’s assumption are not met. With Khalkhi each set of events is not defined by a whole program, but by the corresponding status service plugin, e.g. the one for IM presence, or the one for number of unread emails, the one for last.fm, or whatever. And the possible actions are not the same, at least there is no taskbar entry to flash, rather icons in the Khalkhi applet or in KAddressbook. Tricky is also that there isn’t a centralized Khalkhi demon for now, so all the programs using Khalkhi would all e.g. play the same notification sound. Because of this the events are currently just handled by the applet and nothing else.

The GUI for configuring all that is imitating that of the KNotify control, so it reuses at least the workflow pattern:

One can even control the settings per addressbook entry, so for aunt Lilly a new email triggers a sound, while it doesn’t for all others. But I am not sure how to do a good configuration GUI for this, so for now this is left as hidden feature, until I find some time. There is so much else to do… Like making the panel button really flash, finally.

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

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

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: