repositories: mention debian stable-backports (Thanks Alex)

[i3/i3.github.io] / _docs / hacking-howto

diff --git a/_docs/hacking-howto b/_docs/hacking-howto
index 73ae96335991d5312e1b61b5a0c265be8a16926f..633c277165f40b3a4d22315573367f0b2641f31b 100644 (file)
--- a/_docs/hacking-howto
+++ b/_docs/hacking-howto
@@ -1,7 +1,7 @@
 Hacking i3: How To
 ==================
-Michael Stapelberg <michael+i3@stapelberg.de>
-July 2011
+Michael Stapelberg <michael@i3wm.org>
+February 2013
 
 This document is intended to be the first thing you read before looking and/or
 touching i3’s source code. It should contain all important information to help
@@ -28,7 +28,8 @@ In the case of i3, the tasks (and order of them) are the following:
   the first client of X) and manage them (reparent them, create window
   decorations, etc.)
 . When new windows are created, manage them
-. Handle the client’s `_WM_STATE` property, but only the `_WM_STATE_FULLSCREEN`
+. Handle the client’s `_WM_STATE` property, but only `_WM_STATE_FULLSCREEN` and
+  `_NET_WM_STATE_DEMANDS_ATTENTION`
 . Handle the client’s `WM_NAME` property
 . Handle the client’s size hints to display them proportionally
 . Handle the client’s urgency hint
@@ -77,7 +78,7 @@ workspace, the split container we are talking about is the workspace.
 
 To get an impression of how different layouts are represented, just play around
 and look at the data structures -- they are exposed as a JSON hash. See
-http://i3wm.org/docs/ipc.html#_get_tree_reply for documentation on that and an
+http://i3wm.org/docs/ipc.html#_tree_reply for documentation on that and an
 example.
 
 == Files
@@ -141,7 +142,7 @@ src/load_layout.c::
 Contains code for loading layouts from JSON files.
 
 src/log.c::
-Handles the setting of loglevels, contains the logging functions.
+Contains the logging functions.
 
 src/main.c::
 Initializes the window manager.
@@ -947,31 +948,20 @@ For a short introduction into using git, see
 http://www.spheredev.org/wiki/Git_for_the_lazy or, for more documentation, see
 http://git-scm.com/documentation
 
-When you want to send a patch because you fixed a bug or implemented a cool
-feature (please talk to us before working on features to see whether they are
-maybe already implemented, not possible for some some reason, or don’t fit
-into the concept), please use git to create a patchfile.
+Please talk to us before working on new features to see whether they will be
+accepted. There are a few things which we don’t want to see in i3, e.g. a
+command which will focus windows in an alt+tab like way.
 
-First of all, update your working copy to the latest version of the master
-branch:
+When working on bugfixes, please make sure you mention that you are working on
+it in the corresponding bugreport at http://bugs.i3wm.org/. In case there is no
+bugreport yet, please create one.
 
---------
-git pull
---------
+After you are done, please submit your work for review at http://cr.i3wm.org/
 
-Afterwards, make the necessary changes for your bugfix/feature. Then, review
-the changes using +git diff+ (you might want to enable colors in the diff using
-+git config diff.color auto+).  When you are definitely done, use +git commit
--a+ to commit all changes you’ve made.
-
-Then, use the following command to generate a patchfile which we can directly
-apply to the branch, preserving your commit message and name:
-
------------------------
-git format-patch origin
------------------------
-
-Just send us the generated file via email.
+Do not send emails to the mailing list or any author directly, and don’t submit
+them in the bugtracker, since all reviews should be done in public at
+http://cr.i3wm.org/. In order to make your review go as fast as possible, you
+could have a look at previous reviews and see what the common mistakes are.
 
 == Thought experiments