Without this call, sometimes the tray icon windows are reparented into
i3’s container around the i3bar window, i.e. into the next remaining
window in the window hierarchy. Since i3 then closes that container
(since the i3bar window itself was closed), the tray window will also
get closed. In general, this weird interaction (getting reparented and
then closed) is not well received by tray icon providers :).
closes: #1296
This reverts commit b109b1b20d.
Turns out the change in behavior was unexpected by a number of users, so
let’s revert it and make those users that want this behavior configure
it explicitly.
Sorry for the back-and-forth here.
When a window becomes managed, if the config specifies a pixel border
style, explicitly set the current border width so it does not change
when the container changes from tiling to floating.
fixes#1266
A window may become unmapped on manage when an assignment command unmaps
the window, such as moving it to the scratchpad or killing it.
This can cause i3 focus to be an unmapped window and different than X
focus which can lead to complications
fixes#1283
This has multiple effects:
1) The i3 codebase is now consistently formatted. clang-format uncovered
plenty of places where inconsistent code made it into our code base.
2) When writing code, you don’t need to think or worry about our coding
style. Write it in yours, then run clang-format-3.5
3) When submitting patches, we don’t need to argue about coding style.
The basic idea is that we don’t want to care about _how_ we write the
code, but _what_ it does :). The coding style that we use is defined in
the .clang-format config file and is based on the google style, but
adapted in such a way that the number of modifications to the i3 code
base is minimal.
I consider this behavior broken and not respecting the standard, but it
happens in real life, and it’s better for i3 to not busy-loop in such a
situation :).
fixes#1259
When `focus_follows_mouse` option is on, prevent an uneeded render on
pointer enter when the con is already focused.
This pointer enter might be caused by entering a window decoration of an
already-focused container.
This extra render can cause concurrency issues when focus is set
asynchronously with WM_TAKE_FOCUS.
Michael Stapelberg