Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

255 lines (186 sloc) 8.921 kb
F-Spot's source repository is in GNOME GIT, in the module 'f-spot'.
For information on GNOME GIT, see:
If you are not familiar with GIT, please read this page:
If you have a patch you'd like to submit, please open a bug describing your fix
or feature on (product 'f-spot'), and submit a merge request
on Gitorious ( The selection below describes how
to do so:
First, clone our git repository ("git clone git://"), apply
your change and "git commit" it, preferably to a branch with a suitable name.
Then create a clone of f-spot mainline on Gitorious, by selecting "Clone this
repository on Gitorious" on the page for the "mainline" repository:
Once that's done, you'll end up on a special page for your clone on Gitorious.
It contains a "push URL", which you'll need in the next step. It should look
like this:
Add this push URL as a remote to your local repository (replace the words
yourname and pushURL with applicable values. You can choose the value of
yourname, pushURL should be the push url for your repository):
git remote add yourname pushURL
You can push the change you created in the first step to Gitorious using the
following command (again replace yourname and branchname):
git push yourname branchname
The change should now show up on the Gitorious web page, and you can request a
merge using the "Request merge" link on the page for your clone. Please
provide a link to the bug you filed in Bugzilla in the merge request.
We will review the patch, but if people are busy it might not happen right
In the past we'd been doing patch review on the mailing list, but that hasn't
always worked very well. Sometimes patches get lost in the shuffle.
Coding Style
F-Spot attempts to follow the Mono coding conventions. The following
description of those conventions was shamelessly stolen from Beagle's
* Tagging buggy code
If there is a bug in your implementation tag the problem by using
the word "FIXME" in the code, together with a description of the
Do not use XXX or TODO or obscure descriptions, because
otherwise people will not be able to understand what you mean.
* Basic code formatting
In order to keep the code consistent, please use the following
conventions. From here on `good' and `bad' are used to attribute
things that would make the coding style match, or not match. It is not
a judgement call on your coding abilities, but more of a style and
look call. Please follow these guidelines to ensure prettiness.
Use tabs for indentation, not spaces.
Since many are using 8-space tabs, you might want to consider the Linus
Torvalds trick to reduce code nesting. Many times in a loop, you will
find yourself doing a test, and if the test is true, you will
nest. Many times this can be changed. Example:
for (i = 0; i < 10; i++) {
if (Something (i)) {
DoMore ();
This take precious space, instead write it like this:
for (i = 0; i < 10; i++) {
if (! Something (i))
DoMore ();
A few guidelines:
* Use a space before an opening parenthesis when calling
functions, or indexing, like this:
Method (a);
b [10];
* Do not put a space after the opening parenthesis and the
closing one, ie:
good: Method (a); array [10];
bad: Method ( a ); array[ 10 ];
* Inside a code block, put the opening brace on the same line
as the statement:
if (a) {
Code ();
Code ();
if (a)
Code ();
Code ();
* Avoid using unecessary open/close braces, vertical space
is usually limited:
if (a)
Code ();
if (a) {
Code ();
* When defining a method, use the C style for brace placement,
that means, use a new line for the brace, like this:
void Method ()
void Method () {
* Properties and indexers are an exception, keep the
brace on the same line as the property declaration.
Rationale: this makes it visually
simple to distinguish them.
int Property {
get {
return value;
int Property
get {
return value;
Notice how the accessor "get" also keeps its brace on the same
For very small properties, you can compress things:
int Property {
get { return value; }
set { x = value; }
* Use white space in expressions liberally, except in the presence
of parenthesis:
if (a + 5 > Method (Blah () + 4))
if (a+5>Method(Blah()+4))
* For any new files, please use a descriptive introduction, like
// System.Comment.cs: Handles comments in System files.
// Author:
// Juan Perez (
// (C) 2002 Address, Inc (
* Switch statements have the case at the same indentation as the
switch (x) {
case 'a':
case 'b':
* Private variable and function local variable names are under_scored
(no camelCase please).
If you are using Emacs, you might want to put something like this
in your .emacs file:
(defun poor-mans-csharp-mode ()
(setq mode-name "C#")
(set-variable 'tab-width 8)
(set-variable 'indent-tabs-mode t)
(set-variable 'c-basic-offset 8)
(c-set-offset 'inline-open 0)
(c-set-offset 'case-label 0)
(setq auto-mode-alist (append '(("\\.cs\\'" . poor-mans-csharp-mode))
Unit Tests
Unit tests using Nunit should follow a very simple structure. The
class being tested should include an inner class (typically called
Tests) that is marked with the [TestFixture] attribute and should
include one or more methods marked with [Test] attributes. The entire
test class and any using statements should be surrounded by an #if
ENABLE_NUNIT directive so that f-spot can still build on systems without
nunit installed.
References and standards
* .desktop file specification:
* thumbnail caching:
Jump to Line
Something went wrong with that request. Please try again.