Getting drops to Khalkhi plasmoids going

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.