9200094203
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. |
||
|---|---|---|
| .. | ||
| Makefile | ||
| README | ||
| dpi.c | ||
| fake_configure_notify.c | ||
| font.c | ||
| get_colorpixel.c | ||
| get_exe_path.c | ||
| get_mod_mask.c | ||
| get_process_filename.c | ||
| get_visualtype.c | ||
| ipc_connect.c | ||
| ipc_recv_message.c | ||
| ipc_send_message.c | ||
| is_debug_build.c | ||
| libi3.mk | ||
| root_atom_contents.c | ||
| safewrappers.c | ||
| string.c | ||
| strndup.c | ||
| ucs2_conversion.c | ||
README
Introduction ============ libi3 is an *INTERNAL* library which contains functions that i3 and related tools (i3-msg, i3-input, i3-nagbar, i3-config-wizard, i3bar) use. It is NOT to be used by other programs. Structure ========= Every function gets its own .c file, which in turn gets compiled into an .o object file. Afterwards, all .o files are archived into one static library (libi3.a). This library will be linked into all i3 binaries. The linker is able to eliminate unused .o files when linking, so only the functions which you actually use will be included in the corresponding binary.