git pull-
-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
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 @@ -152,7 +153,7 @@ the same split container, which uses the default layout. In case of an empty 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.
-Contains the lexer for i3âs configuration file, written for flex(1). -
--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.
-Contains the lexer for i3 commands, written for flex(1). -
--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).
-Handles the setting of loglevels, contains the logging functions. +Contains the logging functions.
+Everything for restored containers that is not pure state parsing (which can be +found in load_layout.c). +
+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.
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
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.
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.
First of all, update your working copy to the latest version of the master -branch:
git pull-
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.
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.
When working on bugfixes, please make sure you mention that you are working on +it in the corresponding bugreport at https://github.com/i3/i3/issues In case +there is no bugreport yet, please create one.
After you are done, please submit your work for review at https://github.com/i3/i3
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.
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â.