-Jean-Baptiste Mardelle <jb@kdenlive.org>: MLT and KDE SC 4 porting, main developer and maintainer
-Marco Gittler <g.marco@freenet.de>: MLT transitions and effects, timeline, audio thumbs
-Dan Dennedy <dan@dennedy.org>: bug fixing, etc.
-Simon A. Eugster <simon.eu@gmail.com>: color scopes, bug fixing, etc.
-Till Theato <root@ttill.de>: bug fixing, etc.
-Alberto Villa <avilla@FreeBSD.org>: bug fixing, logo, etc.
-Jean-Michel Poure <jm@poure.com>: rendering profiles customization
-Ray Lehtiniemi <rayl@mail.com>: bug fixing, etc.
-Jason Wood <jasonwood@blueyonder.co.uk>: original KDE 3 version author (not active anymore)
+Active Kdenlive authors
+
+ Jean-Baptiste Mardelle <jb@kdenlive.org>
+ MLT and KDE SC 4 porting, main developer and maintainer
+ 2005-present
+ Marco Gittler <g.marco@freenet.de>
+ MLT transitions and effects, timeline, audio thumbs
+ 2009-present
+ Dan Dennedy <dan@dennedy.org>
+ Bug fixing, etc.
+ 2009-present
+ Simon A. Eugster (Granjow) <simon.eu@gmail.com>
+ Colour and audio scopes, titler, manual, bug fixing, etc.
+ 2009-present
+ Till Theato <root@ttill.de>
+ Bug fixing, etc.
+ 2010-present
+ Alberto Villa <avilla@FreeBSD.org>
+ Bug fixing, logo, etc.
+ 2009-present
+
+Former Kdenlive authors
+
+ Jean-Michel Poure <jm@poure.com>
+ Rendering profiles customization
+ 2004-2009
+ Ray Lehtiniemi <rayl@mail.com>
+ Bug fixing, etc.
+ 2009
+ Jason Wood <jasonwood@blueyonder.co.uk>
+ Original KDE 3 version author
--- /dev/null
+
+This is the coding guideline for Kdenlive.
+
+Committing
+ Auto-indent
+ Please don't use for existing files. It is very likely to break manual tweaks like:
+ const int componentFlags = (ui->cbY->isChecked() ? 1 : 0) * HistogramGenerator::ComponentY
+ | (ui->cbS->isChecked() ? 1 : 0) * HistogramGenerator::ComponentSum
+ | (ui->cbR->isChecked() ? 1 : 0) * HistogramGenerator::ComponentR
+ | (ui->cbG->isChecked() ? 1 : 0) * HistogramGenerator::ComponentG
+ | (ui->cbB->isChecked() ? 1 : 0) * HistogramGenerator::ComponentB;
+ which are intended to improve readability.
+
+ Changelog
+ When adding a new feature, add it to the CHANGELOG file. Features often are not mentioned
+ in the bug tracker; adding it to the changelog helps keeping track of them.
+
+ Bug fixes
+ Bugs often are in mantis. When fixing a bug, add a link to the bug tracker entry in the commit log
+ and close the bug there.
+ If the bug is not in mantis, it should be (a) added (and marked as fixed) if it is an important bug,
+ or (b) not added otherwise.
+
+
+Source code comments
+ Classes
+ Each class should be shortly described in its header file.
+
+ Functions
+ Public functions should be documented as well in the header file. Especially regarding side effects!
+ (What does a programmer neeed to know in order to use this function without reading the whole source code?)
+
+ Inline comments
+ are very helpful for commands (function calls, calculations) that are not obvious. For example, what
+ does this function call do?
+
+ davinci.drawLine(0, y, scopeRect().size().width()-RGBParadeGenerator::distRight, y);
+
+ A short comment makes it obvious (also helps locating bugs when something needs to be fixed):
+
+ // Draw a horizontal line through the current mouse position
+ davinci.drawLine(0, y, scopeRect().size().width()-RGBParadeGenerator::distRight, y);
+
+
+API documentation
+ The docs can be generated by using doxygen (doxygen DoxyConfig in the main directory).
+ See [1] for an overview of doxygen commands.
+ Often used: \brief, \param, \return
+
+
+Coding style
+ This part is based on Krita's HACKING file[2].
+
+ Indentation, Braces etc.
+ 4 Spaces for indentation. Always braces.
+ This is, according to the Qt4 coding style, which is documented here:
+ http://techbase.kde.org/Policies/Kdelibs_Coding_Style
+
+ Includes
+ Avoid as much as possible #includes in header files; use forward declarations
+ of classes.
+
+ Initializers
+ Avoid as much as possible initializers in the body of the constructor. Use
+ initializer lists instead.
+
+ Scope prefixes
+ Use only m_ for class-level variables. No other scope prefixes; no g_, l_,
+ no 'p' for pointer variables.
+
+ Shared pointers
+ Use shared pointers wherever possible.
+
+ Getter/setter
+ Getter/setters are named x() for getters and setX(int x) for setters. If you
+ come across violations of this rule, change the code.
+
+ Function naming
+ Functions should be named in camelBackedFashion, to conform to Qt's standards.
+ If you encounter functions in c_style_like_this, feel free to rename. Also:
+ verbNoun -- i.e., rotateLayer, not layer_rotate. The latter is a true c-ism,
+ introduced by a language that needs to prefix the 'class' name to every function
+ in order to have something that not quite OO.
+
+ Variable/Parameter names
+ Variable/parameter names start with an undercast letter. A name composed of different
+ words is done in camelBackedStyle.
+
+ Files and classes
+ It's preferred (and strongly preferred) to have only one class per .h/.cpp file.
+ (Which is logical, because otherwise you won't be able to keep to the naming scheme.)
+
+ Spaces
+ Keep the source airy and open. In particular, there should be empty lines between function
+ declarations and definitions.
+
+ Slots and signals
+ Prefix slots with slot and signals with signal: slotUpdateSelection, signalSelectionUpdated.
+
+ Boolean operators
+ Use the standard !, !=, ==, && etc style, not the "not", "and" etc. style. Keep kdenlive code
+ using one, easily recognizable, C++ style.
+
+
+ Exceptions
+ These rules are merely guidelines for making the code consistent and more readable. In some cases
+ it makes sense to not follow some of the points mentioned above.
+
+
+[1] http://www.stack.nl/~dimitri/doxygen/commands.html
+[2] http://quickgit.kde.org/?p=calligra.git&a=blob_plain&h=3e8fcab9dd3588c0228498af2795d3b714b73d42&f=krita/HACKING