Fine grained access control to class methods?

One year ago I showed a first picture of Okteta, a successor to KHexEdit in-work. Time to show a new one, here it is:

Well, no big changes in the UI, except for the style and the color. Still looking similar to KHexEdit (which it shall in the default settings, to easen moving over).

But under the hood things are developing. Created a framework called Kakao which serves as a template for programs, so one just needs to plug in factories for documents, views, and tools to get a full featured program for your $datamodel. Currently I am laying grounds for the concept of model synchronizers. Something I have been looking for since ages, really, how can our allday-programs just be without it? Right now I am trying to map the action “Save as…” to it, meaning something like switching the synchronizer, if the remote data model is different (e.g. PNG->JPG for stream formats), or only the location/url. Why is there no option with today’s “Save as…” actions to remove the old remote data model (like old file) BTW? Sometimes one just wants to move/rename a file or recode it, while working on it. Is this workflow so unusual?

An interesting problem is:
How can one limit access to a subset of methods of a class for only certain other classes in C++? I can define friend class Class; for access to all protected methods. But I would like to declare different friends for different subsets of the protected methods. So only the synchronizer classes could call void setRemoteHasChanges( bool hasChanges ); or similar for document subclasses, not some nasty plugin doing dirty things. I imagine I could play some tricks with subclassing abstract classes, but those methods don’t need to be virtual. Is there a better way?

No time to take part in things like Krush Day, me bad boy, I am just too fascinated by the possibilities I see coming with the Kakao framework!

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?

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.

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.

Gears of Liberty

Those gearheads looked so familiar, I tried hard to remember where I first had seen one of them.

Then I remembered:

How to script KWord/Openwriter to fill address lines in a letter?

I may miss the right terms to query Google, so perhaps you can help me. I want to write a script which starts/ensures whatever wordprocessor, creates a new document from a given $TEMPLATE, fills the address lines for a given $CONTACT, and sets the cursor right behind the “Dear Sir/Madam,”. $CONTACT may be the UID from KABC or just some already preformatted address string.

Is this possible with Openwriter or, better, KWord? Are there already similar examples?

Thanks, if only for the right query terms 🙂

Last release of Khalkhi?

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! 🙂

First release candidate of Khalkhi framework 0.2.2

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! 🙂

“Your aunt is now…”

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.

E(xiting) environments

KDE developers seem currently all focused on getting KDE 4 into shape. So far it looks very promising, now that also Plasma is changing it’s state from vapour to, uhm, even plasma 😛 It’s really time for me to return to KDE 4 development, given my ambitious plans with Khalkhi for it. Attending the Decibel hackathon in two weeks might help me 🙂

The rest of the FLOSS desktop planets show activities, too. The GNOME, XFCE, and ROX planets are blooming and enhancing.

But since my first steps with Linux there are, besides KDE, two other projects I once in a while have a look at: Enlightenment and GNUstep. While the 0.17 version of enlightenment is really taking it’s time, the seldom reports on the state and the activities make one wanting to have it here and now. Just saw the video of Carsten Haitzler’s talk at linux.conf.au from two month ago. Forward to the end, and look at the demo. Cool, or?

GNUStep seems to develop even more slowly, but still. This is sad IMHO, as OpenStep/NextStep really had some great ideas and architectures. More than ten years ago. Things have not really enhanced since then on the desktop IMHO. At least, there is now a new and fresh plant on the GNUStep planet: Étoilé. At FOSDEM 2007 they released a first(?) Live CD, I did not test, only looked at the screenshots. But I wish them much success. Especially after browsing their very interesting wiki with all their plans and ideas. Lots to think about.