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
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.
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).
i3bar previously used get_colorpixel on strings without the leading # (ff0000
instead of #ff0000). Since it uses libi3’s get_colorpixel now we needed to
update a few places.
This fixes a problem with workspace assignments.
I tested i3 -C with three user configs (Thanks SardemFF7, julien, xeen)
and did not notice any problems.
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>
Instead of using a quoted string to specify the class / title, the assign
command now uses criteria, just like the for_window command or the command
scopes.
An example comes here:
# Assign all Chromium windows (including popups) to workspace 1: www
assign [class="^Chromium$"] → 1: www
# Make the main browser window borderless
for_window [class="^Chromium$" title=" - Chromium$"] border none
This gives you more control over the matching process due to various reasons:
1) Criteria work case-sensitive by default. Use the (?i) option if you want a
case-insensitive match, like this:
assign [class="(?i)^ChroMIUM$"] → 1
2) class and instance of WM_CLASS can now be matched separately. For example,
when starting urxvt -name irssi, xprop will report this:
WM_CLASS(STRING) = "irssi", "URxvt"
The first part of this is the instance ("irssi"), the second part is the
class ("URxvt").
An appropriate assignment looks like this:
assign [class="^URxvt$" instance="irssi"] → 2
3) You can now freely use a forward slash (/) in all strings since that is no
longer used to separate class from title (in-band signaling is bad, mhkay?).
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'.
Yaroslav Molochko