40 lines
1.7 KiB
Text
40 lines
1.7 KiB
Text
Woop, a HACKING document for openbox at last!
|
|
|
|
dirs:
|
|
kernel - core of the WM
|
|
render - librender, rendering routines for the WM and for apps
|
|
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!
|
|
|
|
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
|
|
value is not what you see in any shape or form, and gravity is applied to it to
|
|
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
|
|
* 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
|
|
|
|
|