See also http://code.google.com/p/quodlibet/wiki/Development for
various proposals/roadmaps/guides.

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

tests/*		- Unit/regression tests

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.

Printing Text
-------------
All terminal output should go through the print_, print_w, print_e,
or print_d functions. These will handle Unicode recoding. They also
let us capture all output for debugging purposes.

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.10 and
Python 2.4.

Please prepare your patches against the latest Mercurial release,
or the most recent release.

Translation
-----------
http://code.google.com/p/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 ./setup.py test. 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.

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,
quod-libet-development@googlegroups.com.

The ticket tracker is at http://code.google.com/p/quodlibet/issues/list
and at http://code.google.com/p/quodlibet/issues/entry.

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.
