X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=docs%2Fhacking-howto.html;h=755c732dfa984acabec8eae5a1bdc2e20cd8f846;hb=eee149f9ffa4fe019179bd14159eb0a4bd3762c0;hp=ad5900eed09c34c0906a8f228213ac0515747f6e;hpb=ce4b1dcccd3cc39ecf7e8340cc90dfe736d54781;p=i3%2Fi3.github.io diff --git a/docs/hacking-howto.html b/docs/hacking-howto.html index ad5900e..755c732 100644 --- a/docs/hacking-howto.html +++ b/docs/hacking-howto.html @@ -4,13 +4,13 @@ - + i3: Hacking i3: How To @@ -78,7 +78,8 @@ 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

  • @@ -133,7 +134,7 @@ moving/resizing windows while you usually want to get some work done. After all, most users sooner or later tend to lay out their windows in a way which corresponds to tiling or stacking mode in i3. Therefore, why not let i3 do this for you? Certainly, it’s faster than you could ever do it.

    -

    The problem with most tiling window managers is that they are too unflexible. +

    The problem with most tiling window managers is that they are too inflexible. In my opinion, a window manager is just another tool, and similar to vim which can edit all kinds of text files (like source code, HTML, …) and is not limited to a specific file type, a window manager should not limit itself to a certain @@ -191,19 +192,12 @@ picture, either browse all header files or use doxygen if you prefer that).

    -src/cfgparse.l +src/config_parser.c

    -Contains the lexer for i3’s configuration file, written for flex(1). -

    -
    -
    -src/cfgparse.y -
    -
    -

    -Contains the parser for i3’s configuration file, written for bison(1). +Contains a custom configuration parser. See src/command_parser.c for rationale + on why we use a custom parser.

    @@ -216,19 +210,13 @@ clicks initiate resizing and thus are relatively complex).

    -src/cmdparse.l -
    -
    -

    -Contains the lexer for i3 commands, written for flex(1). -

    -
    -
    -src/cmdparse.y +src/command_parser.c

    -Contains the parser for i3 commands, written for bison(1). +Contains a hand-written parser to parse commands (commands are what +you bind on keys and what you can send to i3 using the IPC interface, like +move left or workspace 4).

    @@ -379,6 +367,15 @@ Contains the functions to resize containers.

    +src/restore_layout.c +
    +
    +

    +Everything for restored containers that is not pure state parsing (which can be +found in load_layout.c). +

    +
    +
    src/sighandler.c
    @@ -682,7 +679,7 @@ The override_redirect must not be set. Windows with override_redirect shall

    • -

    Afterwards, i3 gets the intial geometry and reparents the window (see +

    Afterwards, i3 gets the initial geometry and reparents the window (see reparent_window()) if it wasn’t already managed.

    Reparenting means that for each window which is reparented, a new window, slightly larger than the original one, is created. The original window is then @@ -703,7 +700,7 @@ target workspace is not visible, the window will not be mapped.

    9. What happens when an application is started?

    -

    i3 does not care for applications. All it notices is when new windows are +

    i3 does not care about applications. All it notices is when new windows are mapped (see src/handlers.c, handle_map_request()). The window is then reparented (see section "Manage windows").

    After reparenting the window, render_tree() is called which renders the @@ -875,7 +872,7 @@ position/size is different: They are placed next to each other on a single line

    14.3.4. Dock area layout

    -

    This is a special case. Users cannot chose the dock area layout, but it will be +

    This is a special case. Users cannot choose the dock area layout, but it will be set for the dock area containers. In the dockarea layout (at the moment!), windows will be placed above each other.

    @@ -1485,9 +1482,11 @@ Forgetting to call floating_fix_coordinates(con, old_rect, new_rect) af

    20. Using git / sending patches

    +
    +

    20.1. Introduction

    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

    +http://web.archive.org/web/20121024222556/http://www.spheredev.org/wiki/Git_for_the_lazy +or, for more documentation, see http://git-scm.com/documentation

    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.

    @@ -1500,6 +1499,17 @@ 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.

    +
    +

    20.2. Which branch to use?

    +

    Work on i3 generally happens in two branches: “master” and “next”. Since +“master” is what people get when they check out the git repository, its +contents are always stable. That is, it contains the source code of the latest +release, plus any bugfixes that were applied since that release.

    +

    New features are only found in the “next” branch. Therefore, if you are working +on a new feature, use the “next” branch. If you are working on a bugfix, use +the “next” branch, too, but make sure your code also works on “master”.

    +
    +

    21. Thought experiments