Release Version 1.0

This is the first release version of nuklear (previously: zahnrad).
As for those who no the old version will notice: a lot has changed.

Most obvious should be the two biggest changes. First the name change
because I got critique that the name is hard to comprehend and
remember (understandable for non-germans) and the second is the
transistion from four files (zahnrad.h, zahnrad.c, stb_truetype
and stb_rect_pack) to one single header library file nuklear.h.
I am not 100% convinced that using a single header library is the
right choice here but so far I haven't encountered any problems.

Noticable should be as well that nuklear now directly embeds three
stb libraries: stb_truetype, stb_rect_pack and stb_textedit. Like
in previous versions the first two are optional and the library
can be compiled without. stb_textedit on the other hand powers
the text edit implementation for single as well as multiline
text manipulation. The text edit implementation is still relative
new and untested so you can expect some bugs I have not found yet.

In the demo department a lot changed as well. All platform demos
now don't compile one big demo but instead contain a simple
demo and small abstraction layer over the platform. Main benefit is
better understandablity improved ease of use. The old demo
is now split up and transfered into the example folder while each part
is self contained and compileable. (All examples use glfw I don't now
if this is the best platform but it is at least the simplest.
I also removed the apple demo because I don't have an apple system
and cannot make sure the new version runs with the old version.

Finally a lot of small bugs have been fixed as well as bugs found by
clang analyzer and coverity.

Readme.md

@@ -1,9 +1,7 @@
-# Zahnrad
-[![Coverity Status](https://scan.coverity.com/projects/5863/badge.svg)](https://scan.coverity.com/projects/5863)
-
+# Nuklear
 This is a minimal state immediate mode graphical user interface toolkit
-written in ANSI C and licensed under zlib. It was designed as a simple embeddable user interface for
-application and does not have any direct dependencies,
+written in ANSI C and licensed under public domain. It was designed as a simple
+embeddable user interface for application and does not have any dependencies,
 a default renderbackend or OS window and input handling but instead provides a very modular
 library approach by using simple input state for input and draw
 commands describing primitive shapes as output. So instead of providing a
@@ -12,34 +10,30 @@ render backends it only focuses on the actual UI.
 
 ## Features
 - Immediate mode graphical user interface toolkit
+- Single header library
 - Written in C89 (ANSI C)
-- Small codebase (~12kLOC)
+- Small codebase (~15kLOC)
 - Focus on portability, efficiency and simplicity
-- No dependencies (not even the standard library)
-- No global or hidden state
+- No dependencies (not even the standard library if not wanted)
 - Fully skinnable and customizable
+- Low memory footprint with total memory control if needed or wanted
 - UTF-8 support
-
-## Optional
-- Vertex buffer output 
-- Font handling
+- No global or hidden state
+- Customizeable library modules (you can compile and use only what you need)
+- Optional font baker and vertex buffer output
 
 ## Building
-The library is self-contained within four different files that only have to be
-copied and compiled into your application. Files zahnrad.c and zahnrad.h make up
-the core of the library, while stb_rect_pack.h and stb_truetype.h are
-for a optional font handling implementation and can be removed if not needed.
-- zahnrad.c
-- zahnrad.h
-- stb_rect_pack.h (optional)
-- stb_truetype.h (optional)
-
-There are no dependencies or a particular building process required. You just have
-to compile the .c file and #include zahnrad.h into your project. To actually
-run you have to provide the input state, configuration style and memory
-for draw commands to the library. After the GUI was executed all draw commands
-have to be either executed or optionally converted into a vertex buffer to
-draw the GUI.
+This library is self contained in one single header file and can be used either
+in header only mode or in implementation mode. The header only mode is used
+by default when included and allows including this header in other headers
+and does not contain the actual implementation.
+
+The implementation mode requires to define  the preprocessor macro
+`NK_IMPLEMENTATION` in *one* .c/.cpp file before #includeing this file, e.g.:
+```c
+    #define NK_IMPLEMENTATION
+    #include "nuklear.h"
+```
 
 ## Gallery
 ![screenshot](https://cloud.githubusercontent.com/assets/8057201/11761525/ae06f0ca-a0c6-11e5-819d-5610b25f6ef4.gif)
@@ -51,40 +45,100 @@ draw the GUI.
 ## Example
 ```c
 /* init gui state */
-struct zr_context ctx;
-zr_init_fixed(&ctx, calloc(1, MAX_MEMORY), MAX_MEMORY, &font);
+struct nk_context ctx;
+nk_init_fixed(&ctx, calloc(1, MAX_MEMORY), MAX_MEMORY, &font);
 
 enum {EASY, HARD};
 int op = EASY;
 float value = 0.6f;
 int i =  20;
 
-struct zr_panel layout;
-zr_begin(&ctx, &layout, "Show", zr_rect(50, 50, 220, 220),
-    ZR_WINDOW_BORDER|ZR_WINDOW_MOVEABLE|ZR_WINDOW_CLOSEABLE);
+struct nk_panel layout;
+nk_begin(&ctx, &layout, "Show", nk_rect(50, 50, 220, 220),
+    NK_WINDOW_BORDER|NK_WINDOW_MOVEABLE|NK_WINDOW_CLOSEABLE);
 {
     /* fixed widget pixel width */
-    zr_layout_row_static(&ctx, 30, 80, 1);
-    if (zr_button_text(&ctx, "button", ZR_BUTTON_DEFAULT)) {
+    nk_layout_row_static(&ctx, 30, 80, 1);
+    if (nk_button_text(&ctx, "button", NK_BUTTON_DEFAULT)) {
         /* event handling */
     }
 
     /* fixed widget window ratio width */
-    zr_layout_row_dynamic(&ctx, 30, 2);
-    if (zr_option(&ctx, "easy", op == EASY)) op = EASY;
-    if (zr_option(&ctx, "hard", op == HARD)) op = HARD;
+    nk_layout_row_dynamic(&ctx, 30, 2);
+    if (nk_option(&ctx, "easy", op == EASY)) op = EASY;
+    if (nk_option(&ctx, "hard", op == HARD)) op = HARD;
 
     /* custom widget pixel width */
-    zr_layout_row_begin(&ctx, ZR_STATIC, 30, 2);
+    nk_layout_row_begin(&ctx, NK_STATIC, 30, 2);
     {
-        zr_layout_row_push(&ctx, 50);
-        zr_label(&ctx, "Volume:", ZR_TEXT_LEFT);
-        zr_layout_row_push(&ctx, 110);
-        zr_slider_float(&ctx, 0, &value, 1.0f, 0.1f);
+        nk_layout_row_push(&ctx, 50);
+        nk_label(&ctx, "Volume:", NK_TEXT_LEFT);
+        nk_layout_row_push(&ctx, 110);
+        nk_slider_float(&ctx, 0, &value, 1.0f, 0.1f);
     }
-    zr_layout_row_end(&ctx);
+    nk_layout_row_end(&ctx);
 }
-zr_end(ctx);
+nk_end(ctx);
 ```
 ![example](https://cloud.githubusercontent.com/assets/8057201/10187981/584ecd68-675c-11e5-897c-822ef534a876.png)
 
+
+##FAQ
+---
+#### Why single-file headers?
+Windows doesn't have standard directories where libraries
+live. That makes deploying libraries in Windows a lot more
+painful than open source developers on Unix-derivates generally
+realize. (It also makes library dependencies a lot worse in Windows.)
+
+There's also a common problem in Windows where a library was built
+against a different version of the runtime library, which causes
+link conflicts and confusion. Shipping the libs as headers means
+you normally just compile them straight into your project without
+making libraries, thus sidestepping that problem.
+
+Making them a single file makes it very easy to just
+drop them into a project that needs them. (Of course you can
+still put them in a proper shared library tree if you want.)
+
+Why not two files, one a header and one an implementation?
+The difference between 10 files and 9 files is not a big deal,
+but the difference between 2 files and 1 file is a big deal.
+You don't need to zip or tar the files up, you don't have to
+remember to attach *two* files, etc.
+
+#### Where is the documentation?
+Each file has documentation, basic ussage description and
+examples at the top of the file. In addition each API function,
+struct and member variables are documented as well.
+Finally each library has a corresponding test file inside the
+test directory for additional working examples.
+
+#### Why C?
+Personally I primarily use C instead of C++ and since I want to
+support both C and C++ and C++ is not useable from C I therefore focus
+on C.
+
+#### Why C89?
+I use C89 instead of C99/C11 for its portability between different compilers
+and accessiblity for other languages.
+
+##CREDITS:
+Developed by Micha Mettke and every direct or indirect contributor to the GitHub.
+
+
+Embeds stb_texedit, stb_truetype and stb_rectpack by Sean Barret (public domain)
+Embeds ProggyClean.ttf font by Tristan Grimmer (MIT license).
+
+
+Big thank you to Omar Cornut (ocornut@github) for his imgui library and
+giving me the inspiration for this library, Casey Muratori for handmade hero
+and his original immediate mode graphical user interface idea and Sean
+Barret for his amazing single header libraries which restored by faith
+in libraries and brought me to create some of my own.
+
+##LICENSE:
+This software is dual-licensed to the public domain and under the following
+license: you are granted a perpetual, irrevocable license to copy, modify,
+publish and distribute this file as you see fit.
+

demo/allegro5/Makefile

@@ -8,7 +8,7 @@ DCC = gcc
 # Flags
 CFLAGS = -std=c89 -pedantic
 
-SRC = ../../zahnrad.c allegro.c
+SRC = main.c
 OBJ = $(SRC:.c=.o)
 
 ifeq ($(OS),Windows_NT)