Compilers store the path with which they were called in the debug
symbols. Therefore, this will make backtraces show something like
../i3-4.2/src/main.c instead of src/main.c.
See also http://stackoverflow.com/questions/6473561/
$ time CC=clang make -j16
CC=clang make -j16 6,04s user 0,86s system 468% cpu 1,471 total
CC=clang make -j16 6,05s user 0,87s system 468% cpu 1,477 total
CC=clang make -j16 6,15s user 0,86s system 464% cpu 1,510 total
CC=clang make -j16 6,05s user 0,93s system 467% cpu 1,493 total
CC=clang make -j16 6,10s user 0,84s system 461% cpu 1,507 total
$ time CC=gcc make -j16
CC=gcc make -j16 9,91s user 1,43s system 508% cpu 2,231 total
CC=gcc make -j16 10,02s user 1,37s system 500% cpu 2,275 total
CC=gcc make -j16 9,80s user 1,60s system 507% cpu 2,245 total
CC=gcc make -j16 10,02s user 1,44s system 506% cpu 2,264 total
CC=gcc make -j16 9,99s user 1,45s system 505% cpu 2,261 total
after:
$ time CC=clang make -j16
CC=clang make -j16 3,41s user 0,83s system 375% cpu 1,131 total
CC=clang make -j16 3,29s user 0,90s system 373% cpu 1,122 total
CC=clang make -j16 3,35s user 0,77s system 369% cpu 1,116 total
CC=clang make -j16 3,36s user 0,78s system 374% cpu 1,105 total
CC=clang make -j16 3,46s user 0,75s system 373% cpu 1,126 total
$ time CC=gcc make -j16
CC=gcc make -j16 10,74s user 1,44s system 494% cpu 2,462 total
CC=gcc make -j16 10,68s user 1,54s system 497% cpu 2,453 total
CC=gcc make -j16 10,60s user 1,60s system 488% cpu 2,499 total
CC=gcc make -j16 10,63s user 1,51s system 485% cpu 2,502 total
CC=gcc make -j16 10,70s user 1,51s system 497% cpu 2,453 total
Therefore, we enable pre-compiled headers only when CC=clang.
ipc: implement GET_VERSION to find out the i3 version
This is useful for third-party scripts which require certain features
and want to error out cleanly when they are run with an old i3 version.
Additionally, i3 --version might be different from what’s actually
running (an old version of the binary), so i3-msg -t get_version will be
the best way to figure out the i3 version you are actually running from
this commit on.
With this commit, the "default" layout is replaced by the splith and
splitv layouts. splith is equivalent to default with orientation
horizontal and splitv is equivalent to default with orientation
vertical.
The "split h" and "split v" commands continue to work as before, they
split the current container and you will end up in a split container
with layout splith (after "split h") or splitv (after "split v").
To change a splith container into a splitv container, use either "layout
splitv" or "layout toggle split". The latter command is used in the
default config as mod+l (previously "layout default"). In case you have
"layout default" in your config file, it is recommended to just replace
it by "layout toggle split", which will work as "layout default" did
before when pressing it once, but toggle between horizontal/vertical
when pressing it repeatedly.
The rationale behind this commit is that it’s cleaner to have all
parameters that influence how windows are rendered in the layout itself
rather than having a special parameter in combination with only one
layout. This enables us to change existing split containers in all cases
without breaking existing features (see ticket #464). Also, users should
feel more confident about whether they are actually splitting or just
changing an existing split container now.
As a nice side-effect, this commit brings back the "layout toggle"
feature we once had in i3 version 3 (see the userguide).
AFAIK, it is safe to use in-place restart to upgrade into versions
after this commit (switching to an older version will break your layout,
though).
This is necessary because the autobuilder uses a dist tarball to build
i3 from. If we store $VERSION, the autobuiluder binaries will not run in
developer mode, thus defeating the purpose of developer mode.
cfgparse: Write custom scripts for i3-sensible-terminal
This workaround is necessary for terminal emulators which parse -e in a
different way: some accept a list of arguments (-e command arg1 arg2 …),
some accept only one argument (-e "command arg1 arg2 …"). Therefore, we
just create a script and pass that as the one and only argument.
config-wizard: use the level 0 keysym whenever it’s unambiguous
From the code:
Try to use the keysym on the first level (lower-case). In case
this doesn’t make it ambiguous (think of a keyboard layout
having '1' on two different keys, but '!' only on keycode 10),
we’ll stick with the keysym of the first level.
This reduces a lot of confusion for users who switch keyboard
layouts from qwerty to qwertz or other slight variations of
qwerty (yes, that happens quite often).
When a workspace marked 'urgent', i3bar unhide
itself. if I want to hide it again, I must press the
modifier.This sometimes annoys me.
In this patch I change the above behavior to this:
If a urgent workspace occurs, i3bar will unhide itself;
and when you navigates away from the last urgent
workspace and there is no more urgent workspace, i3bar
will hide itself.
resizing: traverse containers up properly (+test) (Thanks oblique)
In certain situations (when you have a h-split within a h-split) you
couldn’t properly resize previously. This commit makes the resize
command properly traverse up the containers.
yajl1 has the status yajl_status_insufficient_data, which in our stream
parsing context basically means "ok". Therefore, in yajl1, we no longer
print an error in this case.
While it’s generally intended that wait_for_window is not called within
this testcase, in the first test instruction it was a mistake. The
window in fact gets mapped and therefore we should call wait_for_window.
This fixes a race condition when running the tests. I think that the X11
server has more time to clean up the resources when we do an explicit
disconnect. The symptom I was seeing was that sometimes, i3 couldn’t
become the window manager on one of the Xdummy instances.
…by using the new syntax which will not trigger i3-nagbar. Checking for
i3-nagbar is inherently prone to race conditions since i3-nagbar does
not communicate in any way that it’s there.
…by getting the socket path from i3 and then checking that it conforms
to what we expect. Previously we monitored /tmp, which can go wrong in
various ways, especially since i3’s directory within /tmp is not
predictable (by design).
projects / i3 / i3 / log