nk_begin no window about nuklear

[dumblob]

I'm afraid I don't understand what you mean with "precompiler" (there is nothing like that in this repository). Do you use any bindings or do you download nuklear.h directly from this repository and include it manually?

You can find examples under example/ in this repository (https://github.com/Immediate-Mode-UI/Nuklear/tree/master/example ) and you can choose the backend of your choice in demo/ (https://github.com/Immediate-Mode-UI/Nuklear/tree/master/demo ).

[William-Baker]

Thanks for the quick reply!
Whoops, my bad meant Pre-processor

I downloaded the source from this repo and included it in the project with very little setup, I just added the folder as an additional include directory to expose the header, then added the source files to the project within solution manager so they're compiled.

I looked at those examples but they're all using GLFW so have different code to set up a window, I want to build up the complexity of the project as and when I need to. I was of the understanding GLFW was not a dependency?

[dumblob]

Please try first some of the demo/ backends and if it works for you, incorporate it into your project. The demo/ directory contains also a small example showing how e.g. a window can be created. The examples/ directory shows though more complex examples and uses one chosen backend to make things easy to read & understand.

[William-Baker]

Just refactored to follow the simple demos example, which attaches to an existing Win32 window but only does so through the buggy nuklear_gdi.h in Nuklear/demo/gdi/nuklear_gdi.h.
All other options look like they require writing your own library to create a d3d or OpenGL window :(
I guess it is technically a single header UI library but I'm not sure if this is going to be worth my time considering there are much more complete (but bulkier) libraries such as NanoGUI. Shame :(

[dumblob]

All other options look like they require writing your own library to create a d3d or OpenGL window :(

Hm, I'd say, that most of them create a window. Or am I missing something? What do you actually mean by "writing your own library"? Everything is already written - you just need to initialize it based on your app needs (which you do even in high-level frameworks like Qt). If anything is missing, please tell us and propose solution - we'd like to improve Nuklear and its ecosystem.

I guess it is technically a single header UI library but I'm not sure if this is going to be worth my time considering there are much more complete (but bulkier) libraries such as NanoGUI. Shame :(

Well, that highly depends on your needs. Apparently there are thousands of developers (see stars of the old Nuklear repo), who do require full control over the main loop, event dispatch etc. and not a fixed solution with all decisions made up front to match mainstream (which is when it comes to UI pretty low quality in terms of final user experience as well as development time of mid and more complex UIs).

but only does so through the buggy nuklear_gdi.h

If you found any bugs, please make a PR or at least write them down into a separate issue to have them tracked. See also these open GDI+ PRs: vurtun/nuklear#940 , vurtun/nuklear#796 .

[William-Baker]

They all create a window but require a lot of work to do so including introducing dependencies on GLFW, DirectX or Win32.
I think there should be some helper functions included for single line font importing and baking and single-line window creation, and similar for other setup items. Allowing you the ease of use while you start with the library so you can gradually introduce lower-level functions when needed to add that flexibility.
A little bit of documentation on the most basic program to draw a text box or button wouldn't go amiss too.
I'm just a student though so forgive me if what I'm saying is stupid.

[dumblob]

There is nothing stupid in your questions - it's an important feedback. Let's try to get to some action items.

A little bit of documentation on the most basic program to draw a text box or button wouldn't go amiss too.

There is such a small example in Readme.md (without any backend, so you need to choose one otherwise you won't see anything though everything will compile and work fine) and then there are advanced examples under example/ (they chose a backend for you, but if the chosen backend doesn't work for you, you have to slightly touch the source code and use other backend - you can use as many backends as you like and you can do so in compile time as well as in run time unlike in most other UI frameworks where if it doesn't match your use case, you're screwed forever).

I think there should be some helper functions included for single line font importing and baking and single-line window creation, and similar for other setup items. Allowing you the ease of use while you start with the library so you can gradually introduce lower-level functions when needed to add that flexibility.

Definitely. I'm all for it. So far there were no such PRs and from other UIs there seem to be absolutely no consensus how such a "compound" API should look like. PRs are welcome.

They all create a window but require a lot of work to do so including introducing dependencies on GLFW, DirectX or Win32.

This is something we shall discuss more in detail. I'm not aware of that - in the simpliest case, you won't use any backend at all and compile Nuklear application fine. But you won't get any other output then list of instructions (there are just a few - e.g. "draw cornered rectangle", "draw poly line", "draw text", "draw arc", etc.). You can use it to draw to anything (to SVG, to any bitmap, to Web canvas, to GDI surface, to DirectX surface, you name it). And if you provided Nuklear with some input events (e.g. a mouse click) by calling the corresponding Nuklear function, the list of instructions will reflect upon that automatically. That's it, nothing else.

So, where did you get the impression, that you need dependencies on GLFW, DirectX or Win32? I'd like to fix those places which are this misleading.

[samadadi]

Does using fonts in nuklear require one of these libraries? (glfw, sdl, gdi, win32, ...)

[dumblob]

@samadadi no, no such libs are required (it uses by default stb_truetype internally, but that can be changed if it doesn't suit your needs).

[samadadi]

I tried to write a simple nuklear gui example. It compiles and runs in background but there is no window to be show. here is the stackoverflow link. stackoverflow

[exchg]

I tried to write a simple nuklear gui example. It compiles and runs in background but there is no window to be show. here is the stackoverflow link. stackoverflow

Looks like you forget to create window )) You should take a look to exampes. It use target specific renderer wrapper, which handle window dispatching and input.

In other words you should handle input and window dispatching/drawing routine yourself. You can find existent code for some common subsystems inside 'demo' directory.

[samadadi]

Looks like you forget to create window )) You should take a look to exampes. It use target specific renderer wrapper, which handle window dispatching and input.

I thought nuklear has its own renderer for window creation and redering the window (using nk_begin & nk_end). So if I want to render a window, I should use third party library like sdl, glfw and ... . Is this true?

[dumblob]

So if I want to render a window, I should use third party library like sdl, glfw and ... . Is this true?

To be clear here, Nuklear has it's own windows for which no external dependency is needed. But judging based on your stackoverflow link, you're not trying to render the Nuklear windows into a raw framebuffer, but rather you're expecting Nuklear "magically" (i.e. without any other dependency) draw OS-level windows (which are OS-specific and thus require dependency on OS-specific libraries providing the windowing functionality - e.g. on Linux it's X11 or Wayland, on Windows it's winapi, on macOS it's Quartz, on Android ...).

[RobLoach]

What dumblob said. You'll need a platform renderer. See one of the examples in the /demo/ folders.