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!
Starting from this commit, a borderless window will always be
borderless if it is the only window in a container. For example,
you can have Firefox borderless in a tabbed container and as soon
as the download manager or a viewer gets opened, the container
will be rendered like a normal tabbed container.
This solves the user-interface dilemma of borderless/1-px-border
windows inside stacked/tabbed containers, at least for this special
case. Thanks to Merovius for this suggestion.
When having 8 windows in a container which has 766 px available,
you ended up losing 0,75 px per window which would quickly sum up.
Now, the rest space (6 px in this example) is distributed in units
of one pixel to as many windows as possible.
This prevents errors in rounding leading to an unoccupied space of
-1 which in turn leads to infinity when calculating the new size
of a container after resizing.
This fixes many problems we were having with a dynamically growing
array because of the realloc (pointers inside the area which was
allocated were no longer valid as soon as the realloc moved the
memory to another address).
Again, this is a rather big change, so expect problems and enable
core-dumps.
This is necessary now, because when creating a new row, several
containers have to be created. Since the implementation of the default
mode for containers, this also involves rendering the layout. However,
when rendering the layout, all of the containers are potentially
accessed…
The following new directives have been implemented for the configuration
file:
new_container <default|stacking|tabbed>
new_container stack-limit <cols|rows> <value>
Note that they require using the new lexer/parser, which you can
do by passing -l to i3 when starting.
Warning: This is not yet thoroughly tested, so be prepared to
encounter some segfaults. Please enable logging and coredumps,
so we can fix bugs quickly.
xterm by default sets a border_width of 2. This was not taken into
account when determining the size of the window by i3. Still, you
probably want to set this to 0 in your .Xresources as the pixels
are just lost.
Using this command, you can limit the amount of columns or rows for
a stacking container. This allows for better usage of screen estate
when using stacking containers with many clients.
Examples:
i3-msg "stack-limit cols 2"
You will now have a stack window which has two columns of windows.
Thanks to Mikael for bringing it to my mind. This change introduces
two new color classes, client.urgent and bar.urgent. By default,
urgent clients are drawn in red (colors by Atsutane).
Before this fix, you could go upwards and select the screen which
was at the rightmost because it also was the one topmost (if all
screen’s top position is equal).
Please test this! Plug in screens, unplug them, use your video projector,
change resolutions, etc.
To use the assignments, use the following syntax:
workspace <number> [screen <screen>] [name]
Where screen can be one of:
<number> (It is not provided that these numbers stay constant, so use with care)
<x>x<y> (Coordinates where the screen starts, so 1280 will be fine to match the
screen right of the main screen if your main screen is 1280 pixels
width. However, 1281 will not match)
<x>
x<y>
Some examples follow:
workspace 1 screen 0
workspace 1 screen 1
workspace 1 screen 1280x0
workspace 2 screen 1280
workspace 3 screen x0
workspace 3 screen 1 www
workspace 4 screen 0 mail
Use bn (normal), bp (1-px), bb (borderless) as commands to change the
border style of the currently focused window. Feel free to use i3-msg
to do this.
Thus, no more flickering because the window was first mapped and then
moved. Especially users of multiple monitors should be happy now ;-).
Rather radical change, though, so be prepared for problems.
Also update documentation (manpage, userguide).
To make the code easier to read/write when checking if a client is
floating, introduce client_is_floating().