Developer's Corner

Welcome to the xine Developer's Corner page.

This page is intended to be a directory of everything to do with xine development. If you're looking for information about creating new software using xine library or adding multimedia capabilities to your existing application, check out our language bindings and sample code pages.

If you're looking to work on the xine library to add new features or fix or improve the existing multimedia capabilities, we suggest that you start reading the xine Hacker's Guide. Also consider subscribing to xine-devel mailing list to discuss your ideas.

Regardless, developers do need to know at least the rules (below).

Developer's FAQ

Q: How do I make a debug build of xine?

A: Start with a clean build (if in doubt, use 'make clean'). Then do 'make debug' and 'make install-debug'. This procedure is valid for xine-lib, xine-ui and gxine.

Q: How do I run xine in gdb?

A: First make sure you have a debug build. You can either run xine from gdb or attach to an already-running process:

  • Running xine from gdb:

    $ gdb xine
    (gdb) handle SIG32 noprint nostop
    (gdb) run

  • Attaching to a running xine process:

    $ gdb xine `pidof xine`

Q: How do I run xine in valgrind?

A: Just as for running xine under gdb (above), you will need debug builds of both xine and xine-lib for this to be useful.

  • Disabling acceleration

    $ export XINE_NO_ACCEL=1
    $ valgrind --tool=memcheck xine

    You can substitute memcheck with other valgrind skins, see the Valgrind documentation for details.

A few rules

Developers are encouraged to be present in #xine on OFTC and, optionally, Freenode.

Code style

  • Try to match the style of the surrounding code.
  • Tabs should not be used. If they are, then remember that tab stops are every 8th column.
  • No trailing spaces or camelCase.
  • If unsure: K&R 1TBS, 2 space indent.

Committing code changes

  • Make sure that the first line (up to the first line feed) is a complete short description of the patch.
  • Large or intrusive changes should be discussed first. (Staging repositories or branches are fine for testing purposes.)
  • Add to the changelog if you think that your change warrants it.
  • Make sure that unrelated changes are in separate commits.
  • Split (large) cosmetic changes from functional ones. Otherwise, keep cosmetic changes relevant to the functional changes.
  • For those with commit access:
    • Always use hg push to make your changes public.
    • Ensure that you have the following in your ~/.hgrc on vasks.debian.org: 
      [trusted]
users = dsalt-guest
      Without this, commit messages won't be posted on our IRC channels (and, sooner or later, you'll be asked about it). (But see also here.)
  • The best ways to publish your patches for review or for commit are to have a public repository or to use hg email to send the patches to xine-devel.

What's allowed where

xine-lib 1.2

  • 1.2 is the current development and primary release branch. API and ABI extensions will be considered, but anything which breaks existing API or ABI will be rejected; if you need to change either, it's probably time to open a 1.3 branch.
  • Do not commit here if the change is also for 1.1. Commit to 1.1 instead and merge into 1.2. (Merging need not be done immediately.)

xine-lib 1.1

  • 1.1 is in maintenance mode. Changes should be restricted to bug fixes and clean-ups, but new code may be considered if the case for it is compelling enough.

Front ends

  • If you make a change to xine-ui or to gxine and the change seems appropriate also for the other front end, by all means make the change there too.