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.
Also prints out useful stuff:
CORE DUMPS: You are running a development version of i3, so coredumps were
automatically enabled (ulimit -c unlimited).
CORE DUMPS: Your current working directory is "/home/michael/i3".
CORE DUMPS: Your core_pattern is: /tmp/%e.core.%p
i3 (tree) version 4.0.2-479-g26ab2ac (2011-11-08, branch "next") starting
This does not affect child processes of i3.
The intention of this change is to make debugging easier – it’s one less thing
users of the development version have to worry about when trying to help with
debugging.
Also, the API changed a bit. There are two functions now, both assume you
already got the keysyms (which is the case for i3 and i3-config-wizard),
one gets the modifier mapping for you (aio_get_mod_mask_for) while the other
assumes you also got that. No roundtrips are required for the latter.
Michael Stapelberg