We already claim _NET_WM_DESKTOP support in _NET_SUPPORTED since around 2009,
but haven't actually done anything with it. However, especially pagers like
gnome-panel rely on this property to be updated and many tools, like GTK, want
to use the corresponding client messages to make a window sticky, move it
around etc.
This patch implements full support according to the EWMH spec. This means:
* We set the property on all windows when managing it.
* We keep the property updated on all windows at all times.
* We read and respect the property upon managing a window if it was set before
mapping the window.
* We react to client messages for it.
* We remove the property on withdrawn windows.
Note that the special value 0xFFFFFFFF, according to the spec, means that the
window shall be shown on all workspaces. We do this by making it sticky and
float it. This shows it on all workspaces at least on the output it is on.
Furthermore, the spec gives us the freedom to ignore _NET_WM_DESKTOP when
managing a window if we have good reason to. In our case, we give window
swallowing a higher priority since the user would likely expect that and we
want to keep placeholder windows only around for as long as we have to.
However, we do prioritize this property over, for example, startup
notifications.
fixes#2153fixes#1507fixes#938
This patch migrates all decoration rendering of i3 to cairo. Using the
compile switch CAIRO_SUPPORT, rendering can be switched back to the
previous XCB behavior, just like with the previous migration to cairo
in i3bar.
This patch also fixes a bug in draw_util.c where copying one surface
to another would use incorrect coordinates if the source coordinates
are not 0, 0.
Furthermore, this patch implicitly fixes some minor issues in the
decoration rendering which would be ignored previously due to the fact
that errors would only show up in the event queue, but not cause the
rendering code path to crash. One example is zero-height pixmaps which
are not allowed. Using cairo, these would cause i3 to instantly segfault,
so this patch avoids this.
Lastly, this patch annotates other issues found but not fixed in this patch
using TODO comments, e.g., the zero-height check not working correctly
and the comment that it should probably work the same way for zero-width
pixmaps.
relates to #1278
With this patch, we support the special value "0" for _NET_WM_USER_TIME
on a window upon managing it, which indicates that the window shall not
be focused.
fixes#2064
With this patch, we only grab the scrollwheel buttons (4 and 5) when
managing a window if a whole window key binding exists for these buttons.
This allows both of these usecases:
- Bindings to scrollwheel buttons using --whole-window (see #1701).
- Scrolling in a window without focusing it if no such binding
exists (see #2049).
Furthermore, we drop all button grabs and regrab them after a config
reload in order to reevaluate the new bindings correctly.
fixes#2049
We refactor the button grabbing into a function to allow the next patch
both to
- conditionally grab different sets of buttons
- grab the buttons again when reloading the config.
relates to #2049
With this patch, the no_focus directive will be ignored if the
to-be-opened window is the first on its workspace as there's no
reason the user would not want to focus it in this case.
This improves usability when, for example, using a tabbed
workspace_layout.
fixes#1987
Not quite sure why there are so many differences. Perhaps we’ve gotten
out of the habit of running clang-format after every change.
I guess it’d be best to have a travis hook that runs clang-format for us
and reports any problems on pull requests.
When a window becomes managed, explicitly set the current border width
to the default instead of relying on the default value of -1 to apply
the correct value.
Now that there are two different kinds of default borders, a border
width value of -1 is ambiguous. This can lead to different border widths
effectively being applied when the container changes from tiling to
floating, which is surprising behavior.
This commit extends behavior introduced in this commit to normal
borders:
7afe9cc78b4d22dfd5a0c5866382a0e001ea38b6
Explicitly set current border width when BS_PIXEL
fixes#1304
Fixes a bug where a normal floating default border is not applied when
the default tiling border is set to a pixel value.
This bug was introduced in this commit:
43b447855df095c56e860117d53acd0dd09ac42b
Consider motif border for floating geometry
Fixes a comment that claimed default floating border could override
motif hints, which was never the case.
fixes#1305
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
When calculating the geometry of a floating window with motif hints that
specify a border style, take into account that this window will have a
different border style when calculating its position with
floating_enable() when the window becomes managed.
A nice side effect of this is that users can override motif hints with
`new_float` config directives when they are specified other than
`normal`.
fixes#1270
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
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
> Clients using the Globally Active model can only use a SetInputFocus request
> to acquire the input focus when they do not already have it on receipt of one
> of the following events:
> * ButtonPress
> * ButtonRelease
> * Passive-grabbed KeyPress
> * Passive-grabbed KeyRelease
Since managing a window happens on a MapNotify (which is absent from this
list), the window cannot accept input focus, so we should not try to focus
the window at all.
Fixes an issue with xfce4-notifyd which (correctly) declines focus when
we send WM_TAKE_FOCUS, which puts i3 in a state where i3 focus and X
focus are different when a notification appears.
This should be the last commit that formats a big bunch of files. From
here on, whenever I merge patches, I’ll run clang-format like described
in the title.
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
Floating windows already had their own border style, but the width was
the same for all windows.
The configuration directives 'new_window' and 'new_float' can now be
used simultaneously to have different border widths for floating and
tiled windows.
fixes#1244
Otherwise, we read random garbage. Found by the testsuite due to
t/185-scratchpad.t failing because a window was incorrectly recognized
as a floating window.
Windows that match the following criteria are floated by default:
- dialog, utility, toolbar, or splash windows,
- modal windows, or
- windows that have specified equal minimum and maximum size.
closes#1182
This patch fixes ticket #1168 to extend the window IPC event mechanism
to send IPC events for window focus and title changes. The newly added
window events use the same format as the already established "new"
event.
Specifically this patch:
* Moves the ipc_send_window_event() function from src/manage.c into
src/ipc.c and adds an argument for the change property of the event
* Updates src/manage.c to use the new function signature. To ensure
that the "new" event does not send the same event data as the
"focus" event, setting focus now happens after the "new" event
has been sent
* Adds IPC focus event notification to src/x.c. To workaround a problem
during window close when accessing the window name, a function has been
added to query whether a window is actually attached to its parent. To
avoid obsolete focus notification, a new field has been added to keep
track of the focus without any interference by the click handling
* Adds IPC title event notification to src/handlers.c. To avoid
obsolete title notification, a function has been added to determine
whether a window title has actually changed
* Updates the IPC documentation to include the new events
* Updates testcases/t/205-ipc-windows.t to include the "focus" event
in order to ensure the correct event sequence
* Adds two new unit tests, b/testcases/t/219-ipc-window-focus.t and
b/testcases/t/220-ipc-window-title.t to ensure proper "focus" and
"title" events
When the _MOTIF_WM_HINTS property of a window specifies it should have
no title bar, or no decorations at all, respond by setting the border
style of that container to BS_PIXEL or BS_NONE respectively.
This comes from the old Motif window manager. It was originally intended
to specify exactly what sort of decorations a window should have, and
exactly what sort of user input it should respond to. The EWMH spec
intended to replace Motif hints with _NET_WM_WINDOW_TYPE, but it is
still in use by popular widget toolkits such as GTK+ and Java AWT.
i3's implementation simply mirrors Gnome's Metacity. Official
documentation of this hint is nowhere to be found.
For more information see:
https://people.gnome.org/~tthurman/docs/metacity/xprops_8h-source.htmlhttp://stackoverflow.com/questions/13787553/detect-if-a-x11-window-has-decorationsfixes#832
When i3 begins to manage a window, if the window opens on a workspace
that is not visible, the urgency hint on the newly managed window will
be set.
fixes#1088
