File: HACKING

package info (click to toggle)
xfce4-panel 4.3.99.2-2
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k
  • size: 6,000 kB
  • ctags: 2,052
  • sloc: ansic: 17,370; sh: 8,587; xml: 2,908; makefile: 804
file content (49 lines) | stat: -rw-r--r-- 1,885 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
This file describes the coding style I prefer for the panel. If you want to
help out with panel development, please try to conform to these 'rules'.
-- Jasper

* 2005-1-3

Somewhere in the past year I decided to expand tabs, to make sure there's no
misunderstanding in how I want things to look.


* 2003-05-17

Updated the .indent.pro to use Olivier's new version. He seems he conformed to
my standards this time ;-)) (<-- this is a joke, please laugh) Anyway, his new
version has all the things I find important.


* 2003-04-02

If you are interested in working on the panel that is of course enormously
appreciated. I would like to ask you to follow a small number of rules to ease
the maintainer's job a little.

- Please use the .indent.pro file provided in this directory to format your
  files. Since we didn't seem to agree on a common coding style for the entire
  project I took the liberty to adapt Olivier's file (found in xfwm4/src/) a
  little to better suit my own taste. The most important aspects are:
  o indentation is 4 spaces (which does not equal 1 tab!)
  o braces are on a new line
  o return type for function definitions on separate line

- If you have CVS access it's alright to commit bugfixes or trivial changes to 
  CVS directly. But please send a patch to the mailing list for any 
  non-trivial and/or non-obvious changes for discussion. When in doubt, ask 
  first. Make patches by running `cvs diff -u > <patchfile>'.

- Patches are always welcome please use `diff -Naur <oldfile> <newfile>' to
  create them or use the cvs method mentioned above. You can send them to the 
  mailing list for discussion.

If we all stick to these guidelines I'm sure the code will remain as clean and
readable as it it today (Ahem ... ;).

Look at the README and TODO for a bit more information, but be careful, it may
not be entirely up to date.

Thanks,
	Jasper