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 get a backtrace under Linux with GDB, use following command:
$ gdb digikam (gdb) catch throw (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:
For memory leaks
To check any memory leak problem in digiKam, valgrind is your friend. Try to run the command line below into a console and report the the trace to developers. digiKAm must be previously compiled with debug symbols.
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
Note: under Windows, no trace are printed to the console directly. You need to install DebugView tool to capture debug traces generated by digiKam.
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 traces 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 git/master revision), not the stable release or an old beta version published. 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 software 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.