I am right now toying around building an interface for iOS and Android and potentially other touch screen devices. Getting a rough port up running on iOS was pretty easy, thanks to the clean structure of zahnrad. I have discovered only one major show stopper and this is the mouse pointer centric approach. On a touch screen there is no concept of hovering for example. And most widgets (those that do not involve dragging) do fire on touch up and not down.

As a workaround I am sending a motion event right before a touch down.

zr_clear(&gui.ctx);

zr_input_begin(&gui.ctx);
zr_input_motion(&gui.ctx, location.x, location.y);
zr_input_end(&gui.ctx);

zr_input_begin(&gui.ctx);
zr_input_button(&gui.ctx, b, location.x, location.y, zr_true);
zr_input_end(&gui.ctx);

run_demo(&gui);

and again a motion event right after a touch up

zr_clear(&gui.ctx);

zr_input_begin(&gui.ctx);
zr_input_button(&gui.ctx, b, location.x, location.y, zr_false);
zr_input_end(&gui.ctx);

zr_input_begin(&gui.ctx);
zr_input_motion(&gui.ctx, 0, 0);
zr_input_end(&gui.ctx);

run_demo(&gui);

This does work surprisingly well, but of course feels quite hackish and does not solve the touch up vs. down issue.

Another issue is the hit test. On a touch screen it is rather difficult to hit small widgets and the solution usually is to extend the hit area virtually to at least 40 x 40 pixel.

I see a huge potential for zahnrad on touch devices.

What do you think?

Cheers, richi

Hey, I have many questions/comments about your sample code under the README. (this is all c++)

1. Firstly it seems that the first line needs to be changed to this: struct gui_command_buffer *buffer = new gui_command_buffer; or else it doesn't work on this line:gui_foreach_command(cmd, buffer) {
2. In reference to void *memory = malloc(MEMORY_SIZE); What is memory size? I noticed that in the demo it was set to 64 * 1024... what is the significance of this?
3. In reference to len = gui_panel_edit(&layout, buffer, len, 256, &active, GUI_INPUT_DEFAULT); What is len? what is active?
4. I have been trying for a very long time for your example to work but its always crashing on "gui_panel_begin" I have confirmed that the assert statements are returning properly, beyond that I didn't want to have to debug your code to see where it crashes. Do you think you could point me in the right direction here?

I think that having one header deployment is the best way to ship C/C++ libraries (aka stb way), but it makes development a bit clumsy in a way. In my case I would like to contribute to the library, but having 15kloc file is just too bulky to work on and takes time to figure out the mental model behind the code. In some other projects like tigr and buildfox they have source as separate files which gets amalgamated into final files in the end.

Would be nice to have nuklear source divided across multiple files just for sake of making development a bit easier.

sdl_opengles2 already supports Open GL ES 2 and Web GL. It can be compiled on Raspberry Pi (Raspbian Linux), but gives black square only. Please fix it to have an ability to have accelerated Open GL ES output on Raspberry Pi.

8$ bounty

All examples and GL based demos for me produces pretty awful font.

See this screenshot: This is from example/overview.c demo on Linux with Iris Pro 5200. And I get same output also on Windows with Nvidia 970.

Is this expected? Because fonts in screenshots on nuklear github page looks much prettier.

There is still no text. I provide the code, you can find my error.

#define NK_INCLUDE_FIXED_TYPES
#define NK_INCLUDE_STANDARD_IO
#define NK_INCLUDE_STANDARD_VARARGS
#define NK_INCLUDE_DEFAULT_ALLOCATOR
#define NK_INCLUDE_VERTEX_BUFFER_OUTPUT
#define NK_INCLUDE_FONT_BAKING
#define NK_INCLUDE_DEFAULT_FONT
#define NK_IMPLEMENTATION

#include "nuklear.h"

nk_context *ctx;

NK_INTERN void gui_device_upload_atlas(const void *image, int width, int height)
{
    struct gui_device *dev = &glgui.ogl;
    glGenTextures(1, &dev->font_tex);
    glBindTexture(GL_TEXTURE_2D, dev->font_tex);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, (GLsizei)width, (GLsizei)height, 0, GL_RGBA, GL_UNSIGNED_BYTE, image);
    glBindTexture(GL_TEXTURE_2D, 0);
	
    // Here the texture contains the Cyrillic, checked "xxx.bmp"
    // void *color = malloc(width * height * 4);
    // glBindTexture(GL_TEXTURE_2D, dev->font_tex);
    // glGetTexImage(GL_TEXTURE_2D, 0, GL_RGBA, GL_UNSIGNED_BYTE, color);
    // glBindTexture(GL_TEXTURE_2D, 0);
    // save_image("xxx.bmp", width, height, 4, color);
    // free(color);
}

struct nk_context *gui_init(nk_user_font *font)
{
    nk_init_default(&glgui.ctx, font);
    glgui.ctx.clip.copy = gui_clipbard_copy;
    glgui.ctx.clip.paste = gui_clipbard_paste;
    glgui.ctx.clip.userdata = nk_handle_ptr(0);
    nk_buffer_init_default(&glgui.ogl.cmds);

    glgui.is_double_click_down = nk_false;
    glgui.double_click_pos = nk_vec2(0, 0);

    return &glgui.ctx;
}

void gui_font_stash_begin(struct nk_font_atlas **atlas)
{
    nk_font_atlas_init_default(&glgui.atlas);
    nk_font_atlas_begin(&glgui.atlas);
    *atlas = &glgui.atlas;
}

void gui_font_stash_end()
{
    int w = 0, h = 0;
    const void *image = NULL;
    image = nk_font_atlas_bake(&glgui.atlas, &w, &h, NK_FONT_ATLAS_RGBA32);
    gui_device_upload_atlas(image, w, h);
    nk_font_atlas_end(&glgui.atlas, nk_handle_id((int)glgui.ogl.font_tex), &glgui.ogl.null);
    if(glgui.atlas.default_font) nk_style_set_font(&glgui.ctx, &glgui.atlas.default_font->handle);
}

void CreateGUI()
{
    ctx = gui_init(NULL);

    struct nk_font_atlas *atlas;
    struct nk_font_config cfg = nk_font_config(14);
    gui_font_stash_begin(&atlas);
    cfg.range = nk_font_cyrillic_glyph_ranges();
    struct nk_font *font = nk_font_atlas_add_from_file(atlas, "Roboto-Regular.ttf", 14, &cfg);
    gui_font_stash_end();

    nk_style_set_font(ctx, &font->handle);
}

void RenderGUI()
{
	if(nk_begin(ctx, "Окно", nk_rect(50, 50, 200, 200), 31))
	{
		nk_layout_row_static(ctx, 30, 80, 1);
		if(nk_button_label(ctx, "Кнопка"))
			printf("button pressed!\n");
	}
}

I hope for your help, for a long time I have not been able to display the text with the Cyrillic.

I'm currently debugging the mouse-hover problem I'm seeing in my integration of nuklear for Oryol here: http://floooh.github.io/oryol-samples/asmjs/NuklearUIAdvanced.html, and I'm opening this bug to record my findings, may be at one point you can jump in and point me in the right direction :)

The buttons in the left most window, starting at the second row, don't get 'hovered' when the mouse is over them. Moving the window to the middle fixes the problem, but when moving towards the right, the problem happens again. This happens only in emscripten, so I'm limited to printf-debugging.

Here's what I found out so far:

The button doesn't get hovered because: in nk_button_behaviour(), the incoming nk_input* is null, moving up the callstack to nk_button_text(), this will happen when the widget is in state NK_WIDGET_ROM, which seems to be the 'partially visible' (or occluded?) state...

Another interesting thing: up in the 'button_demo()' function, I have commented everything out except that first Push Button, and it looks like this:

    ui_widget(ctx, media, 35);
    if (nk_button_label(ctx, "Push me"))
        fprintf(stdout, "pushed!\n");

The ui_widget() function looks like this:

static void
ui_widget(struct nk_context *ctx, struct media *media, float height)
{
    static const float ratio[] = {0.15f, 0.85f};
    nk_style_set_font(ctx, &media->font_22->handle);
    nk_layout_row(ctx, NK_DYNAMIC, height, 2, ratio);
    nk_spacing(ctx, 1);
}

If I'm commenting out the call to nk_spacing(ctx, 1), the button becomes smaller, and the mouse hover works in emscripten.

That is all so far, I'll try to find out now why the button is in NK_WIDGET_ROM state.

Btw, how does nuklear detect the current canvas size, in Imgui I'm explicitely setting this at the start of a frame, but I haven't seen something similar in nuklear. I'm mentioning this because this might be a difference between emscripten and other platforms in Oryol, the size of the WebGL canvas might change, if nuklear uses the 'display resolution/canvas size', this might one potential cause for the problem.

Is there any simple way to scale the whole UI in a "vector" way (i.e. not scaling the resulting bitmap, but every single part of the UI separately in a consistent way)? I found just several scaling options, but only for some containers (e.g. panel).

Without scaling, the whole UI is currently not suitable for many deployments (high-res displays of wildly varying sizes - e.g. 5" mobile devices having higher resolution than my 15.4" notebook display).

Also, the sizes differ in the pixel shapes etc., so a separate scaling factor for x and y would be much better than just one common scaling factor.

layout->bounds cannot be used (loc 16615) since we modify it up here: layout->bounds.x += panel_padding.x; (16471) layout->bounds.w -= 2*panel_padding.x; (16472) Because of it there was no ability to nk_draw_image attached to window's edge. There alway was empty lines of right and left.

This code breaks the other's code. Popups, for example. My paddings are 10px. To show popup at (20,20) without this patch I must use nk_rect(10, 20, .... With this patch I must use nk_rect(20, 20, ..., not depending on paddings. I think (20,20) is a correct constant for (20,20) coordinate.

I'm having problems with nk_combo. The lists in the combo box are not sized correctly. This usually results in the list being too short for the box and weird rendering problems happen at the bottom of the box. Sometimes there seems to be garbage, sometimes it just stops short, sometimes the backing layer stops too short and you can see through the box. \

Also, sometimes this causes the last item in the list to be unselectable.

Also, the scrollbar appears, but it really shouldn't because it only scrolls a few pixels. If things were sized correctly, there wouldn't need to be a scrollbar. Scrolling all the way down doesn't help the unselectable problem.

The first picture shows a stop-short.

The second picture shows part of the missing backing.

A related question: is there a way to control the size of the list box? As you can see in the second picture, it is getting really long.

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  70 (X_PolyFillRectangle)
  Serial number of failed request:  29
  Current serial number in output stream:  102

Dear visitor,

this repository, issue tracker, etc. is abandoned in favor of https://github.com/Immediate-Mode-UI/Nuklear . Any activity in this issue tracker, any pull requests, etc. will be ignored.

Looking forward to hearing from you in https://github.com/Immediate-Mode-UI/Nuklear

Nuklear community

Are you a volunteer? Please see TODO in https://github.com/vurtun/nuklear/pull/913#issuecomment-558565788 .

@vurtun, could you please remove the current description of this original repository and instead place the following text there and then archive this original repository?

Repository moved to https://github.com/Immediate-Mode-UI/Nuklear

(btw. you're also an admin in the new organization)

I think that one big differencial in one GUI component be the shadows. Example:

https://www.w3schools.com/cssref/tryit.asp?filename=trycss3_box-shadow2

This example is exagerated, but "small shadows" be nice, the google desgin really like to use the "small shadows", so if you have an android you already have seen it.

how would i do this in Nuklear? Is it possible, if not yet, how difficult it would be to implement something like this?

the GDI+ fix make the nk_button_color draw the rectangle with inner black lines, while the original one is ok. I found the PR make change of the GDI+, maybe it's the reason of problem. https://github.com/vurtun/nuklear/pull/527 The GDI+ fix version The Original Version

Hello. Thanks for a great project. What are the reasons behind using scissor command? For which purposes it's used? Why can't it be evaded? Scissors are stopping one from combining multiple draw calls into instanced one or force to implement them in the shader.

Just adjust UV coords for elements when it's needed. Thanks.