In most cases this won't make a difference, but consider the following
scenario:
* Some application acquires input focus on its own (which the window manager
is not involved in, so it will "always" work).
* Before the FocusIn / FocusOut events are processed by i3, the
workflow to push X changes is run, resulting in xcb_set_input_focus()
being called.
Using XCB_CURRENT_TIME, this means i3 will "win" and override the focus,
even though it simply wasn't aware (yet) that focus had already been taken
over by someone else. When processing the FocusIn / FocusOut events, i3
assumes that the focus is already set which results in a broken focus
state as i3 assumes some container has the input focus when it doesn't.
With the new behavior, i3's attempt to set the input focus will fail if
the FocusIn / FocusOut events have not yet processed. Once they are processed,
the focus state will be automatically corrected.
fixes#2322
This code has been neutralized for many years now and served no purpose
other than cluttering up the code. We obviously don't need it and it's
out of date anyway.
If there's ever any reason to restore (parts of) it, we have git for
that. But we don't need to keep commented out code around.
This commit removes the title indentation in certain nested container
situations. The behavior was considered broken as it didn't seem to
make sense and it was unclear why this was introduced.
Given that nobody on i3-discuss@ complained about removing this logic
within two weeks, we are now removing it to make the title rendering
code a little less complex.
fixes#2247
Since we don't actually stop drawing a title (or marks) with the
distance of the border width on the right side, but instead with
a hard-coded two pixel distance, we can only redraw that much of
the border without potentiall cutting off text.
relates to #2247
This patch moves the title_format information from windows to containers.
Furthermore, it allows correctly setting it on window-less containers and
displays the title accordingly for split containers.
We now also dump and read title_format in GET_TREE / during restarts.
fixes#2120
This fixes race conditions, for example when i3bar gets reconfigured
after the available outputs change. In that specific case, i3bar sends a
ConfigureWindow request (see
b5693d6fb3/i3bar/src/xcb.c (L376))
which normally is turned into a ConfigureRequest that i3 largely
ignores, only the dock client’s height is considered (see
b5693d6fb3/src/handlers.c (L390)).
Turning ConfigureWindow into ConfigureRequest is only done when the
SubstructureRedirect event mask is set, and because we temporarily
removed _all_ events from our mask, the ConfigureWindow request went
through unmodified.
This in turn lead to the i3bar client window (not its decoration frame)
being positioned at e.g. y=1304, whereas dock client windows should
always end up at x=0 y=0 within their decoration frame. The result of
the i3bar client window being out of the visible space was either a
black i3bar or graphics corruption.
This also fixes issue #1904, I think. I couldn’t reproduce issue #1904
specifically, but when i3bar is in the misconfigured state, it will
receive a VisibilityNotify event, telling i3bar that it is obscured.
This would explain why i3bar sent a SIGSTOP in issue #1904.
fixes#1904
The values of a Rect are unsigned, but can contain signed values.
Using MAX when the value is negative causes incorrect behavior and
makes the result stay negative, which is what we wanted to avoid here
in the first place.
Fix by properly casting the value for the comparison.
fixes#2094
With this patch, we use 32-bit visuals per default whenever it is
available. Otherwise, we fall back to the actual root window's
depth, which will typically be 24-bit.
Before this patch, we already used 32-bit depth for containers with
a window that uses 32-bit. However, this means that we didn't use
32-bit for split parent containers on which decoration is drawn.
For 32-bit windows using transparency, this caused a graphical glitch
because the decoration pixmap behind it would show through. This
behavior is fixed with this change.
relates to #1278
Such containers never require a pixmap anyway. In particular for the __i3
output (used for the scratchpad workspace), this would cause an allocation
error anyway because it can be very big -- so big, in fact, that X cannot
allocate the pixmap for it.
Until now, this error was silently ignored due to the fact that we did not
create the pixmap checked (and asserted its success), but with cairo this
would cause a crash because we'd try to create a surface for a pixmap
which doesn't exist.
relates to #1278
With this patch we remove the temporary draw_util_colorpixel_to_color
function we introduced previously by parsing the colors as color_t to
begin with.
relates to #1278
We return early from drawing functions if the surface to draw to is not
initialized properly. There is no immediate need to do so, at least no
crashes have been observed, but it mirrors the previous behavior a bit
more closely. Furthermore, i3 should not crash due to not being able to
make some rendering call, so this provides some stability.
relates to #1278
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
This patch allows multiple marks to be set on a single window. The restriction that a mark may
only be on one window at a time is still upheld as this is necessary for commands like
"move window to mark" to make sense.
relates to #2014
This patch creates all necessary windows for i3bar with 32-bit visuals if available.
It also introduces the possibility to define RGBA colors (next to RGB colors), which
allows the user to set the opacity of any color. This requires running a compositor.
With this patch we also start supporting _NET_SYSTEM_TRAY_VISUAL, which is necessary
for the tray icons so they create the tray window with the correct depth and visual.
If no other window is available on the active workspace, we now select the EWMH support window (used to indicate that an EWMH-compliant window manager is preent) as the focus window rather than the root window. The NET_WM_ACTIVE window will still be set to XCB_WINDOW_NONE to pretend that no window is actually focused.
This fixes the issue that when using the root window, a fallback mechanism in X11 takes effect which routes keyboard input to the window under the cursor, independent of whether that window has the input focus. Using the EWMH window instead, we can avoid this behavior. We cannot simply set it to XCB_WINDOW_NONE as this would discard all keyboard events, breaking keybindings.
fixes#1378
The format string set with "title_format" can contain the placeholder "%title" which will be replaced with the actual window title.
By not overwriting window->name itself, we make sure that assignment matching still works as expected.
fixes#1723
Introduce a config directive "show_marks [yes|no]" to en- or disable drawing marks on window decorations.
To not change the look & feel of existing configurations, the default is "no".
If a window has a mark set, e.g., "example", it will be printed on the right side of the window decorations.
The format is "[example]" and the name of the window is truncated if necessary.
Marks starting with an underscore ("_") will be ignored.
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.
Rectangles passed to function xcb_poly_fill_rectangle are of type
xcb_rectangle_t and defined as:
struct xcb_rectangle_t {
int16_t x;
int16_t y;
uint16_t width;
uint16_t height;
}
The rectangles for the right and lower border had a width and height,
respectively, greater than the actual border width.
Furthermore, offset the bottom border to not overlap with the right one
and, for the top border, use r->width instead of con->rect.width as with
the other borders.
Do not set focused_id to XCB_NONE in route click to force resend focus,
in some cases to an already focused window.
Sending focus again on click is not necessary and may cause problems
with certain wine or mono apps. Resending focus makes combo boxes not
work in Office 2010.
This effectively reverts commit 250577da, so in case this commit causes
any problems with Eclipse to resurface, we’ll revert this commit in
favor of 250577da (the Eclipse-related bug fix).
In normal border style, two horizontal lines are drawn to outline the
bar decoration. The lower line leaves a gap to the left and right to
align with the border. This gap was hardcoded to 2 pixels. Now it
matches the current border width, if any.
In stacked layout, only the bottommost bar is aligned. In tabbed layout,
no gaps are left in order to close the outline and make the notion of a
tab more clear.
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.
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.
_NET_ACTIVE_WINDOW:
> The window ID of the currently active window or None if no window has
> the focus.
This fixes a bug that would not update _NET_ACTIVE_WINDOW when focus
changed to an i3 container without a window such as a branch or
workspace content container.
This patch adds a new configuration option "mouse_warping [output|none]".
When mouse warping is disabled, mouse cursor does not jump to middle of current
screen when changing workspaces between multiple outputs. This introduces a
"special" cursor state, where focus is in one window and cursor on another.
Useful for eg. scrolling a web page with mouse wheel while typing into another
window on keyboard.
http://standards.freedesktop.org/wm-spec/latest/ar01s03.html#idm140251368149456
The _NET_CLIENT_LIST property of the root window:
> These arrays contain all X Windows managed by the Window Manager.
Dock clients are not managed windows, so they should not be included in
_NET_CLIENT_LIST or _NET_CLIENT_LIST_STACKING.
If input focus is set by the window manager, it is not necessary to send
WM_TAKE_FOCUS because it has already taken focus.
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
> The goal is to support window managers that want to assign the input
> focus to a top-level window in such a way that the top-level window
> either can assign it to one of its subwindows or can decline the offer
> of the focus. For example, a clock or a text editor with no currently
> open frames might not want to take focus even though the window
> manager generally believes that clients should take the input focus
> after being deiconified or raised.
Both setting input focus and sending WM_TAKE_FOCUS is effectively
setting focus on the window twice which is certainly against the spirit
of the spec, if not the letter.
fixes#1167
