The implementation is naive because the user has to generate exactly the
event he specified. That is, if you use this binding:
bindsym --release $mod+x exec import /tmp/latest-screenshot.png
Then it will only be triggered if you hit $mod, hit x, release x,
release $mod. It will not be triggered if you hit $mod, hit x, release
$mod, release x. The reason is that the KeyRelease event in the latter
case will not have the modifier in its flags, so it doesn’t match the
configured binding.
This changes the fact that Firefox would not be launched on the correct
workspace because it marked the startup sequence as completed *before*
actually mapping all of its windows.
To test this, go to workspace 3 and run this command in a terminal:
i3-msg 'exec iceweasel; workspace 4'
That will make i3 start iceweasel (and create a proper startup
notification context for it), then immediately switch to workspace 4
(before iceweasel could possibly start).
The iceweasel window(s) should appear on workspace 3.
While this is a bit ugly, it makes the log messages end up where they
are supposed to: in the shmlog/stdout in case of i3 and on stdout in
case of utilities such as i3-input
This changes the SHM log format, it doesn’t use 0-bytes to separate
entries anymore. Instead of using lots of printf() calls in i3-dump-log,
we now do precisely one big write().
So, to be clear: i3-dump-log and i3 both need to be upgraded.
Mismatching versions will lead to garbage output (no crashes of i3, just
garbage output).
The -f flag uses an inter-process pthread_cond_t in the shared memory
header to broadcast the arrival of new messages to all i3-dump-log
processes. This internally uses futexes and thus doesn’t even mean a
kernel call in most cases. inter-process pthread_cond_ts require NPTL
(the Native Posix Thread Library, introduce in Linux 2.6).
From the source:
When starting i3 initially (and after each change to the connected
outputs), this function fixes the resolution of the __i3
pseudo-output. When that resolution is not set to a function which
shares a common divisor with every active output’s resolution,
floating point calculation errors will lead to the scratchpad window
moving when shown repeatedly.
fixes#632
This is useful for third-party scripts which require certain features
and want to error out cleanly when they are run with an old i3 version.
Additionally, i3 --version might be different from what’s actually
running (an old version of the binary), so i3-msg -t get_version will be
the best way to figure out the i3 version you are actually running from
this commit on.
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
e.g. pressing Mod1+x when having the following in your configfile:
bindsym Mod1+x some invalid command
will lead to an i3-nagbar instance popping up, offering you to view the
error log (which will contain parser errors from this commit on).
This is now restricted according to the already defined fullscreen
focus constraints. Test case 157 was removed, as we don't prevent
level up/down in fullscreen anymore. Those commands are properly
tested in fullscreen by test case 156.
Fixes: #612
Basically, a focus change can't escape a fullscreen container. The
only exception is per-output fullscreen containers, as you should
be able to focus a container in a different workspace in this case.
This is an improvement on 4eab046e, now considering the difference
between global and per-output fullscreen and taking the tree
structure into account to determine what escaping the fullscreen
container means. It only affects targeted focus commands in the
form "for_window [...] focus", but it lays the foundation for
forthcoming fixes to all other focus commands.
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.
Initially I thought using the second precision time() function is good enough,
but to make t/113-urgent.t considerably faster (>2s vs. 0.08s), we put in a
little more effort and use gettimeofday. Otherwise, this test blocks the whole
testsuite from completing much faster on modern machines :).
This change has two implications:
1) tree_render() will now be called precisely once for input which consists of
multiple commands (like "focus left; focus right"). Also, the caller of
parse_command() has to call it. This makes us able to fix tickets such as
ticket #608 (where multiple tree_render() calls are noticable).
2) The output of a command is now a JSON array of return values of the
individual subcommands. In the case of "focus left; focus right", this is:
[{"success":true}, {"success":true}]
While this is incompatible with what i3 returned before, the return value of
commands was undocumented and therefore not subject to our API stability.
You need to specify the --enable-32bit-visual flag when starting i3. This is
done because everything feels sluggish on my system when using a 32 bit visual
instead of a 24 bit visual. Fast > fancy.
Currently it supports the following options:
"oldest": match the first window that triggered an urgent event
"latest": match the last window that triggered an urgent event
This re-introduces borders around the workspace buttons in i3bar.
No additional pixels will be consumed (you will not lose any space for your
windows).
On the rationale of using a custom parser instead of a lex/yacc one, see this
quote from src/commands_parser.c:
We use a hand-written parser instead of lex/yacc because our commands are
easy for humans, not for computers. Thus, it’s quite hard to specify a
context-free grammar for the commands. A PEG grammar would be easier, but
there’s downsides to every PEG parser generator I have come accross so far.
This parser is basically a state machine which looks for literals or strings
and can push either on a stack. After identifying a literal or string, it
will either transition to the current state, to a different state, or call a
function (like cmd_move()).
Special care has been taken that error messages are useful and the code is
well testable (when compiled with -DTEST_PARSER it will output to stdout
instead of actually calling any function).
During the migration phase (I plan to completely switch to this parser before
4.2 will be released), the new parser will parse every command you send to
i3 and save the resulting call stack. Then, the old parser will parse your
input and actually execute the commands. Afterwards, both call stacks will be
compared and any differences will be logged.
The new parser works with 100% of the test suite and produces identical call
stacks.
After a reload, the drawing parameters for the decorations might
have changed, so we need to invalidate the cache and force a redraw
of the currently visible decorations. Also, don't leak the previous
font when reloading by freeing it before parsing the config.
Abstracted draw_text and predict_text_width into libi3. Use
predict_text_width from libi3 in i3 too. This required tracking
xcb_connection in a xcb_connection_t *conn variable that libi3
expects to be available in i3bar.
Also prints out useful stuff:
CORE DUMPS: You are running a development version of i3, so coredumps were
automatically enabled (ulimit -c unlimited).
CORE DUMPS: Your current working directory is "/home/michael/i3".
CORE DUMPS: Your core_pattern is: /tmp/%e.core.%p
i3 (tree) version 4.0.2-479-g26ab2ac (2011-11-08, branch "next") starting
This does not affect child processes of i3.
The intention of this change is to make debugging easier – it’s one less thing
users of the development version have to worry about when trying to help with
debugging.
Also, the API changed a bit. There are two functions now, both assume you
already got the keysyms (which is the case for i3 and i3-config-wizard),
one gets the modifier mapping for you (aio_get_mod_mask_for) while the other
assumes you also got that. No roundtrips are required for the latter.
In order to not depend on X11 just for getting the socket paths, scripts or
other programs can now use i3 --get-socketpath. Since i3 must be present on the
computer anyways, this saves one dependency :).
This is mainly useful for the testsuite. The tests can wait until i3 processed
all X11 events and then continue. This eliminates sleep() calls which leads to
a more robust and faster testsuite.
The configuration option does the same as the commandline parameter, except
it can be easily set by the user (e.g. you are using KDM and can't start a
session through ~/.xsession).
Signed-off-by: Michael Walle <michael@walle.cc>
- 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.
Modify _tree_next() so that when we reach the workspace container:
1. Find the next corresponding output (screen) using the added
get_output_next().
2. If there is another output, find the visible workspace.
3. Call workspace_show on found workspace.
4. Find the appropriate window to focus (leftmost/rightmost, etc.) using
con_descend_direction, and then focus it.
I've only tested on horizontal monitors (left/right).
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.
This fixes a race where we created cursors on the Xlib connection, flushed,
then used the cursor on the XCB connection. Even though we flushed, the X
server did not process the requests yet and therefore returned a BadCursor
error.
This bugfix uses the Xlib connection for setting the root window cursor which
will ensure that the requests are properly serialized.
An easy test for this (on my machine) is the following ~/.xsession:
xsetroot -cursor_name cross
exec i3
If you see a cross cursor instead of the pointer, the race happens. You’ll see
a error_code=6 error in your ~/.xsession-errors.
These errors can happen because a DestroyWindow request by a client will
trigger an UnmapNotify, then a DestroyNotify. We cannot distinguish this
UnmapNotify from an UnmapNotify not followed by a DestroyNotify, so we just try
to send the ReparentWindow / ChangeProperty and ignore the errors, if any.
Think of the following layout:
-------------
| tab | |
| con | win |
| | |
-------------
The tabbed container on the left has two children. Assume you have focused the
second/right child in the tabbed container. i3 used to focus the first/left
container of the tabbed container when using 'focus right' (it wrapped focus).
With this commit, the default behaviour is to instead focus the window on the
right of the screen.
The intention is to make focus switching more intuitive, especially with tabbed
containers supporting 'focus left'/'focus right' in tree. You should end up
using less 'focus parent' :).
You can force the old behaviour with 'force_focus_wrapping true' in your
config.
Code coverage is 62.5% with this commit.
An example to set all XTerms floating:
for_window [class="XTerm"] mode floating
To make all urxvts use a 1-pixel border:
for_window [class="urxvt"] border 1pixel
A less useful, but rather funny example:
for_window [title="x200: ~/work"] mode floating
The commands are not completely arbitrary. The commands above were tested,
others may need some fixing. Internally, windows are compared against your
criteria (class, title, …) when they are initially managed and whenever one of
the relevant values change. Then, the specified command is run *once* (per
window). It gets prefixed with a criteria to make it match only the specific
window that triggered it. So, if you configure "mode floating", i3 runs
something like '[id="8393923"] mode floating'.
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).
When a tabbed container had more than one child and at least the first one
supported WM_DELETE, i3 entered an endless loop when killing that tabbed
container. This was due to tree_close only sending WM_DELETE without actually
removing the child, while the loop in tree_close assumed that with every call
of tree_close one child would be removed.
Actually, commit 1c5adc6c35 commented out code
without ever fixing it. I think this was responsible for the 'workspace
switching sometimes does not work' bug. My observations:
Had it again today and analyzed a log of it. Looks like after unmapping the
windows on one workspace (in my case: chromium, eclipse, urxvt, focus on
eclipse) we get UnmapNotify events for chromium and eclipse, but then we get an
EnterNotify for the terminal (due to unmapping the other windows and therefore
mapping the terminal under the cursor), only afterwards the UnmapNotify
follows.
So, there are two things wrong with that:
• We handle EnterNotifys for unmapped windows
• Unmapping windows sometimes works in a sequence, sometimes the sequence gets
split. Not sure why (if unmapping can take longer for some windows or if our
syncing is wrong -- but i checked the latter briefly and it looks correct).
Maybe GrabServer helps?
• We don’t ignore EnterNotify events caused by UnmapNotifies. We used to, but
then there was a different problem and we decided to solve the EnterNotify
problem in another way, which actually never happened (commit
1c5adc6c35).
This involves:
• Compiling with xcb-util instead of xcb-{atom,aux} (they merged the libraries)
• Not using xcb-{event,property} anymore (code removed upstream)
• Not using the predefined WINDOW, CARDINEL, … atoms (removed upstream)
• Using the new xcb_icccm_* data types/functions instead of just xcb_*
(for example xcb_icccm_get_wm_hints instead of xcb_get_wm_hints)
Also I refactored the atoms to use x-macros.
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]'.
Instead, we attach them to their workspace when toggling back to tiling. This
makes more sense; afterall, floating clients are always directly below a
CT_WORKSPACE container.
The file is now created in /tmp using the process PID and the
username of the user running i3. The restart state file is only
loaded when restarting (the --restart option is appended to the
command line prior to the restart). That means that renaming the
old state file with the ".old" extension is no longer needed.
This "--restart" switch is supposed to be only used by i3. The
"-L" switch can be used to load a layout (and not delete it
afterwards). We unlink the state file after we load it so that
we don't keep cruft in /tmp or try to restart from an old config
file if restart_state is set.
Quote from the source:
When the container type is CT_WORKSPACE, the user wants to change the
whole workspace into stacked/tabbed mode. To do this and still allow
intuitive operations (like level-up and then opening a new window), we
need to create a new split container. */
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.
This fixes the bug which caused floating windows to be visible even when
switching to a different workspace.
Instead of ignoring a specific sequence, we now set an ignore_unmap counter for
each container. (So, should containers be closed too early or stay open even if
they should be closed, we probably need to have a closer look at the counter.
At the moment, it is increased by one on reparenting and unmapping (for
workspace changes) and decremented by one on each UnmapNotify event).
This system is better because a sequence does not describe a single unmap or
reparent request but a request to X11 on the network layer -- which can contain
multiple requests.
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 helps for windows which are immediately destroyed instead of
unmapped, like when starting i3status | ./foobar | dzen2 -dock
and foobar does not exist (i3status and dzen2 will get a SIGPIPE).
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.
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.
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!
Actually, WM_CLASS contains two null-terminated strings, so we cannot
use asprintf() to get its value but rather use strdup() to get both
of them. Both values are compared when a client is matched against
a wm_class/title combination (for assignments for example).
This makes it more clear that the option is meant to be a special
case (it *disables* part of the focus handling). Also, when
initializing the config data structure with zeros, it will get
initialized with the right value.
Furthermore, the config file parser now also accepts various values
which represent "true", not only numbers.
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.
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.
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.
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.
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 "bindsym" instead of "bind". You have to use the names of keys
as in xmodmap. To get a list of currently bounud symbols, use
xmodmap -pke
Technical quirk: Xlib generated MappingNotify events upon
XkbMapNotify events (from XKB, as the name says). XCB does not yet
have support for XKB, thus we need to select and handle the event
by ourself. Hopefully, this will change in the future.
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().
Michael Stapelberg