If a window with _NET_STARTUP_ID set is moved to another workspace, it
will delete any associated startup sequence immediately. This will also
occur if a window has a leader with _NET_STARTUP_ID set, if the leader
has no container (never been mapped).
A startup sequence may also be deleted if it's matched by
startup_workspace_for_window() and its 30-second timeout has elapsed.
This avoids a case where a fullscreen container could be moved onto a
workspace that already had its own fullscreen container, leading to
two fullscreen containers on top of each other.
Previously, while the loop would not be executed anymore, the callback
(for actually repositioning the window after a MotionNotify) would still
get called once. This commit avoids that, thus fixing the crash.
fixes#819
Fix a crash that occured when moving a window to the scratchpad that is
seemingly floating to the user, but actually a descendant of a floating
parent con (and itself non-floating). If that is the case, move the
floating parent container to scratchpad instead of the window.
fixes#740
This commit breaks floating window keyboard focus order
(t/135-floating-focus.t) when you have > 2 floating windows. Since
keyboard focus is more important than saving one click to raise floating
windows, I revert the commit.
Note that we cannot implement this without keeping a third list (beneath
floating_windows and focus) for the z coordinate of a floating window.
This seems not worth it.
This reverts commit 064be457e5.
This makes our signal handler useless and leads to infinite SIGSEGV
loops because the ev callback handler gets called only from within the
event loop, and control doesn’t necessary get to the event loop…
This reverts commit 514265b529.
If there is a single floating con on a separate workspace that is not
focused, and this con becomes urgent, switching back to that workspace
may result in a crash of i3. This is because while setting the urgency
of parent containers, 'parent' may become NULL in case of floating
containers. This commit checks the validity of parent.
fixes#821
We need to verify that setting the event mask works, and we need to
include StructureNotify to get unmap events at any point in time.
Thanks darkraven for the pointer.
fixes#718
Previously, when you had an urgent container in a stack on some
invisible workspace (say urxvt) and you switched to it, the urgency hint
was not properly cleared.
Previously, i3 would send width=0, height=0 to windows which were put on
workspaces created by an assignment (that is, invisible workspaces,
which do not get rendered normally).
fixes#653
The removed code was add by commit 61b8a62 to fix#564. That bug is cause
by rendering the mplayer window again as a floating window (even if it
has been rendered before as a fullscreen window, at line 202). So simply
checking for fullscreen window is enough to solve this problem. Treating
floating/tiling fullscreen window differently is not needed.
A good visualization of the new algorithm is this:
+--------+
| |
+--------+=| S1 |========================
| | | |
| S0 | +--------+
| | +--------+
+--------+=========| |================
| S2 | +--------+
| | | |
+--------+ | S3 |
| |
+--------+
When focus is on S0, 'focus output right' will first match S1 (the
closest output which overlaps in the highlighted area), then S2, but not
S3 (since S3 does not overlap into the highlighted area).
fixes#669fixes#771
While it’s certainly better and clearer to specify it, we should do the
right thing when the unit is missing, just like CSS for example
(margin: 0; is okay, margin: 0px; too).
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.
Functions such as fprintf() might be unsafe to use in a signal handler,
see http://stackoverflow.com/questions/3941271/#answer-3941563
By using ev_signal, libev will use a tiny signal handler which just
passes on the information and then calls (outside of the signal handler)
our callback function which can use fprintf() and other unsafe
functions.
fixes#803
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
If the focused application is in fullscreen mode and 'scratchpad show'
is executed, toggle the fullscreen mode before showing the scratchpad
application. Otherwise, the scratchpad app would not be visible anyways
but focus would be stolen.
fixes#613
The problem was that scratchpad_move() didn’t check whether the source
workspace was focused. Therefore, 'move scratchpad' only worked reliably
interactively , but not when used with criteria.
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.
In tabbed mode, the available width (say 1280) is divided by the amount
of child containers (say 3). Before this commit, we just truncated the
result and would end up with 426 + 426 + 426 = 1278 pixels that we
render to. Now we render a bit too much, but that’ll at least not give
us graphics corruption on any side :).
fixes#791
When the workspace layout (formerly orientation) was forced to change
due to a move command, the split container we created was not marked as
split = true, which caused tree_flatten() to errnously kill the contents
of it and thus one window ended up unmanaged.
Also, the logic in tree_flatten() was inverted due to commit de94f6da.
fixes#790
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.
Basically, this is the same fix as commit 914ca6cf :-/. Once again, we
called exit() instead of _exit(), but this time it lead to a kill(0,
SIGTERM), effectively killing all processes in the i3 process group,
including i3 itself. The cause for the kill(0) is that nagbar_pid is set
to 0 by fork(), signaling we’re in the child process. The cleanup
handler only checks for nagbar_pid being -1 as a special value, however.
Previously, in case 'layout stacked' (for example) had been called
interactively, con_set_layout would be called with focused->parent,
while with for_window, it’d be called on the actual matching container.
This difference in behavior was the cause for the inability to use
'for_window [class="XTerm"] layout tabbed', which now works \o/, but
more on that below.
The change also allows us to handle the case of the user selecting a
CT_WORKSPACE container properly, that is, by using the special case and
creating a new split container on the workspace which gets all the
contents, but a new layout.
Now, before you are enthusiastic about the change and try to use
for_window magic in your config file, keep in mind: The 'layout' command
acts on the parent split container. That is, when using a line such as
this one:
for_window [class="XTerm"] layout tabbed
…and opening an XTerm when on a workspace with one single other window,
the whole workspace will be set tabbed (just as previously when you
opened an XTerm and sent 'layout tabbed' manually).
Therefore, to open XTerm in its own tabbed split container, you need to
split before:
for_window [class="XTerm"] split v, layout tabbed
The comma here is important! It says that the second command should not
be treated as an entirely unrelated command, but it should also relate
the matching window (while it does work with a ';', that is prone to
race-conditions and should be avoided).
fixes#358
When you have a tabbed container which has had more than one container
but currently has precisely one container, there was a bit of flickering
when switching workspaces occasionally. This commit fixes it by properly
setting the height of the deco_rect (and thus the X11 window) to not
make the old window contents show up for a minimum period of time.
fixes#777
This fixes a compatibility issue with gnome-terminal and xfce’s
terminal, where fullscreening would lead to moving the window and not
displaying the contents properly.
fixes#788
When resizing floating windows, changing the height was not correctly
handled. This commit fixes that and adds testcases for shrinking and
growing the width and height of floating windows.
To automagically do the right thing when rotating monitors with regards
to splith/splitv layout (depending on width/height of the monitor), we
change the orientation of existing workspaces and the first child.
If that first child happens to be a stacked/tabbed con, we cannot change
the layout unconditionally (previously, the orientation was not in the
layout, so we never noticed this problem).
fixes#768
The latter is actually wrong. For example, when running i3
--moreversion, it will print $(pwd)/i3 instead of $(which i3). In my
previous tests, this coincidentally was the same.