With this commit, the "default" layout is replaced by the splith and
splitv layouts. splith is equivalent to default with orientation
horizontal and splitv is equivalent to default with orientation
vertical.
The "split h" and "split v" commands continue to work as before, they
split the current container and you will end up in a split container
with layout splith (after "split h") or splitv (after "split v").
To change a splith container into a splitv container, use either "layout
splitv" or "layout toggle split". The latter command is used in the
default config as mod+l (previously "layout default"). In case you have
"layout default" in your config file, it is recommended to just replace
it by "layout toggle split", which will work as "layout default" did
before when pressing it once, but toggle between horizontal/vertical
when pressing it repeatedly.
The rationale behind this commit is that it’s cleaner to have all
parameters that influence how windows are rendered in the layout itself
rather than having a special parameter in combination with only one
layout. This enables us to change existing split containers in all cases
without breaking existing features (see ticket #464). Also, users should
feel more confident about whether they are actually splitting or just
changing an existing split container now.
As a nice side-effect, this commit brings back the "layout toggle"
feature we once had in i3 version 3 (see the userguide).
AFAIK, it is safe to use in-place restart to upgrade into versions
after this commit (switching to an older version will break your layout,
though).
Fixes#464
See also:
http://article.gmane.org/gmane.linux.kernel/1268792
The C compiler will handle (void) as "no arguments" and () as "variadic
function" (equivalent to (...)) which might lead to subtle errors, such
as the one which was fixed with commit 0ea64ae4.
- Introduce warp_to static variable in x.c that stores the coordinates
to warp to as a Rect.
- Add x_set_warp_to function to set this variable. Use in _tree_next,
workspace_show, and con_move_to_workspace.
- In x_push_chanages, if warp_to is set, then call xcb_warp_pointer_rect
and then reset it to NULL.
This fixes all know bugs for pointer warping for me.
Generally, the traversal goes: numbered workspaces in order, and then
named workspaces in the order in which they appear in the tree.
Example:
Output 1: Output 2:
1 3 D C 2 4 B A
Traversal: 1, 2, 3, 4, D, C, B, A, 1, ...
Note, after the numbered workspaces, we traverse the named workspaces
from output 1, and then output 2, etc.
Use 'kill window' to kill a specific window (for example only one specific
popup), use 'kill client' to kill the whole application (or X11 connection to
be specific).
Due to lots of cases which were added and added to tree_move(), the function
was not really easy to understand. For this refactoring, I wrote tree_move()
from scratch, thinking about (hopefully) all cases. The testsuite still passes.
The move command also has different parameters now. Instead of the hard to
understand 'before v' stuff, we use 'move [left|right|up|down]'.
Numbered workspaces (workspaces with a name containing only digits) will be
inserted in the correct order now. Named workspaces are always sorted after
numbered workspaces and in the order of creation.
The implementation works like this:
Containers can have a 'sticky-group' attribute. Imagine two different
containers (on two different workspaces) which have the same sticky-group.
Now you open a window in the first container. When you switch to the
other workspace, the window will be re-assigned to the other container.
An obvious problem which is not covered with the code at the moment is
having two containers with the same sticky-group visible at the same time.
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.
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!
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).
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.
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.
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.
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