See also http://www.sacredchao.net/quodlibet/wiki/Development for
various proposals/roadmaps/guides.

Source Layout
-------------
browsers/*	- Things in the View menu
formats/*	- File format support
library/*	- Library management code
qltk/*		- GTK+ widget subclasses/extensions
tests/*		- Unit/regression tests
util/*		- General utility functions and setup code

If you want to get a full overview of QL's code, good places to start
are browsers/_base.py, formats/_audio.py, and library/_library.py.

Submitting Patches
------------------
If you don't follow these guidelines, your patch will be turned down.
The following will lead to an almost automatic rejection:
 * Mixing tabs and spaces.
 * Not using 4 space indents.
 * Lines longer than 79 characters.
 * Sending whole files rather than patches.

Currently we are limiting the code to features in PyGTK 2.8 and Python
2.4.

Please prepare your patches against the Subversion release, or the
most recent release. You can update a checked-out version to the
latest trunk using `svn switch' and `svn update'.

Translation
-----------
http://www.sacredchao.net/quodlibet/wiki/Development/Translation is
a detailed guide to handling translation. Don't be afraid to ask for
help on IRC or the mailing list.

Unit Tests
----------
Quod Libet comes with tests. To run them, run ./_sanity.sh. Your patch
can't break any unit tests, and if you change tests in a non-obvious way
(e.g. a patch that removes an entry point and also removes a test for it
is obvious) you should explain why.

These tests are not included in released versions, since they are fairly 
large and have more dependencies than Quod Libet itself.

Submitting
----------
If your patch fixes a known bug with a ticket, you should attach it to
the ticket directly. If it is a bug fix but doesn't have a ticket, you
can either make a ticket to attach it to, or send it to the mailing list,
quodlibet@lists.sacredchao.net.

The ticket tracker is at http://www.sacredchao.net/quodlibet/report
and at http://www.sacredchao.net/quodlibet/newticket.

Guidelines
----------
We prefer Python to C. We prefer ctypes to compiled C wrappers. A good way
to get a new feature applied is if you include tests for it. Stock
strings and string reuse are awesome, but don't make the interface
awkward just to avoid a new string.