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.
Apparantly, after activating numlock once, the numlock modifier
stays turned on (use xev(1) to verify). So, to resolve useful
keysyms, we remove the numlock flag from the event state. What
currently does not work is actually using your keypad.
Ingo Bürk