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.
Calls ewmh_update_current_desktop on startup to set the
_NET_CURRENT_DESKTOP property. Without this change the property only
gets set after the workspaces have been manipulated. Also exclude
hidden workspaces (i.e. those starting with "__" from the workspace
index.
Adds tests for startup and workspace switching.
This is done by installing a new check watcher that replaces the main
X11 event handler and calling ev_run with EVRUN_ONCE until the dragging
loop left state DRAGGING.
With this commit, other handlers, most notably the redraw handler for
placeholder windows, get a chance to run when dragging (placeholder!)
windows around.
Since the macro PATH_MAX is not defined on every system (GNU/Hurd being
one of those who do not define it), we remove all references to this
macro. Instead, we use a buffer of arbitraty size and grow it when
needed to contain paths.
The commit title is fairly technical, so I’ll try to explain.
Recently, users of GDM3 (I’m sure) and LightDM (I think) have reported
that when switching to a new workspace, the contents of the previous
workspace are still visible. i3bar updates, though, so it is the X11
root window which is not being updated here.
When using GDM3, X11 will be started with -background none, and no
background pixmap or pixel is set. Then, apparently,
gnome-settings-daemon will display a fade animation from whatever is
currently on the window to the destination contents. I think this is to
avoid flickering when logging in, which would occur when just setting a
specific background pixmap or pixel.
So, this commit will, when i3 starts first (not on restarts), copy the
contents of the X11 root window (typicall a grey background, at least on
my machine with GDM3) into a pixmap and set that pixmap as background
pixmap. That way, the content will be preserved and one has a
background, instead of what is perceived as a bug :).
This commit has some chance of breakage, so I’m prepared to revert it
unless we can figure out the issues and roll forward.
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.
This makes our signal handler useless and leads to infinite SIGSEGV
loops because the ev callback handler gets called only from within the
event loop, and control doesn’t necessary get to the event loop…
This reverts commit 514265b529.
Functions such as fprintf() might be unsafe to use in a signal handler,
see http://stackoverflow.com/questions/3941271/#answer-3941563
By using ev_signal, libev will use a tiny signal handler which just
passes on the information and then calls (outside of the signal handler)
our callback function which can use fprintf() and other unsafe
functions.
fixes#803
From the source:
When starting i3 initially (and after each change to the connected
outputs), this function fixes the resolution of the __i3
pseudo-output. When that resolution is not set to a function which
shares a common divisor with every active output’s resolution,
floating point calculation errors will lead to the scratchpad window
moving when shown repeatedly.
fixes#632
See also:
http://article.gmane.org/gmane.linux.kernel/1268792
The C compiler will handle (void) as "no arguments" and () as "variadic
function" (equivalent to (...)) which might lead to subtle errors, such
as the one which was fixed with commit 0ea64ae4.
You need to specify the --enable-32bit-visual flag when starting i3. This is
done because everything feels sluggish on my system when using a 32 bit visual
instead of a 24 bit visual. Fast > fancy.
Michael Stapelberg