git.sur5r.net Git - i3/i3.github.io/blob - index.html

   1 ---
   2 layout: default
   3 title: Your New Jekyll Site
   4 ---
   5
   6 <div id="info" class="clearfix">
   7
   8     <div id="screens">
   9         <a href="/screenshots/" title="view more screenshots of i3">
  10         <img id="screenshot" src="/screenshots/i3-9.bigthumb.png" width="375" height="234" alt="i3 screenshot"
  11          srcset="/screenshots/i3-12.bigthumb.jpg 2x">
  12         </a>
  13     </div>
  14
  15     <h2>Do What I Mean. Good Docs. Clean Code. Sounds good?</h2>
  16     <p>
  17     Then you will love i3. Watch the <a href="/screenshots/">screencast</a>,<br>
  18     read the <a href="/docs/userguide.html">User’s Guide</a> and <a
  19     href="/downloads/">install i3</a>!
  20     </p>
  21     <div id="download">
  22         <a href="/downloads">
  23         <span style="font-weight: bold; color: #3A8ECD; margin-right: .5em">➡</span>
  24         Download the latest version
  25         <span style="margin-left: 2em; color: #c0c0c0">4.14</span>
  26         </a>
  27     </div>
  28 </div>
  29
  30 <div id="content">
  31 <p>
  32 i3 is a <a href="http://en.wikipedia.org/wiki/Tiling_window_manager">tiling
  33 window manager</a>, completely written from scratch. The target platforms are
  34 GNU/Linux and BSD operating systems, our code is Free and Open Source Software
  35 (FOSS) under the BSD license. i3 is primarily targeted at advanced users and
  36 developers. Based upon the experiences we made when wanting to hack/fix wmii,
  37 we agreed upon the following goals for i3:
  38 </p>
  39
  40 <ol>
  41   <li>
  42     Write well readable, well <strong>documented</strong> code. Create additional
  43     documentation on how to extend i3 by explaining its internal workings.
  44     <br />
  45     This includes being modifiable by people who do know how to program but who are
  46     not necessarily familiar with all of X11’s internals. That is, document why
  47     things happen and when they happen so that the user gets a picture of the whole
  48     process a Window Manager is responsible of by just reading the source code.
  49   </li>
  50   <li>
  51     Use xcb instead of Xlib. xcb has a much cleaner API and should be faster in
  52     quite a lot of situations.
  53   </li>
  54   <li>
  55     Implement multi-monitor correctly, that is by assigning each workspace to a
  56     virtual screen. Especially make sure that attaching and detaching new monitors
  57     like video projectors works during operation and does the right thing. Also
  58     provide support for rotated monitors.
  59   </li>
  60   <li>
  61     Use a tree as data structure. This allows for more flexible layouts than
  62     the column-based approach used by other window managers.
  63   </li>
  64   <li>
  65     Implement different modes, like in vim. You can use different keybindings
  66     when in the 'resize' mode than when you are in the default mode, for
  67     example.
  68   </li>
  69   <li>
  70     Implement an IPC interface for other programs. Provide subscription to
  71     certain events and accept commands.
  72     <br />
  73     This approach should be more lightweight than wmii’s usage of the 9P filesystem.
  74     Furthermore, core functionality does not depend on a separate program, so that i3
  75     runs faster, especially when your system is under load.
  76   </li>
  77   <li>
  78     Be UTF-8 clean.
  79   </li>
  80   <li>
  81     The usual elitism amongst minimal window managers: Don’t be bloated, don’t be fancy
  82     (simple borders are the most decoration we want to have).
  83     <br />
  84     However, we do not enforce unnecessary limits such as a maximum amount of source lines
  85     of code. If it needs to be a bit bigger, it will be.
  86   </li>
  87 </ol>
  88
  89 <p>
  90 In addition to these stated goals, we try our best to uphold the following
  91 values when considering contributions to the project:
  92 </p>
  93
  94 <ul>
  95   <li>
  96     Never break configuration files or existing workflows. Breaking changes
  97     require a major version bump (v4 → v5).
  98   </li>
  99   <li>
 100     Keep mental complexity low: once you know i3’s key features, other features
 101     should be easy to understand.
 102   </li>
 103   <li>
 104     Only add features which benefit many people, instead of going to great
 105     lengths to support rarely used workflows.
 106   </li>
 107   <li>
 108     Only documented behavior is supported. Clear documentation is a requirement
 109     for contributions.
 110   </li>
 111 </ul>
 112
 113 </div>