If there is a client with an urgency hint on another workspace and
switching to this workspace would cause the urgency to be reset (by
moving the focusing to the client), delay the reset by some time. This
gives the user the chance to see it.
This commit adds the possibility to configure the urgency delay timer
duration using the 'force_display_urgency_hint' directive. Also,
documentation and a testcase was added to allow for automated checks of
the intended behavior.
fixes#482
this implements both the "move container to workspace back_and_forth" command
and movements to the same workspace when auto_back_and_forth is set.
it includes documentation and test suite additions by michael.
it also simplifies the workspace_show_by_name function (making use of
workspace_get accepting NULL pointers).
Introducing a new event to subscribe called mode. It's fired up
when i3 changes binding mode (like switching from default to resize).
IPC guide adjusted also.
Before commit 4976fa3350, setting the
layout of workspaces to something else than the default would just mess
up the parent container of the workspace (the content container).
After that commit, it would create an unnecessary split container when
you change the layout _before_ opening any containers. To avoid this, we
now store the layout (similar to how the 'workspace_layout'
configuration directive works) and apply it when the first container is
attached to the workspace.
Fixes#796
For the following binding:
# Simulate ctrl+v upon pressing $mod+x
bindsym --release $mod+x exec --no-startup-id xdotool key --clearmodifiers ctrl+v
you can now use either:
1. press $mod, press x, release x, release $mod
2. press $mod, press x, release $mod, release x
fixes#485
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.
Simon Elsbrock