We now build a docker base container based on debian sid (where the very
latest packages are available). That base container is updated once a
month, or whenever travis-build.Dockerfile or debian/control change, but
re-used for subsequent travis runs. While the initial build might take
up to 15 minutes, subsequent builds typically run in a minute or two.
All the different steps that we run on travis are now factored into
separate scripts in the travis/ directory.
Switching to docker should also help with issue #2174.
Corrects the cases where the colorpixel is not 0xRRGGBB : we have to
use the full color_t struct to describe font colors, as Pango expects
RGB values and not an XCB colorpixel value.
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.
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.
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.
Given that the code was exit(0)ing directly after using that memory,
it’s not like this has any effect. However, less false positives on the
clang-analyze report pages is a good thing.
This avoids flooding stdout every time some text (e.g. a window
decoration) is drawn, yet leaves the message in place when it’s actually
relevant (upon DPI changes).
fixes#1115
This removes code duplication, which will be useful for a subsequent
commit.
Furthermore, we now don’t open X11 connections unnecessarily in some
corner cases.
While this is a bit ugly, it makes the log messages end up where they
are supposed to: in the shmlog/stdout in case of i3 and on stdout in
case of utilities such as i3-input
open_input_window was slightly different for each of them, so it made no sense
to generalize it (then we would end up with a thin and useless wrapper).
This introduces the '-F format' parameter, which takes a format and replaces %s
in it with the user input. An example: The user should enter the target
workspace name. The appropriate i3-input invocation looks like this:
i3-input -F 'workspace "%s"' -P 'Switch to workspace: '
The case of an X11 server having multiple displays is handled correctly by the
code in src/mainx.c. However, due to some functions not being correctly
refactored and still getting the first screen (and also the first root window)
from the XCB connection, i3 was operating on the wrong root window.
Michael Stapelberg