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:

Simple Drop menu of KhalkhiΒ 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.

Advertisements

7 thoughts on “Getting drops to Khalkhi plasmoids going

  1. This is excellent! I wanted to let you know that better English would be “send…via E-mail” rather than “per.” The word “per” can mean “by way of,” but is more often used to mean “according to.” The word “via” always means “by way of.” Just my suggestion. Thanks.

  2. Two things:

    1. Use instead of

    since stands for preformatted text (e.g. indented code) and

    is meant for -well- blocks of quotes ;-)

    2. What about grouping the menu in your screenshot:
    Send Link addresses
    - per Email
    - to address FOO
    - ...
    - per IM
    - to contact BAR
    - ...
    β€” ...
    Send File
    - per Email
    - to address FOO
    - ...
    - per IM
    - to contact BAR
    - ...
    - ...
    ...

  3. Sorry, my previous comment got messsed up, here it’s again:

    Two things:

    1. Use <pre><code> instead of <blockquote><code> since <pre> stands for preformatted text (e.g. indented code) and <blockquote> is meant for -well- blocks of quotes πŸ˜‰

    2. What about grouping the menu in your screenshot:

    Send Link addresses
    – per Email
    – to address FOO
    – …
    – per IM
    – to contact BAR
    – …
    β€” …
    Send File
    – per Email
    – to address FOO
    – …
    – per IM
    – to contact BAR
    – …
    – …

  4. Hi!!!

    Wonderful, thank you πŸ˜‰

    about the questions asked right now, I would automate it. Just use the best way first (eg if someone is on the local network and you’ve identified him with zeroconf, just send the files using whatever that supports, samba or something; then IM or P2P, then email). I guess the ‘just’ part here is difficult, of course πŸ˜‰

    But you seem to be good at handling difficult stuff, so I look forward to your next blog πŸ˜€

  5. Gotta agree with Milian, the menu needs simplifying.

    Also, I suggest the word ‘by’ instead of ‘per’ in the menu is probably simpler for most people to parse.

  6. @Louis and Henry: changed “per” to “by”, thanks.

    @Milian: <pre> works better, thanks. Yes, the menu needs quite some structuring, I didn’t even show the normal one with actions without data (which includes services like “Copy address to clipboard” or “Open homepage”), it is a mess with dozens of services and for persons with a lot of properties. I am hoping to solve this with an approach similar to the application menu (KMenu) one, based on tags. But this is still at the draft stage.

    @Jos: Yes, it’s a typical `just’ part πŸ˜‰ But such a `I’m lucky’ default service ranking option should be doable, I think (is at draft stage, too). But my next blog will hopefully be rather about loading, editing and storing of Khalkhi entities, so I am no longer too shy to withhold things from at least playground in KDE’s repository!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s