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.
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
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 :).
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
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.
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).
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.
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.
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.
Michael Stapelberg