Category Archives: coding

Our holiday seems long time ago already. We had a great week, relaxed a lot, read a lot and did some nice walking and cycling tours. Short impression. However that was two weeks ago already and between now and then the academic year of our university has started and I’ve had the first lectures already. One of the courses is new and seems pretty cool. It’s called advanced webtechnologies and it’s about modelling the web, the properties of such models. It’s also about pageranking algorithms so it promisses at lot of fun stuff. Cool lectures have one disadvantage, they take time. Reading the material for the lectures takes even more time and the labcourses will take a lot of time also…. *sigh*. But in the spare time that remains I’m still hacking on kpilot. Currently I do a dull job. Mostly because I don’t want to think much when working on it and besides that after 8 weeks or so coding on the base conduit I don’t want to see that thing anymore for a while. Sorry vanRijn =:). I’m cleaning up the code in kpilot/kpilot. It contains a lot of Qt3/KDE3 support stuff which I want to get out. This mostly means moving UI stuff into UI files. If that was done earlier a lot of porting stuff would be a lot easier I think. Most of this is easy and well documented in the Qt documentation. However I now have a small annoyance which I can’t solve with a QTableWidget. This is what I get when I run the program:

However in Designer I’ve set the table headers to something different.

As I did not yet receive the book of Johan Thelin I won, I hoped someone could give some hints on this. Continue reading →

That revision is actually the finishing touch for my GSoC project. It contains the last work that was needed to get syncing of categories done. Now we have a fairly complete base framework and a working conduit for gnukeyring. At least for the version 4 databaseformat. I’ll not go in further detail here because vanRijn did that quite well in the last commit-digest. There are a couple of things left to wrap up the project, like the final evaluation and uploading the code to the google website.

Now the project has finished I really like to thank Google for making this possible. First of all it was a great way to get deeply involved in open source. Although I already was contributing to KPilot, this project gave me much more insight in the code then I ever had before. Working on open source isn’t be about the money in the first place for me. However, it was really great that we got paid for this. Otherwise I had too look for some other job (which most probably would be some dull cleaning job or so) because I really need to pay my study and the rental of our house and so.

Of course I also want to thank Jason “vanRijn” Kasper. He has been my mentor for the project and I only can say that he did a great job. It was him who insisted to have a long design period which was one of the best moves we did together in the project I think. Besides his technical skills and knowledges of the KPilot source he was always around in irc to cheer me up, or to use his whip to make me work harder. vanRijn thanks a lot, it was a real pleasure to work with you! I hope that much fruitfull years of collaboration will follow.

Last but not least I’d like to thank the KDE developers community. You’re a bunch of very helpfull guys and it was always a pleasure to hang around in #kde4-devel.

So what are the plans now? First of all I’ll take a week holiday next week. I’ll go with my wife to campground at Mechelen. When I’m back my study will start so I won’t be as active as I was this summer. But I’ll keep hanging around and keep continuing work on kpilot as much as I can.

Continue reading →

Yesterday was the big day. After a package update of my Gentoo system, which took way too long anyway, libexpat seemed to get an update also. What’s the deal? I see you think. Well that there where around 35 packages which linked to it and needed to get recompiled. *Sigh* and that after hours of waiting to get the update finished. So I started revdep-rebuild and wanted to do some development underwhile. Not possible! about every app I needed was linked to that lib so i had to wait while my system was completly unusable for that time.

Ok that was it. I was tired of all that waiting and besides that I needed a new harddrive anyway (had 40G, now 160G weee!). I figured out that this might be a good moment to try another distro. After some threads of vanRijn I decided to go for openSuse. Because I don’t have an dvd burner I did the network-install-dance. This went quite ok except that http sources didn’t work for me. After waiting another half a day I had a ready-to-use opensuse system. With some extra nice goodies working out of the box which I coudn’t or didn’t try to install on Gentoo.

Drifting away from Gentoo made me think about it. It came to me that I use Gentoo as long as I use linux. I started using it when I started my bachelor degree in software engineering, 5 years ago now. It has some very nice qualtities. For example the docs are outstanding for starting Linux users. There’s a lot of documentation on their official website and besides that there is a wiki which contains another bunch of usefull information. Also the user base is quite helpfull in the forums. I also liked the possibilities of useflags and splitted kde packages. Install only what I need and also install only the parts of the installed software you need. Quite cool, I’m gonna miss that. However waiting hours to get your system updates is just not what one wants (at least I don’t want that anymore). Also the developer community is something I dislike, or at least the way they communicate with eachother. They should become more aware of the fact that not only devs, but also users read their mailinglists. However I’m gonna miss some of that devs a bit! Yes guys I read your weblogs all that years. No hard feelings, just time to move on.

Now I’ve copied my mail and stuff back, set up a kde4 development environment and actually compiled (*sigh* does it ever end? =;) I should be able again to get some work done.

So farewell Gentoo and hello openSuse 10.2! Continue reading →

Wooohoo! After a lot of fidling and fudzing with bytes, the pilot-link classes and the KPilot classes I was earlier this day finaly able to create a new database for the Keyring conduit. But even better was that my little creation just ran for the first time as a real conduit. Although a lot of polishing is needed, it seems that the first rough implementation doesn’t crash and actualy syncs some information. What for sure works is the reading and decryption of the database on the handheld. This is a good thing because it’s the first time I actualy tried a database that is created with the keyring application on my handheld. Of course there is a lot to fix before we have a completely working Keyring conduit for KPilot, but i’m very glad with the results I have now.

One of the issues I have is with the wallet system. To open a wallet a window id is needed and I don’t know what the right way is to get the right window id. First I tried this:

WId window = qApp->activeWindow()->winId();

But that didn’t work quit well. activeWindow() returns a 0 sometimes. Asking in #kde4-devel dfaure told me that it indeed isn’t a good id to use this. He told me to use widget->topLevelWidget()->wId(). However in the conduit code I don’t have garanteed access to a widget. After a bit looking in the Qt docs i found: QApplication::topLevelWidgets() but the problem here is that I get a widgetlist with 5 items or so and I don’t know which WId is actualy from KPilot. I tried to print the objectNames and the windowTitles of the widgets but they are all empty. Any help on this would be appreciated. Continue reading →

<edit>First post on plannet. Hi planet! I’m the guy who’s doing the kpilot summer of code project.</edit>

A lot of work happened since my last blog. The base conduit is in a pretty good shape already. It has a nice testsuite which test a lot of important cases. I started working now on the keyring conduit. First I had to read through the keyring code and some sample applications to get some idea how the data is encrypted. I discoverd that there are two database versions for the gnukeyring application. The latest stable has version 4 and the latest beta has version 5. The most important difference is the encryption methods used. For now I decided to go for the stable version.

This lead me to investigate on how to encrypt/decrypt the records. My first plan was to copy as much as code as possible from the J-pilot keyring conduit. But this lead very soon to troubles because it uses OpenSSL to encrypt/decrypt the records. Thiago pointed me to QCA which resides in the kdesupport module. After some wrestling with it I got it decrypting and encrypting a keyring database. I have to say that (like the rest of Qt api) it’s a very nice library. Quite easy to use and only a couple of lines of code to do the job.

On of the things I encountered with it is that it’s not very well documented (or I didn’t read well enough) that when using QCA::SecureArray you must have a QCA::Initializer object. If there isn’t such an object you’ll get segfaults and if you don’t know where to look it’s quite hard to find out why. Another thing is that a QCA::SecureArray gets cleared when the QCA::Initializer object gets out of scope. Safety wise this is a good thing, secret data gets whiped out from memory. But it makes it a bit hard to pass QCA::SecureArrays to methods without losing the overview when an array gets erased. It took me some time before I discoverd that I was trying to decrypt records with an empty key, which of course was not valid. However, things are going quite well now, if you want to see QCA working take a look at the Keyring conduit.

Other news: I won a Qt book =:). And it’s quite nice to see vanRijn and [ade] working on kpilot. Continue reading →

It seemed that I was thinking that the world was less complex then it really is. *Sigh*. How could I? I was discussing some code with vanRijn and we came to the conclusion that I over simplified Records. I was thinking about records as entities which have an Id, some fields and a value for each field. This is still true but…. What I wanted is something like this:

syncFields( Record from, Record to )
{
    QStringList fields = from.fields();
    QStringListIterator it( fields );

    while( it.hasNext() ) {
       it.next();
       to.setValue( it, from.value( it ) );
    }
}

A same sort piece of code I would use for checking the equality of two records. This would be really nice because it would mean that implementing classes could be really simple. Even this sort of things (syncing fields and checking equality) could be done at top-level. However things are a bit more complicated then I thought. The address book conduit serves as an example here. The address book on the pda has place for five emails, phones, fax etc. So when you ask phones() from a hand held record you can get one but also five phone numbers. And also you won’t know at which place which number is stored. So just walking over fields from both sides won’t work here, and of course checking equality suffers the same problem.

Now I abstracted both methods, syncFields() and equal() but that means a lot of work on the test cases again. So….. let’s fix that. Continue reading →

It has been a while since I blogged. I guess I never become a great blogger, or more general a great writer. It’s realy not my thing to do.

However it still may be a good thing to write some things down so now and then. I’m halfway my Google summer of code project now and things are going quite nice. The base conduit is getting the wanted shape, although a lot of work has to be done to make it realy functional. At this moment I’ve finished the hotsync algorithm. This means that I still have to implement four other algorithms (first sync, fullsync, copy handheld to pc, copy pc to handheld) but I think that this isn’t that much work anymore because they will mostly use the same methods as hotsync does.

I also started adding some unittests which is quite nice, although it gives a lot of work when changing method signatures *sigh*. It might add quite a bunch of work next to development of the conduit, it’s quite a good sign when the testbase grows and doesn’t fail after working on the conduits. When in the end for all important algorithms tests are written it will become a less tedious job to maintain the conduits.

Today I worked on the commit/rollback mechanism for the data proxies. Not the most fun part to do, but the design is quite nice I think. For the handheld side I’ll be able to completely implement this, which means that writing a new Conduit doesn’t burden the conduit developer with this. For the PC site (e.g. the ics file or whatever you’re syncing with) there are only three methods that have to be implemented:

• virtual void commitCreate( Record *rec );
• virtual void commitDelete( Record *rec );
• virtual void commitUpdate( Record *rec );

The only thing about this that doesn’t satisfy me is that I can’t five a const Record* to these functions. The problem here is that the handheld creates a new id for the pilot record. So on a commit it should be able to alter the record. Of course I’ll document in the API that the implementing conduits shouldn’t alter the data of the record except for the id, but still…..

Oh there seems to be a real techbase vibe. People doing promises about adding documentation. So I thought that I could add to that…. It may be not a bad thing to write a tutorial for writing a new record-based conduit. (Heh this even could lead to me porting less conduits). But before anyone will be even able to write conduits for trunk/kpilot a lot of work has to be done.
Continue reading →

So, a couple of weeks has past now and as vanRijn mentioned we’re making good progress. It’s great to work with him and i realy appreciate his comments on my work. We’ve had a lot of discussion about design issues such as “Should we copy the databases we want to sync to a temporary location?” and “How do we keep track of changes and fall back if something wrong happens?”. We decided not to copy the databases to a temporary location but to go for a dataproxy which registers changes (somehow) and commits them at once to the database at the end.

We have less or more finished our use case document and are now working on class and sequence diagrams. At the end of this week i hope to generate some code from the diagrams so that I can work on the CMake files that are necessary.

This week i’ll have to finish some lab work for the cours “Signals and systems and next week I’ll have an exam for that so until then i’ll be a bit busy with my study but after that i’ll have a lot more time to work on the project.

Continue reading →

So the summer of code now realy has started for the students. I chitchatted already a bit with Jason "vanRijn" Kasper and this saturday we became realy serious .  We started working on the first document which can be found at: http://websvn.kde.org/trunk/KDE/kdepim/kpilot/conduits/base/design/Use%20Case%20-%20Conduit%20Syncing.odt
Currently I’m working on this document to get some more insight in the syncing process of conduits which are record based. A couple of things are relevant in this process.

1. The process must become a three way sync. Namely between the database on the handheld, the last synced copy of this database on the pc and the datastorage on the pc (e.g. an ical file, a flat file, a xml file, etc). When a record on the palm is the same as the record in the backed up copy during a sync then the record on the palm didn’t change. If the record on the palm hasn’t changed but differs from the record in the datastorage then that record has changed. If both records differ from the backup db then there is a conflict. Also handling of deleted and added records must be handled someway.

2. What to do when:

• The backup db on the pc doesn’t exist.
• The local datastorage doesn’t exist.
• There is a local datastorage but no db on the handheld and no backup db.
• The pc id of the local backup db differs from the pc id on the handheld (this can happen when a handheld is synced with more then one pc).

3. What situations can occur when handling records, and how should we handle each situation (conflicts, added records, deleted records, etc).

Curious about all these things? Keep an eye at the document. In a day or two this should be a bit more clear or at least documented. Continue reading →