Even though i3 cannot know the width/height of some workspaces as
long as they are not initialized (say you used workspace 1 and 3,
but not workspace 2), some applications require this information.
In this case, it was Firefox which intersects the available workareas
(see mozilla/gfx/src/gtk/nsScreenGtk.cpp) and did not position some
windows correctly when being confronted with zero-width/height
workspaces.
Please note that rdesktop’s -g workarea option will not work on
64-bit systems at the moment because of a bug in rdesktop (see the
rdesktop-devel mailing list).
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 bug could happen if you have floating and tiling windows (for
example Firefox in tiling mode and its Open dialog in autmatically
floating mode) and you opened a new tiling window while in fullscreen.
i3 would then place the window below the floating windows, but
floating clients are above fullscreen windows. Thus, the client
would be placed above the fullscreen window.
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.
Minimum width/height was not consistent with the limit for grabbing
and resizing a window at its border.
If one of both was violated (width < min_width for example), none
of them were updated.
Calculations were wrong (they simply didn’t take into account that
there is more than one border style, the code was from before we
implemented that…). We cannot directly set child_rect to the coordinates
as resize_client takes rect and calculates the child_rect, so we need
the new lines of code for this bugfix in any case (rect needs to be
updated).
The welcome message is displayed using xmessage(1), not using your
terminal. Thus, it makes no sense to have this option anymore. Also,
the new lex/yacc parser cannot correctly handle the situation:
normal variables are expanded before parsing the file. As a replacement,
you can use:
set $terminal /usr/bin/urxvt
This did not happen all the time. It seems like you need to have a
container which is in stacking/tabbing mode on the screen which
is being reconfigured. (when doing xrandr --output VGA1 --off for
example)
When the sending application was so fast (*cough*) that the messages
could get queued by the kernel, it may happen that we receive multiple
messages at once.
Sometimes, it may happen that the focus is "nowhere" and thus the
user is stuck. This was often the case with opera, sometimes with
pcmanfm. See ticket #118.
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…
As the workspaces are now created dynamically, we cannot rely on
the workspaces to be there when we need them without creating them.
On the other hand, this eliminates the case that there are no workspaces
to assign to a new screen, because now we can just create one.
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.
For example, you can create a mode which will let you resize windows
with some easy to use keys. So, instead of binding a combination
of your homerow and modifiers to resize, like this:
bind Mod4+44 resize right +10
bind Mod4+45 resize right -10
...
You can instead define a new mode:
mode "resize" {
bind 44 resize right +10
bind 45 resize right -10
...
bind 36 mode default
}
bindsym Mod4+r mode resize
So, if you press Mod4+r now, your keybindings will be set to the ones
defined in your resize mode above. You can then use your homerow
(without any other modifier) to resize the current column/row and
press enter to go back to the default mode when you are done.
Note that using this option requires you to enable the new lexer/parser
by passing the -l flag 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.
We now use the virtual screen’s size/position instead of the X root
window for the grabwin (grabwin = the area in which the pointer may
move when resizing).
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.
Commands are 'mark' and 'goto'. Both can be used either directly,
like 'mark a' and 'goto a', or interactively (just 'mark'). For
interactive mode, i3-input must be installed and in your PATH.
This warning only showed up with CFLAGS=-O2.
The variables in question could never be uninitialized because
they were definitely set, have a look at the code. But anyways,
less warnings is always a good thing ;-).
This is necessary because otherwise the window into which the
pointer is warped still is at its old position, so that the pointer
will effectively be warped onto the wrong screen in case of moving
a window to another screen.
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).
Michael Stapelberg