How can I contribute ?
You can start by promoting digiKam to your friends and colleagues by showing them how powerful digiKam is :)
You are also welcome to strongly test all digiKam features and to report bugs, see below.
Subscribing to digiKam-users and helping newbies is also a good way to increase the number of digiKam users !
If you are new to the free software world, we recommend to take a look at this article which summarizes they way open source projects work very well.
Reporting bugs and wishes
Please use the KDE bug tracking system for all bugreports and new feature wishlists. Take a look at support page for details.
If you are experiencing crashes with digiKam
If you found a context to crash digiKam, you can provide a backtrace using GDB debugger. digiKam needs to be compiled with all debug info orelse the backtrace will be useless. If you installed digiKam using the packages provided by your distribution please install the corresponding debug package. To find the name of these packages more information can be found here. In order to test recent changes made by the developers, it would be even better to build the current development version yourself, the instructions are given here.
To make a backtrace with GDB use following command:
$ gdb digikam (gdb) run (gdb) ... (gdb) _crash here_ (gdb) ... (gdb) bt (gdb) _the backtrace is here_ (gdb) quit
For a detailed and very helpful guide on providing useful crash reports see this guide.
For Windows users, take a look on this tutorial
For Mac-OSX users, you need to install digiKam through Macports project using +debug keyword. GDB debugger must be installed too with Macports. To run digiKam under gdb, just use this command line: gdb /Applications/MacPorts/KDE4/digikam.app/Contents/MacOS/digikam.
For memory leaks
To check any memory leak problem in digiKam, valgrind is your friend (http://valgrind.org) Try this command line to use with valgrind :
valgrind --tool=memcheck --leak-check=full --error-limit=no digikam
For hangs out or dysfunctions
digiKam trace main debug statements into the console. To turn on debug mode, use kdebugdialog tool to switch on right digiKam debug spaces before to run it, else nothing will be printed to the console. Usual debug spaces are:
- digikam (core) : core digiKam operations
- digikam (kio-slave) : KIO-Slave traces
- digikam (showfoto) : stand-alone Showfoto editor
- digikam (editor plugins) : image editor tools
- digikam (database server) : database operations
- KEXIV2 : metadata handling through libkexiv2/Exiv2 shared libraries
- KDCRAW : Raw images handling through libkdcraw/LibRaw shared libraries
- KIPI (general) : Kipi tools operations
- KIPI (loading) : kipi tools loading through libkipi shared library
- KFACE : Face management through libkface shared library
- KGEOMAP : Geolocation through libkgeomap shared library
digiKam use also dedicated KIO-Slaves to query database contents outside main process. KIO-Slave are separated processes which are delicate to hack. Under Linux, KIO-Slave trace are reported to your .xsession-errors from your home directory. Try this command line to grep digiKam KIO-Slave traces :
cat ~/.xsession-errors | grep digikam
You are welcome to propose patches. But, please read the HACKING file first.
Send patches against the current version of the code (latest svn revision), not the stable release or an old beta version. Patches can be created with :
git diff HEAD > mydiff.patch
If you want to contribute to the digiKam internationalization effort, you need to contact directly the KDE translation teams at http://l10n.kde.org/.
You can start by reading the KDE Translation HOWTO.
Help to our excellent documentation is always welcome. For all matters concerning it, write to gerhard at kulzer dot net. Our documentation is established in docbook format (KDE standard, a must reading). This README file explains in more detail how to do structure the documents, how to do screenshots, compress them and so on.
Even small additions/changes in ASCII format are possible, and should be sent to gerhard_at_kulzer_dot_net so that they can be incorporated in the docbook.
We need some sample files produced by recent digital cameras, especially RAW and JPEG files from different manufacturers (like Canon, Nikon, Sony, Olympus, Sigma and so on).
With these files, we'll be able to look at metadata (Maker-Notes) embedded in the files to improve their support in digiKam (via the exiv2 and libraw libraries).
We also need sample files produced by all kind of applications (including other OS and proprietary softwares like photoshop) that include IPTC/XMP metadata. It's to ensure compatibility with other tools and to test the new automatic import of this data in the digiKam database (comments and tags update and so on).
If you is a photographer you can contribute to the digiKam to propose your best shots as splash-screens. Take a look at this page for details.