Before this commit, i3 used key bindings in SYNC mode for bindings
like Mode_switch + <a> and replayed the key if the current state
did not include Mode_switch. This had some problems:
1) The WM needed to acknowledge much more key presses than you
actually had bindings for, thus making the system a bit laggy
sometimes.
2) Users of layouts who constantly type in the third level (like
russian layouts) did not get their cyrillic symbols correctly
(they were not replayed right), neither did the keybindings
work in both modes.
So, the current implementation uses the following approach: XKB
provides an event which contains the current state (including
the current level). i3 signs up for this event and upon receival,
it re-maps the bindings using Mode_switch (enables them when the
level goes to the third level and disables them as soon as the
level goes back to normal). This fixes both problems.
visible == currently visible on the output it is on
(multiple workspaces can be visible at the same time)
focused == has the focus (only one workspace can be focused)
This is the foundation to use dzen2 or similar as a complete
replacement for the internal workspaces bar.
A testcase is included, more documentation about the IPC interface
will follow.
This fixes ticket #100, and is best explained using a little example.
Consider the following layout:
+---+---+
| | X |
+---+---+
| X |
+---+---+
Where X marks a window, so you have an empty container in the upper
left, the container on the bottom is snapped to the right. Before
this commit, nothing would happen when focusing "above". After
this commit, the upper window gets focused.
This fixes ticket #173, at least for the rendering errors.
I don’t really know why I implemented predict_text_width like it
was before (querying the whole table and pulling out information
one by one). Maybe I have overlooked xcb_query_text_extents. In
any case, it works better now.
Add --force-xinerama when starting i3 to use Xinerama instead of RandR.
This should *ONLY* be done if you have no other choice (nvidia’s
binary driver uses twinview and does not expose the monitor information
through RandR).
This enables compilation with llvm-clang and thus closes ticket #101.
While it makes the code more ugly, I don’t see a beautiful solution
which would enable us to stay with the more elegant solution of
nested functions and still allow compilation with any other compiler
than gcc.
Thanks to Merovius for doing a proof of concept on this one and
being a driving force behind the idea.
Using RandR instead of Xinerama means that we are now able to use
the full potential of the modern way of configuring screens. That
means, i3 now has an idea of the outputs your graphic driver
provides, which allowed us to get rid of the ugly way of detecting
changes in the screen configuration which we used before. Now, your
workspaces should not be confused when changing output modes anymore.
Also, instead of having ugly heuristics to assign your workspaces
to (the screen at position X or the second screen in the list of
screens) you will be able to just specify an output name.
As this change basically touches everything, you should be prepared
for bugs. Please test and report them!
Michael Stapelberg