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 removes our last dependency on Xlib! :)
(Okay, an Xlib dependency still comes in through other libraries that we
link against, but it’s not us. Our code is simpler by this change and
uses one less connection to X11.)
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.
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.
This adds some code duplication which we might remove in a future
refactoring or not. Depends on whether unifying the parsers actually
makes the code better or not. I suspect it doesn’t :-).
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
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).
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
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).
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.
Deiz