Revision as of 00:00, 24 January 2009 by Bbroeksema (talk | contribs) (Update the todo list.)


KPilot Development

Pilot development is distributed and collaborative. That means anyone is allowed to -- and encouraged to -- help. We use a revision control system called Subversion to make it possible to work together on one code base. KDE as a whole uses Subversion as well, and has a Subversion guide for KDE which describes basic SVN (Subversion) usage. There is of course also the SVN Book which covers everything. You can fetch the sources to KPilot as described below, and then compile them. This will always give you the latest version of KPilot. Such a version may not be the most stable, since I may be in the middle of fixing something big and complicated. Such is the luck of the draw. I'll try to post a warning on the site beforehand, though. Once you have the source, you can compile the latest version of KPilot with debugging enabled (it is enabled by default) in order to get the best possible debugging logs so you can track problems down effectively. In general, if you have a problem with KPilot I will expect you to have a copy compiled from source to work with -- it's the only way we can get anything done.

Road map

This road map is a list of "what's on our minds for the short and medium term" items; they may not be done in order, and critical bugs might get in the way at any time. Please get ahead of me! Send me patches for any of these items and receive a real KPilot cookie (recipe undisclosed).


  • Short term
    • Check the fDummy and isValid() code in AkonadiRecord it was introduced in r912638 but I'm not sure if this is the way to go.
    • Rethink the patch of r912613. This introduces a check to see if the user configured a different Akonadi Collection with respect to the last sync. I think this should be generalized a bit so that it doesn't depend on conduit specific code anymore as this might give problems for new conduits.
    • get the stupid connection handling stuff cleaned up
    • Use CUDcounter to warn user of large changes (data safety). Although there is a CUDCounter in RecordConduit we should review this code.
    • Make sure that the current conduits (especially the Akonadi ones) work as expected.
  • Medium term
    • Valgrind until clean.
    • Enhance backups (with datestamps, for instance).
    • get full sync working with memofile conduit (oops!) => port memofile conduit to base conduit and this should be fixed.
    • Unit tests need to be the New Way Forward (TM). Any code fixes should include unit tests. Testing should first be done via unit tests and only after that tested via a live Palm device.
  • Long term
    • Detection wizard is broken (probably from threading).
    • The daemon needs a pop-up log viewer window, and kpilot needs to have its hotsync code removed. All the config stuff should end up in the daemon, so that KPilot is just a viewer for data. This is a bit out of date as all the viewer are removed in KDE4 anyway but we should think about the GUI anyway.
    • Fix the keyring conduit?!

Get the source

The source code for KPilot lives in a Subversion repository. You will need a Subversion client to get it (there are no downloads of the KPilot source available right now). How you get a Subversion client is rather system dependent; something along the lines of apt-get install subversion or pkg_add -r subversion should do the trick, though. Once you have SVN, you can use it from the command line to download the KPilot source. It is recommended that you get the latest version, as described below, but there may be other versions available, such as the latest version deemed stable, or whatnot. These can be found in the different tags and branches in KDE SVN

Getting the latest stable version:

The most stable and tested version of KPilot exists in this long-term, stable branch of KDE's SVN repository. As bugs are fixed in KPilot, the latest, bug-fixingest code will be found here. This branch includes what is provided in KDE's 4.x release cycle, plus any bug fixes in between KDE's release cycle. It should always be safe to retrieve and use this code. You can get it from the command line as follows:

$ svn co svn://anonsvn.kde.org/home/kde/branches/KDE/4.2/kdepim/kpilot/

Getting the latest development/unstable version:

The latest version is known as "trunk" in SVN jargon, and the development of KPilot for KDE4 happens in KDE's subversion server, in trunk. This code is very possibly not as functional or well-tested as the above branch, being that it's the unstable and development environment for KPilot. You can get it from the command line as follows:

$ svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepim/kpilot

This will download the source into a directory called "kpilot/". You can rename the directory however you like. Once you've got the source code, you can cd into the directory and compile it (or hack on it). Keeping up-to-date: Once you have a checkout of KPilot trunk (released versions never change, so you don't need to keep those up-to-date), you can keep up-to-date by running SVN update every so often, like this:

$ svn update

Do this in the directory from the KPilot checkout (i.e. in the kpilot/ directory). This will download whatever changes have been made since last time. Once you have the source, you can do almost whatever you like with it within the rules of the license. In particular, I'd suggest you compile it, so that you can run the latest version.

Content is available under Creative Commons License SA 4.0 unless otherwise noted.