Commit e2363776 authored by Vincent PINON's avatar Vincent PINON

0.9.8 release

parent 0aa7dd79
......@@ -3,15 +3,12 @@ Active Kdenlive authors
Jean-Baptiste Mardelle <>
MLT and KDE SC 4 porting, main developer and maintainer
Marco Gittler <>
MLT transitions and effects, timeline, audio thumbs
Dan Dennedy <>
Bug fixing, etc.
Simon A. Eugster (Granjow) <>
Colour and audio scopes, titler, manual, bug fixing, etc.
Vincent Pinon <>
Bugs fixing, release
Laurent Montel <>
Bugs fixing, code clean up, review
Till Theato <>
Bug fixing, etc.
......@@ -21,6 +18,15 @@ Active Kdenlive authors
Former Kdenlive authors
Simon A. Eugster (Granjow) <>
Colour and audio scopes, titler, manual, bug fixing, etc.
Marco Gittler <>
MLT transitions and effects, timeline, audio thumbs
Dan Dennedy <>
Bug fixing
Jean-Michel Poure <>
Rendering profiles customization
......@@ -2,7 +2,7 @@ project(Kdenlive)
# An odd patch version number means development version, while an even one means
# stable release. An additional number can be used for bugfix-only releases.
# Minimum versions of main dependencies.
This diff is collapsed.
This is the coding guideline for Kdenlive.
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.
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
Each class should be shortly described in its header file.
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:
Avoid as much as possible #includes in header files; use forward declarations
of classes.
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/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.)
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.
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.
Kdenlive installation instrucions
To compile and install, go in the source directory and type:
mkdir build;cd build
cmake ..
(If you want to install in a different path, use instead:
cmake .. -DCMAKE_INSTALL_PREFIX=/install/path)
To install, become root:
sudo make install
(enter root password at prompt)
Once installed, you can start Kdenlive by typing "kdenlive".
Note that you should also install MLT to do anything useful with Kdenlive. See
the README file for details.
Have Fun!
by Jean-Baptiste Mardelle <> and the Kdenlive team
About Kdenlive
Kdenlive is a video editing application based on KDE Platform 4.
Please check the project page for more information, and to report new bugs.
Kdenlive is a video editing application,
based on MLT Framework and KDE Platform 4.
Please check the project page for more information:
To use Kdenlive, you will need to download and install MLT, available from
the following web page:
It is recommended to use the latest MLT version. It may work with older
versions, but this is not guaranteed, or (at this stage of development) likely.
We welcome all bug reports, feedback, and offers for help!
So please visit our bug tracker and forums:
Bug Tracker:
Building from source
You will first need to install development headers dependencies
from your system (mainly KDE and MLT).
Then in the directory where you extracted the source archive
(with custom /install/path):
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/install/path
make -j4
sudo make install
and then run
Alternately, to get kdenlive with an up-to-date multimedia stack
(isolated from your system), you can use the from:
We welcome all feedback and offers for help!
* Talk about us!
* Report bugs you encounter (if not already done) on:
* Help other users on forum and bug tracker:
* Help to fill the manual at:
* Complete and check application and documentation translation:
* Prepare video tutorials (intro, special tricks...) in your language
and send us a link to add in homepage or doc
* Detail improvement suggestions
we don't test every (any?) other video editor, so give precise explanations
* Code! Help fixing bugs, improving usability, optimizing, porting...
register on KDE infrastructure, study its guidelines, and pick from roadmap:
This file is intended to contain tips and Q/A for translating.
* What is String Freeze?
Some weeks (usually 2) before a new release, string freeze is declared. From
then it is guaranteed that no strings in the source code will be changed
anymore so that translators can work without constantly having to update again
and again.
* There is a duplicate string (like «Clip:» and «Clip: » or «Audio device» and
«Audio Device»). What to do?
File a bug report on Mantis so that they can be corrected for the next
* There is some other weird thing (singular form has to be translated both
separately and together with its plural form, etc.).
As above: bug report.
* There is HTML and some CDATA tags in a string to translate.
Yes. This is not a mistake but intended, for formatting. Please keep these
tags. :)
This file contains a to-do-list for releases. In braces the responsible person; none given means everybody.
All time
Blog about new features that have been added.
Also: Facebook
Before the release
Discover page
Add blog entries to the discover page ( but with updated version number).
Add the changelog as well.
The dot (jb?)
Prepare an article for (may take some days until it is accepted) (they say)
Notifications (jb?)
* Notify devs, testers, and translators of the String/Feature Freeze
* Notify packagers about the new release when it's done
About two weeks before a new release feature and string freeze will be introduced. This allows:
* Translators to translate Kdenlive everything on time. (Strings must not be changed anymore
in the source code, otherwise the translators would have to fix it again and so on.)
* Testers on finding remaining bugs
* Developers to focus on bug fixing (and not introducing new bugs with new features)
Ideally mobilize as many testers as possible to find remaining bugs before the version is released!
Manual (Granjow)
Update the manual (push to git) from the Userbase
After the release
Close all entries that have been resolved in this release.
Some ideas for a big refactoring of code.
handle MLT connection ((re-)move from renderer.cpp (hacks, special cases))
handle project document entry
draw layer on clip instances in timeline (thumbnails)
settings management (available through project tree items)
proxy creation
input method (register mimetype in file dialog, custom widget)
effect support (a, v, av, special effects (freeze, speed))
support for multi-channel sound (5.1, ...)
=> modules for avformat, qimage/gtk_image(?), generators (slideshow, color, f0r)
provides basic operations (resize, move, add, remove) (GUI + XML + MLT) to be applied on any item
=> modules for input modes (drag & drop, 3/4-point editing, cut, resize by dragging end), spacer, ripple edit, push/pull edit, ...)
Clip instances
connection to input module
manage project document entry
information about support for timeline operations
owns an effect device
per instance settings (functionality provided by input module)
graphical timeline item (modules can register layers they want to draw (thumbnails, effect names, keyframes))
Clip groups
manage project document entry
pass on operations to items
Effect system
Keyframe manager
pipe information from/to timeline effect device, effect stack, effect parameter
Effect parameter
custom widget
function to handle keyframes -> connect to keyframe manager
written in QScript/QML ?
Effect device
manages list of effects attached to clip, track, timeline, group, the world
passes info from/to timeline items and effect stack
manage project document entry
project settings management
provide functionality to manage settings (remove hardcoded stuff (slideshow, proxy, ...))
provide functions to add menu items, global actions (for shortcut management)
layout management
styles management (see digikam)
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment