X-Git-Url: http://git.openbox.org/?p=dana%2Fopenbox.git;a=blobdiff_plain;f=HACKING;h=e450bba39e8f5a0a3b351b1e09bf1197c1d8e914;hp=45104201d31c86c516f662e2d4e07e0c7443a2bf;hb=1ffc0021325e30db7bb7f8b2a17ca7f5546b3324;hpb=f26f23de50cb7941a7702198e3b4d1b2f9de062e

diff --git a/HACKING b/HACKING
index 4510420..e450bba 100644
--- a/HACKING
+++ b/HACKING
@@ -1,22 +1,13 @@
-Woop, a HACKING document for openbox at last!
-
 dirs:
-	kernel - core of the WM
+	openbox - core of the WM
 	render - librender, rendering routines for the WM and for apps
-	cwmcc  - client-wm-client communication. netwm/icccm helper routines
-		 for the WM and apps
-	obcf   - openbox config format, generic parser for config files
-	plugins - various plugins
+	parser - libparser, for parsing config files
 
 Beware the Client.transient_for. It can be set to a !NULL value of TRAN_GROUP,
 which is not a valid pointer. You must ALWAYS check for TRAN_GROUP before
-following transient_for. When TRAN_GROUP is found, Client.group will always
-be !NULL. Some smart action should be taken using all members of the group in
-this case.
-    Smart action idea:
-        Skip over members of the group that are also transients of the group
-        (have Client.transient_for set to TRAN_GROUP). These windows are not
-        ancestors and using them will also end up causing infinite loops!
+following transient_for. However if it is transient for the group, this
+excludes other windows whom are transient for the group, and windows which
+are children of the window (infinite loops would result)!
 
 When using coordinates/sizes of windows, make sure you use the right area. The
 Client.area rect is the reference point and size of the *CLIENT* window. This
@@ -25,3 +16,18 @@ translate it into what you see. The Client.frame.area is the actual position
 and size of the entire frame. This is usually the value you want to use, unless
 you are in client.c (probably) and adjusting/using the position or size from
 the client's perspective.
+
+Indentation
+-----------
+For openbox, we aim to have consistent coding style. Some, but surely
+not all, guidelines:
+ * use 4 space indents
+ * tabs should not appear in source files
+ * functions should have the opening and closing braces on their own
+   lines
+ * most other constructs should have braces on the same line as the
+   statement
+ * else appears on a new line, just like an if
+ * when in doubt look at the rest of the source
+ * vim users can use "set expandtab tabstop=4 shiftwidth=4
+   softtabstop=4" for some of this