This fixes problems with the Oracle JRE7, which checks the current focus after
receiving WM_TAKE_FOCUS and just does nothing when the focus is on one of its
windows. Hopefully it doesn’t introduce any regressions :).
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.
Following bug:
1) Assign workspace 9 to output HDMI2
2) On HDMI2, be on workspace 1
3) Focus a different output, say LVDS1
4) Execute i3 'workspace 9'
5) Something happens, but you end up back on ws 1
(this is due to an EnterNotify being generated when warping)
Some of them are useless nowadays, others very unlikely to be a problem.
Those which might still be interesting somewhen in the future are just
commented out.
My testcase was putting a floating window on the left output, but overlapping a
little to the right output. Then switch to a workspace on the right output.
This should fix focus problems where EnterNotify events were generated while
moving windows. Hopefully it does not trigger any regressions :).
Fixes#500
- 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.
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.
As initial may be set to true again after initializing the window, we need to
ensure that it is properly cleared. Otherwise, this leads to ghost windows when
unmapping (such as the Xpdf about dialog) due to i3 issuing MapWindow after an
Unmap happened but before i3 actually received/handled the UnmapNotify.
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.
With the polygon, when using pidgin, having the buddy list in the middle of the
screen, 200 px width, full screen high, then opening the manage accounts
window, the decorations of the buddy list were visible on the accounts window.
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.
Michael Stapelberg