• intro
• news
• security
• contribute
• development
• history
• hardware
• faq

KPilot Development

KPilot 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.

Roadmap

This roadmap is a list of "what's on my mind 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).

• Top priority:
  1. Detection wizard is broken (probably from threading).
  2. Use CUDcounter to warn user of large changes (data safety).
  3. Enhance backups (with datestamps, for instance).
  4. Valgrind until clean.
• Code cleanup:
  1. get full sync working with memofile conduit (oops!)
  2. pull all syncing logic out of conduits into a common base class and leave only data transformation/comparison stuff thar. Note: we have a good base for this code in trunk/KDE4, and it'll happen there, not in the 3.5 branch.
  3. 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.
• Development in trunk:
  1. Need to find areas of base conduit and keyring conduit where syncing is not working and bullet-proof/fix them.
  2. 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.
  3. Category syncing has never worked from PC->Palm. We MUST get this figured out and working in an extensible manner.
  4. Instead of spinning our wheels in trying to convert all of the old conduits from kde3/qt3->kde4/qt4, I think it would be better to convert less code and extend all conduits from our new base conduit code.

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:
KDE3 is an amazing, well-tested environment, and will continue to be supported and used because of its stable nature (in general =;)), even after KDE4 has been released. 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 3.5.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/3.5/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.

KPilot Build Dependencies

KPilot needs a variety of tools in order to build. Most installations of Linux or other Open Source operating systems already have these tools installed, but you should check anyway. Here's a list of what you need to have installed:

• KDE. Otherwise compiling a KDE program doesn't make much sense.
• KDE Development. Many flavors of Linux make the weird choice of installing development packages separately. In that case, you need something like kdelibs-devel as well as the kdelibs software package that comes with KDE. *BSD users get the development stuff for free along with the normal software installation.
• Qt Development. This is one of the underlying libraries for KDE, so if you have KDE, you already have the regular Qt packages, but you still need the development headers. This might be qt-devel -- that depends on your distribution.
• g++. This is the GNU C++ compiler; not all Linux systems have it installed, to my surprise and chagrin. You need, I believe, version 3.3 or later. Earlier versions are certainly not tested.
• Possibly other development packages. This is the most variable of the lot: you may need other stuff that I cannot possibly guess to compile KPilot. For KUbuntu, for instance, you need libattr1-dev because the KDE packages are broken (in the sense that they install without that development package, but subtly require that package for subsequent compilations).
• CMake, version 2.4.4 or later. KPilot lives inside KDE 3.5's kdepim directory and as such is normally built with the auto* tools (autoconf, automake, etc.) that the rest of the KDE PIM suite builds with. KPilot is also buildable on its own. To this end, KPilot uses the CMake (cross-platform make) build system. For the purposes of this website, we will discuss compiling KPilot using CMake.

  Version 2.4.3 of CMake has a bug that causes compilation to fail in a .kidl file; you need 2.4.4 or later, 2.4.5 is preferred. Debian / Kubuntu users can follow the below steps (thanks to pusling for the walk-thru!!!): #Backport cmake in debian / ubuntu. #Install some build tools and stuff: sudo apt-get install fakeroot devscripts build-essential #download and extract sources: dget -x http://.............../c/cmake/cmake_VERSIONSTRING-DEBIANREVISION.dsc #install build-dependencies sudo apt-get build-dep cmake #build time cd cmake-VERSION debuild #install time cd .. sudo dpkg -i cmake_VERSIONSTRING-DEBIANREVISION.deb Other distributions will have to look farther.

  It is possible to hand-patch a 2.4.3 installation: find the file KDE3Macros.cmake and look inside; there are two macros defined there, KDE3_ADD_DCOP_SKELS and _STUBS, with a CUSTOM_COMMAND section inside. One of the CUSTOM_COMMAND sections is missing an underscore somewhere. Add it and you'll be fine (but I can't remember where exactly, it should be obvious if you're brave enough to try this).

Configure KPilot Build

You might want to set some optional parameters before you compile KPilot. These are done by passing parameters to CMake, in a rather complicated manner normally. To make this job easier, a small configure script has been provided to set some of these more commonly-set parameters (such as debugging, installation prefix, and the location of pilot-link). If you need to set these, you can run configure before make, as illustrated below: Make sure you are in the KPilot source directory $ ./configure --prefix=$HOME/kde3 --enable-debug=yes \ --with-pilot-link=$HOME/local/pilot-link-0.12.1/ ... $ make -f Makefile.cmake ... This assumes that the includes and the libraries for pilot-link can be found in the include/ and lib/ directories under the given pilot-link path. If you need even finer control, run configure --help to see what other options there are.

Make KPilot

Once configure has finished, it will instruct you to run the make program (or gmake, on FreeBSD). You must tell make to use an alternative Makefile, like so: $ make -f Makefile.cmake This will invoke CMake in the correct way and then proceed to compile KPilot. It takes about 5 minutes to compile KPilot on an amd64 3200+, but while it is compiling you will be treated to a light show something like this: [ 5%] Building CXX object lib/CMakeFiles/kpilot.dir/pilotDatabase.o [ 6%] Building CXX object lib/CMakeFiles/kpilot.dir/pilotMemo.o Linking CXX shared library libkpilot.so [ 7%] Built target kpilot [ 8%] Generating kpilotConfigDialog.moc If everything compiles correctly and you don't get any errors, you can then install KPilot's code by executing the following command: $ make -f Makefile.cmake install If you have installed KPilot into a directory other than the the same prefix that the rest of KDE is installed, you will need to do a few more things before you can run your new code.

In the example below, we'll assume that you installed KPilot into $HOME/kde3, as was used in the example configure line shown above. $ export KDEDIR=$HOME/kde3 $ export KDEDIRS=$KDEDIR:/usr:/opt/kde3 $ export LD_LIBRARY_PATH=$KDEDIR/lib:$LD_LIBRARY_PATH $ export PATH=$KDEDIR/bin:$PATH $ kbuildsycoca After you've done these steps, you can now kill off any previous version of KPilot and start your newly-compiled code: $ killall kpilot kpilotDaemon $ $HOME/kde3/bin/kpilotDaemon $ $HOME/kde3/bin/kpilot