Wanted: older packages of kdepim-3.5.7 for openSUSE 10.2

They say “Never touch a running system.”. Emphasize on “never”, obviously.
I am loosing quite some hours because I “just” wanted to update the KDE packages on the openSUSE system to the latest package version. To find out that the refreshed KMail ignores my command to fetch from the POP3 servers. Ignores my pledge, too. My anger, even. In offline or online mode it shows a new status symbol with the tooltip “The desktop is offline”. Which is wrong. SMTP works even.

Decided to undo the upgrade. Which is not possible. The older package is gone already, no longer available at the openSUSE servers, there is just the new version 3.5.7.enterprise.0.20070731.694771. I could go back to the 3.5.5 version, which came with the Golden master version of 10.2. I don’t think I want to try that, there isn’t a downgrade script for the settings AFAIK.

Now, does anyone know what to do? Has somebody perhaps a copy of an older package of kdepim-3.5.7 for openSUSE 10.2 she could sent me (the link of)? Is there perhaps a way to make the openSUSE buildservice to give me my personal variant of a package on request?

I might not be alone. I would like to enter the bug with the openSUSE bugzilla, but I got moved to a Novell system, not where I thought to end given this is a project on it’s own?

Advertisements

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.

Look mummy, my first plasmoid!

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.

First steps with KhalkhiĀ plasmoids