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 fixes two issues:
* We detect the EWMH support window from the root window. If this window
currently has the input focus, we ignore this. We do this because this
window is not a window the user is aware of and positioning relative to
it makes no sense.
* We also detect whether the current input focus is in an i3-frame window.
This can happen, e.g., when selecting a parent (split) container. Since
frame windows are direct children of the root window, we must not
translate its coordinates or we get weird results and i3-input ends up
off-screen (see #2312). For all other windows, including those without
any WM_CLASS, we proceed as before.
fixes#2312
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.
The Makefiles should put binaries in $(EXEC_PREFIX) and
architecture-independent files in $(PREFIX). Also a user may have a
prefixed- pkg-config, as in the case of cross compiling on Exherbo
Linux, so respect the well-accepted $(PKG_CONFIG) variable for this
purpose.
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 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.
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
CPPFLGES, CFLAGS and LDFLAGS should be user variables
We now provide default flags but use I3_*FLAGS flags for our own needed
flags
Also reoder lib flags a bit
Ingo Bürk