X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=index.html;h=296498c222f1bff0c21022fda753673d67849b63;hb=fc11b655b554b831dada17c5140ffc86cd689ede;hp=8a45f7faf1456868e5a7d4c333e967e22aa080b9;hpb=33e2f35c88b59de01d3ece1f4460e781aa99d11a;p=i3%2Fi3.github.io
diff --git a/index.html b/index.html
index 8a45f7f..296498c 100644
--- a/index.html
+++ b/index.html
@@ -22,7 +22,7 @@ title: Your New Jekyll Site
â¡
Download the latest version
- 4.9.1
+ 4.14.1
@@ -48,9 +48,8 @@ we agreed upon the following goals for i3:
process a Window Manager is responsible of by just reading the source code.
- Use xcb as far as possible (it does not provide functions for some features
- yet, like XKB) instead of Xlib. xcb has a much cleaner API and should be faster
- in quite a lot of situations.
+ Use xcb instead of Xlib. xcb has a much cleaner API and should be faster in
+ quite a lot of situations.
Implement multi-monitor correctly, that is by assigning each workspace to a
@@ -67,12 +66,6 @@ we agreed upon the following goals for i3:
when in the 'resize' mode than when you are in the default mode, for
example.
-
- Do not use programs such as autoconf/automake for configuration and
- creating unreadable/broken makefiles. Instead, use a clean makefile which automatically
- enables/disables features for specific platforms. Also, document the dependencies
- properly, so that package maintainers have an easy job packaging i3.
-
Implement an IPC interface for other programs. Provide subscription to
certain events and accept commands.
@@ -92,5 +85,29 @@ we agreed upon the following goals for i3:
of code. If it needs to be a bit bigger, it will be.
+
+
+In addition to these stated goals, we try our best to uphold the following
+values when considering contributions to the project:
+
+
+
+ -
+ Never break configuration files or existing workflows. Breaking changes
+ require a major version bump (v4 â v5).
+
+ -
+ Keep mental complexity low: once you know i3âs key features, other features
+ should be easy to understand.
+
+ -
+ Only add features which benefit many people, instead of going to great
+ lengths to support rarely used workflows.
+
+ -
+ Only documented behavior is supported. Clear documentation is a requirement
+ for contributions.
+
+