I have added support for 9-slice (also called 9-patch) images for most of the widgets, at least where it made sense. The following widgets now support nk_style_item_9slice for skinning:

• button
• chart
• combo
• edit
• panel (inc. window) (header + fixed_background only)
• progress
• property
• scrollbar
• selectable
• slider (background only)
• tree

9-slice images can be assigned to styles in much the same way as regular images:

nk_9slice slc = nk_sub9slice_ptr(tex, tex_width, tex_height,
    nk_rect(rgn_x, rgn_y, rgn_w, rgn_h));
ctx->style.button.normal = nk_style_item_9slice(slc,
    left_edge, top_edge, right_edge, bottom_edge));
/* Edges are measured from the edge of the image, so bottom_edge = 2
   would mean that bottom_edge was 2 pixels from the bottom of the image */

Please review this PR and let me know if there are any problems. closes #68

In response to the issue I reported, I forked the repo and pushed my changes to a branch.

The code does compile and it seems to run 'ok' on Linux, but it crashes on macOS because apparently the allocator stuff in the baker percolates around.

I don't understand all the ramifications so I'm asking for someone who knows the code to please assist.

Hello

I am writing a GUI rendering class which uses nuklear as the GUI backend. My header file contains various nuklear structs (struct nk_context *ctx etc), and it has a setup like this:

#ifndef NUKLEAR_GUI_HPP 
#define NUKLEAR_GUI_HPP //header include guard

#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
#define NK_GLFW_GL3_IMPLEMENTATION
#define NK_KEYSTATE_BASED_INPUT
#define INCLUDE_STYLE
#define WINDOW_WIDTH 1200
#define WINDOW_HEIGHT 800

#define MAX_VERTEX_BUFFER 512 * 1024
#define MAX_ELEMENT_BUFFER 128 * 1024

#include <GL/glew.h>
#include <GLFW/glfw3.h>

#include "nuklear.h"
#include "nuklear_glfw_gl3.h"
#include "style.c"

//NUKLEAR CLASS
class NuklearGui{
public:
  struct nk_glfw glfw = {0};
  int* width;
  int* height;
  struct nk_context *ctx;
  struct nk_colorf bg;
  struct nk_command_buffer *canvas;
  NuklearGui();
}


#endif // NUKLEAR_GUI_HPP

However, upon compiling, I get a huge backlog of multiple definition errors, like this:

multiple definition of `nk_glfw3_font_stash_end(nk_glfw*)'; CMakeFiles/binary.dir/src/Application.cpp.o:Application.cpp:(.text+0x4b5e0):

I don't understand why this is happening, as I've already included my own header guards. Any ideas what i could be doing wrong?

Memory usage, keeps rising up in chunks of atleast ~20MB on Windows 7, on Windows 10 doesn't seem to be an issue...

I thought this might've been an issue with nuklear_glfw_gl3.h, but it happens also with nuklear_glfw_gl2.h, so I know that it's most-likely an issue with nuklear.h itself.

The program starts at 10MB memory usage, then climbs all the way up to ~151MB!

Provide an example to build Nuklear using SDL2 / SDL_RenderGeometry (using this PR https://github.com/libsdl-org/SDL/pull/4195)

Which makes Nuklear using the platform backend available (opengl, opengles2, Direct3D11, Metal, or software rendering).

If I draw a tonne of things at once, I reach the limit of the maximum number of indices or vertexes of the default ushort size. However, I read that defining NK_UINT_DRAW_INDEX will increase this limit to a uint which should be way more than enough for what I need it for.

However, if I have this define added, even when barely drawing anything for e.g. just using the nuklear demo, this happens (defined)-

when it should look normal like this (not defined)-

Does anyone know how to properly fix this in the D3D11 implementation, or perhaps what I am doing wrong?

The demo used is from here- https://github.com/Immediate-Mode-UI/Nuklear/tree/master/demo/d3d11

Thank you.

I know my english is worse and my question is newbie, but, try to understand and help anyway.

I recently started learning programming starting with c as my first and i also wanted to learn c alongside with GUI programming in c by using nuklear, but the problem is i can't figure out how to compile demo/glfw_opengl3/main.c on 64-bit windows. I'm using vscode with C/C++ extension + mingw-64 installed with mingw-64 installer. As for glew and glfw 64-bit i copied their files to these folders:

Project
    main.c
    Makefile
    Nuklear_glfw_gl3.h

  MinGW-64
      +- mingw32     
            +- i686-w64-mingw32
                      +- include
                        |  +- GLFW
                        |    |  glfw3.h
                        |    |  glfw3native.h
                        |  +- GL (for glew)
                        |       eglew.h
                        |       glew.h
                        |       glxew.h
                        |       wglew.h
                        |
                      +- lib (for glfw+glew)
                           libglfw3.a
                           libglfw3dll.a
                           glfw3.dll ( to system32)
                           glew32.lib
                           glew32s.lib
                           glew32.dll ( to system32)

tried with gcc -o main.exe main.c -lglfw3 -lopengl32 -lglew32 -lkernel32 -luser32 -lgdi32 And throws a long list of undefined reference to errors starting with _imp____glewCreateProgram

i tried make -f makefile it creates empty bin and-p folders and complains

I really don't even know what i'm doing, but, if you help me to get the window, i will keep playing with it.

I know, but, i'm not starting with python/javascript first and i'm not going to wait till i learn c and get used to programming world. i want to do this.

Fixes issue https://github.com/Immediate-Mode-UI/Nuklear/issues/11

Now detecting if memcpy and memset are actually needed. And same goes for the vertex check (they check correctly now).

Paq.sh now automatically outputs to nuklear.h.

I see that you failed to provide an hello world example, and I can see why. In the sample on the readme you omitted the font hell that you must do. I hope its temporary. The default font and size should be automatic, and there should be an optional function like setdefaultfont( path, size ) and setdefaultfont( name, size ).

Hello i have a problem with compilation in my C++ 20 project. When i try to compile it it gives me this error:

It looks like that it need C DirectX API so i tried to do this but no luck Any ideas how to fix it?

This commit resolves two issues with high-DPI display rendering:

1. The coordinates were not scaled properly, resulting in tiny output and misalignment of actual cursor position with apparent position; this is fixed by calling SDL_SetRenderScale with appropriate scaling factors determined by comparing the window size to the renderer's output size
2. The fonts were not oversampled, resulting in excessively blurry text; this is fixed by setting oversample_h and oversample_v on the font_config according to the scaling factors

I wonder if Nuklear could interface with Glazier (yeah, Rust) or similar to lower the barrier for both newcomers as well as seniors who must currently choose backend and then handle these os-specific things on their own.

In stbtt_PackFontRangesGatherRects, it skips packing when glyphs are missing. Resulting in incorrect glyphs when nk_font_bake reading these ranges rects data. Referring to the way IMGUI handles it, we skip the rect data check.

ref #399

load font:

before:

after:

Hello!

While trying to find and understand the information on how to work with text input boxes, I met two issues:

1. Lack of examples: I could only find one example in demo/common/calculator.c, for double type. As I am definitely not brilliant with C, I couldn't figure out how to make it work with strings, and there is not much info on how to handle it.
2. Lack of documentation: There are no examples on https://immediate-mode-ui.github.io/Nuklear/doc/index.html, and there is only one example on Wiki which is quite too broad in my opinion(though I couldn't exactly understand it due to how it's written)

I love this lib, and I would also love to see some better docs on it. Thanks!

Would you be open to converting all Makefiles / batch files to CMake? This would allow easier cross-platform testing / building.

Additionally, when you would agree on using CMake, how do you feel about using vcpkg for package management? This integrates with CMake, and can be used in Windows, Linux and Mac. The recommended way is to use vcpkg as submodule, but this can also be done as manual checkout.

See example runners for how build definitions could look like.

Both a 'default' build, and with the define INCLUDE_ALL set will be built. I did not know how to unroll the individual build steps (without making it a huge matrix, where each build will do a new checkout), so all build steps are copy-pasted manually.

I would like to have touch to scroll working, for usage on touch screens. You know, how you can effortlessly just scroll up and down on a webpage with a phone. So for a flawless experience, with an enlarged scrollbar being used for scrolling though. As a workaround it is trivial to remap to fingers moving to -> nk_input_scroll() But it just isn't the same as proper one finger touch to scroll.

The logic needed for this is rather simple I imagine. The logic for this is "If mouse is not hovering over something that can be interacted with, then click + drag distance affects ctx.input.scroll_delta". However, whilst there are a bunch of functions to test whether the mouse is over an intractable rectangle, I don't know how to test for the opposite. There is a nk_window_is_any_hovered() but no nk_window_is_any_clickable_thingy_hovered().

Anyone have an idea how to test for "Is the current mouse click over something that can be interacted with?"