From f69689b6cedf8f55423e95a607891a0839cffc09 Mon Sep 17 00:00:00 2001 From: vurtun Date: Sun, 12 Apr 2015 15:40:42 +0200 Subject: [PATCH] updated Readme --- Readme.md | 93 +++++++++++++++++++++++++++++++++++++++++++++++++-- demo/opengl.c | 7 ++-- gui.h | 14 ++++---- 3 files changed, 100 insertions(+), 14 deletions(-) diff --git a/Readme.md b/Readme.md index 731d475..d14c9ea 100644 --- a/Readme.md +++ b/Readme.md @@ -7,7 +7,6 @@ Work in progress - Small (~2.5kLOC) - Focus on portability and minimal internal state - Suited for embedding into graphical applications -- Flexible abstraction layer (Widgets, Panel, Window) - No global hidden state - No direct dependencies (not even libc!) - Renderer and platform independent @@ -15,10 +14,98 @@ Work in progress - Configurable - UTF-8 supported +## Layer +The gui toolkit consists of three level of abstraction. First the basic widget layer +for a as pure functional as possible set of widgets functions without +any kind of internal state, with the tradeoff off of a lot of boilerplate code. +Second the panel layer for a static grouping of widgets into a panel with a reduced need for +a lot of the boilerplate code but takes away some freedome of widget placing and +introduces the state of the pannel. +Finally there is the context layer which represent the complete window and +enables moveable, scaleable and overlapping panels, but needs complete control +over the panel management and therefore needs the most amount of internal state. +Each higher level level of astraction uses the lower level(s) internally to build +on but offers mostly a different API. + +### Widgets + +### Panels + +### Context + +## Memory + +## Input + +## Output + +## Font + +## Configuration +While the widgets layer offers the most configuration and even expects you to +configure each and every widget, the upper levels provide you with a basic set of +configurable attributes like color, padding and spacing. + +## FAQ + +### Is this project stable? +The basic API is stable while the needed backend may change. For example the draw +command backend will probably be changed to support primitives instead of +just using triangles with textures. Which would simplify the library a whole lot +while providing more freedom and control to the user. + +### Where is widget X? +A number of basic widgets are provided but some of the more complex widgets like +comboboxes, tables and tree views are not yet implemented. Maybe if I have more +time I will look into adding them, except for comboboxes which are just +discusting to implement. + +### Why should I use this library over ImGui +You probably shouldn't since ImGui provides a lot more features, better +support and more polish. That being said ImGui is C++ and not C and +therefore for people who exclusivly only use C not interesting. Furthermore +while ImGui provides a way more bloat free expierence than most classic +non immediate mode GUIs, it still focuses on unneeded global hidden state. +And finally the biggest difference between this project and ImGui is the +flexible selection of abstraction provided by this project. That beeing said I +still think the ImGui team did a great job of providing a good +immedate mode GUI that I don't activily try compete against since the +contributors of ImGUI are a.) alot more contributers and b.) probably have more +programming expierence than I do. + +### Why did you use ANSI C and not C99 or C++? +Personally I stay out of all "discussions" about C vs C++ since they are totally +worthless and never brought anything good with it. The simple answer is I +personally love C have nothing against people using C++ exspecially the new +iterations with C++11 and C++14 as long as they stay away from my code. +While this hopefully settles my view on C vs C++ there is still ANSI C vs C99. +While for personal projects I only use C99 with all its niceties, libraries are a +whole different animal. Since libraries are designed to reach the highest number of +users possible. Which brings me to ANSI C which is probably the most portable +programming langauge out there. In addition not all C compiler like the MSVC +compiler fully support C99, which finalized my decision to use +ANSI C. + +### Why do you typedef our own types instead of using the standard types +Because this project is in ANSI C which does not have the header file `` +and therefore does not provide me with fixed size types that I need . Therefore +I defined my own types which need to be set to the correct size for each +plaform. But if your development environment provides the header you can define +`GUI_USE_FIXED_SIZE_TYPES` to directly use the correct types. + +### Why do you use Freetype? I thought there are no direct dependencies? +Freefont is no direct dependency and is only used if you specifically import +the library by defining `GUI_USE_FRETYPE_FONT`. The main reason I even added +freetype was to have a basic easy way to test out the library without having to +manage font handling. + ## References -- [Tutorial from Jari Komppa on imgui libraries](http://www.johno.se/book/imgui.html) +- [Tutorial from Jari Komppa about imgui libraries](http://www.johno.se/book/imgui.html) - [Johannes 'johno' Norneby's article](http://iki.fi/sol/imgui/) -- [imgui: The inspiration for this project](https://github.com/ocornut/imgui) +- [Casey Muratori's original introduction to imgui's](http:://mollyrocket.com/861?node=861) +- [Casey Muratori's imgui Panel design 1/2](http://mollyrocket.com/casey/stream_0019.html) +- [Casey Muratori's imgui Panel design 2/2](http://mollyrocket.com/casey/stream_0020.html) +- [ImGui: The inspiration for this project](https://github.com/ocornut/imgui) # License (The MIT License) diff --git a/demo/opengl.c b/demo/opengl.c index 8a0adc3..c40a5f1 100644 --- a/demo/opengl.c +++ b/demo/opengl.c @@ -215,7 +215,6 @@ main(int argc, char *argv[]) } /* Window */ - UNUSED(argc); UNUSED(argv); SDL_Init(SDL_INIT_VIDEO); SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1); win = SDL_CreateWindow("clone", 0, 0, @@ -238,12 +237,12 @@ main(int argc, char *argv[]) memory.memory = calloc(MAX_MEMORY , 1); memory.size = MAX_MEMORY; memory.vertex_percentage = 0.80f; - memory.command_percentage = 0.19f; + memory.command_percentage = 0.20f; ctx = gui_new(&memory, &input); /* Panel */ gui_default_config(&config); - font = mkfont(argv[1], 14, 16, 255, GUI_ATLAS_DIM_256); + font = mkfont(argv[1], 12, 16, 255, GUI_ATLAS_DIM_256); panel = gui_panel_new(ctx, 50, 50, 500, 320, &config, font); message = gui_panel_new(ctx, 150, 150, 200, 100, &config, font); color_panel = gui_panel_new(ctx, 250, 250, 400, 235, &config, font); @@ -291,8 +290,8 @@ main(int argc, char *argv[]) SDL_Delay(DTIME - dt); } - /* Cleanup */ cleanup: + /* Cleanup */ free(memory.memory); delfont(font); SDL_GL_DeleteContext(glContext); diff --git a/gui.h b/gui.h index 5ec5fd5..438ec96 100644 --- a/gui.h +++ b/gui.h @@ -396,6 +396,13 @@ struct gui_panel { const struct gui_config *config; }; +/* font */ +#ifdef GUI_USE_FREETYPE_FONT +#define gui_font_atlas_alloc_size(sz) ((sz) * (sz) * GUI_ATLAS_DEPTH) +gui_bool gui_font_load(struct gui_font*, struct gui_font_atlas*, gui_uint height, + const gui_byte*, gui_size); +#endif + /* Input */ void gui_input_begin(struct gui_input*); void gui_input_motion(struct gui_input*, gui_int x, gui_int y); @@ -409,13 +416,6 @@ void gui_output_begin(struct gui_draw_buffer*, const struct gui_memory*); void gui_output_end(struct gui_draw_buffer*, struct gui_draw_call_list*, struct gui_memory_status*); -/* font */ -#ifdef GUI_USE_FREETYPE_FONT -#define gui_font_atlas_alloc_size(sz) ((sz) * (sz) * GUI_ATLAS_DEPTH) -gui_bool gui_font_load(struct gui_font*, struct gui_font_atlas*, gui_uint height, - const gui_byte*, gui_size); -#endif - /* Widgets */ void gui_widget_text(struct gui_draw_buffer*, const struct gui_text*, const struct gui_font*);