GIT

---

F-Spot's source repository is in GNOME GIT, in the module 'f-spot'.

For information on GNOME GIT, see:

http://live.gnome.org/Git

If you are not familiar with GIT, please read this page:

http://live.gnome.org/Git/Developers

Patches

-------

If you have a patch you'd like to submit, please open a bug describing your fix

or feature on bugzilla.gnome.org (product 'f-spot'), and submit a merge request

on Gitorious (http://gitorious.org/f-spot). The selection below describes how

to do so:

First, clone our git repository ("git clone git://git.gnome.org/f-spot"), 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:

    http://gitorious.org/f-spot/mainline 

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:

    git@gitorious.org:~yourusername/f-spot/yourusernames-clone.git

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

away.

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

HACKING file.

* 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 

        problem.

        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))

                                continue;

                        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:

                        good:

                                if (a) {

                                        Code ();

                                        Code ();

                                }

                        bad:

                                if (a) 

                                {

                                        Code ();

                                        Code ();

                                }

                * Avoid using unecessary open/close braces, vertical space

                  is usually limited:

                        good:

                                if (a)

                                        Code ();

                        bad:

                                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:

                        good:

                                void Method ()

                                {

                                }

                        bad:

                                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.

                        good:

                                int Property {

                                        get {

                                                return value;

                                        }

                                }

                        bad:

                                int Property 

                                {

                                        get {

                                                return value;

                                        }

                                }

                  Notice how the accessor "get" also keeps its brace on the same

                  line.

                  For very small properties, you can compress things:

                        ok:

                                int Property {

                                        get { return value; }

                                        set { x = value; }

                                }

                * Use white space in expressions liberally, except in the presence

                  of parenthesis:

                        good:

                                if (a + 5 > Method (Blah () + 4))

                        bad:

                                if (a+5>Method(Blah()+4))

                * For any new files, please use a descriptive introduction, like

                  this:

                        //

                        // System.Comment.cs: Handles comments in System files.

                        //

                        // Author:

                        //   Juan Perez (juan@address.com)

                        //

                        // (C) 2002 Address, Inc (http://www.address.com)

                        //

                * Switch statements have the case at the same indentation as the

                  switch:

                        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 ()

  (java-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))

			      auto-mode-alist))

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: http://standards.freedesktop.org/desktop-entry-spec/latest/index.html

* thumbnail caching: http://people.freedesktop.org/~vuntz/thumbnail-spec-cache/