Commit d7ae41cd authored by Thibault Saunier's avatar Thibault Saunier

docs: Update HACKING and make it a markdown file

Differential Revision:
parent bd8036f2
Hacking on Pitivi
# Hacking on Pitivi
## The pitivi development environment
### Setup pitivi
The official way of getting your environment up and running is by using
You first need to [get xdg-app](
making sure you also install xdg-app-builder, which might be provided by an
additional package on some distributions (please tell us if it is the case
for yours so we can make a list here).
Then, create a development environment folder and get the [ Pitivi source code] into it:
$ mkdir pitivi-dev && cd pitivi-dev
$ git clone
$ cd pitivi/
Finally you just need to run:
$ source bin/pitivi-env
Run `pitivi` while inside the environment to launch Pitivi. Next you should run the unittests.
After you edit the source code simply run `pitivi` to see how your changes work.
### Update the environment
In the `pitivi-env` you can simply run:
ptvenv --update
That will actually clean the prefix, update all dependencies from their
git repos and tarballs as defined in the xdg-app manifest (located
in build/xdg-app/pitivi.template.json)
### Work on some pitivi dependencies in the development environment
If you have to work on say, [GStreamer Editing Service](
you can clone it into you `pitivi-dev`:
git clone git://
Then you can just hack on it, run `autogen` to run `./` with the right arguments for the xdg-app sandbox,
and run `make install` to install your changes inside the sandbox (your changes won’t be taken into accout
without installing).
NOTE: When updating the environment, it will use your
local dependencies repositories instead of remote
repositories, which means you have to update them yourself.
Also beware that it will not take into account not committed
# Coding Style Guide
* Coding Style Guide
- We rely on the Python Style Guide PEP-8
......@@ -34,12 +90,15 @@ Hacking on Pitivi
_("<b>First line</b>\n"
"Some second line that is too long to fit on the first line anyway"
- for method names we use the mixedCase style
- for method names we use the small_caps_with_underscore style
Ex :
``` lang=python
class MyClass:
def aReallyImportantMethod(self):
def a_really_important_method(self):
- for callbacks, the name of the methods used should:
- follow same conventions as normal method names
......@@ -47,30 +106,39 @@ Hacking on Pitivi
- be appended with Cb
Ex :
``` lang=python
class MyClass:
def someMethod(self):
self.someobject.connect('event', self.__someObjectEventCb)
def some_method(self):
self.someobject.connect('event', self.__some_object_event_cb)
def __someObjectEventCb(self, object, arg):
def __some_object_event_cb(self, object, arg):
print "our callback was called"
- for function names, we use the small_caps_with_underscore style.
This enables clear separation between functions and methods.
- for other class attributes we use the same calling convention as
for functions:
Ex : @property
def water_level(self):
""" The level of the water in meters"""
return self.__water_level
Ex :
``` lang=python
def water_level(self):
""" The level of the water in meters"""
return self.__water_level
- unused arguments in method should be prefixed by 'unused_'.
The most common place where this would happen is in callbacks from gobject
Ex : (we don't use the second argument, but we do use pad)
``` lang=python
def _padAddedCb(self, unused_element, pad):
- The following naming should be used for class properties/methods:
* public : <name>
......@@ -81,11 +149,3 @@ Hacking on Pitivi
* system modules
* top-level pitivi modules (ex : pitivi.project)
* modules in the same directory
* Debugging
- All debug output should be done through the gstreamer debugging system:
ex : gst.debug("wow")
- Whenever appliable, the debugging should be used on gstreamer objects
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