_NET_WM_STATE_FOCUSED is set on _NET_WM_STATE to indicate that the
window is focused. It must be set when the window is newly focused and
removed once the window no longer has focus.
> _NET_WM_STATE_FOCUSED indicates whether the window's decorations are
> drawn in an active state. Clients MUST regard it as a read-only hint.
> It cannot be set at map time or changed via a _NET_WM_STATE client
> message.
For example, this is used by GTK applications to show the decoration in
an active or inactive state. This change can be tested by opening a GTK
application (like evince), focusing the window and unfocusing the
window, and observing a change in the window decorations.
Fixes#2273
Previously rendering marks and the title were skipped if the title is empty. With marks
this is obviously wrong, with the title it is also wrong because title_format might be
set.
https://llvm.org/bugs/show_bug.cgi?id=30353 was filed for the unintended
line break between in e.g. “TAILQ_ENTRY(foo)\nbar;”.
Until that’s fixed or a workaround is known, we’ll live with line
breaks. To make it a bit easier for readers to see what’s going on, I
added extra line breaks around each such struct member/variable
definition, so that they at least visually are a single unit.
fixes#2174
Including config.h is necessary to get e.g. the _GNU_SOURCE define and
any other definitions that autoconf declares. Hence, config.h needs to
be included as the first header in each file.
This is done either via:
1. Including "common.h" (i3bar)
2. Including "libi3.h"
3. Including "all.h" (i3)
4. Including <config.h> directly
Also remove now-unused I3__FILE__, add copyright/license statement
where missing and switch include/all.h to #pragma once.
This commit correctly handles colormaps by
* Using the static default colormap we determine on startup if the
con has the corresponding depth. This avoids creating pointless
colormaps.
* Not freeing the default colormap to not have stray colormaps on
containers. This fixes an issue with certain programs such as xwd.
* Creating a custom colormap when necessary and freeing it when the
container is killed.
fixes#2435
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.
Tony Crisci