HACKING

   1 Bug tracking system
   2 ===================
   3
   4 Thunar uses the Xfce bug tracking system at http://bugzilla.xfce.org/,
   5 hosted and maintained by the Xfce project.
   6
   7
   8 Patches
   9 =======
  10
  11 Please submit patches to the Xfce bug tracking system or to the thunar-dev
  12 mailinglist. Your patch should be in unified diff format (the -u option
  13 to GNU diff) and it must comply with the coding style described below.
  14
  15 Please send a patch against a recent version of this package. Patches
  16 against the Git master branch are most preferable. You can always
  17 clone the Thunar repository from
  18
  19   http://git.xfce.org/git/xfce/thunar
  20
  21
  22 Feature requests
  23 ================
  24
  25 Please file feature requests to the Xfce bug tracking system
  26 (http://buzilla.xfce.org, product Thunar) with a Severity of
  27 enhancement. Make sure that your feature request wasn't reported
  28 already before; requesting a feature several times won't increase
  29 the changed that it gets added!
  30
  31
  32 Coding Style
  33 ============
  34
  35  - GNU coding conventions, with GLib-like extensions, mostly the same
  36    as GTK+.
  37  - Always expand tabs. This differs from the GNU suggestion, but it is
  38    necessary to be independent from a given tab setting.
  39  - Do NOT ever misuse debugging macros like g_return_val_if_fail() or
  40    g_return_if_fail() to control program flow. They are solely useful
  41    to discover bugs, the final binary won't include code for these
  42    statements, and so any use of these macros to control program
  43    flow presents a bug!
  44  - Do NOT follow the philosophy "If it works, it's right" that most
  45    other open source projects follow, instead Thunar's philosophy is
  46    "It doesn't work unless it's right". Think carefully of what you want
  47    to do, don't just fire up your favourite editor and start hacking
  48    in the hope that it will evolve into something useful one day.
  49  - Maintainability goes over performance. If you have to choose between
  50    a maintainable and a fast solution, always prefer the former, as it's
  51    quite easy to optimize well-designed modules, but very hard and costly
  52    to make spaghetti-code readable.
  53  - Write ChangeLog entries. Whenever you commit a change or send a patch,
  54    write a good entry per change to the ChangeLog file, see the libexo
  55    ChangeLog for the exact format; it's very important to be descriptive
  56    and correct here, else you'll loose your commit bits or your patches
  57    won't be considered for inclusion.
  58  - Use GObject whenever possible. Object-oriented design and programming
  59    makes it easier to separate functionality and also aids in verification
  60    and testing, and GObject provides a very solid base.
  61
  62
  63 Release process
  64 ===============
  65
  66 Yet to be defined!