Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nk_begin no window #5

Closed
William-Baker opened this issue Nov 30, 2019 · 14 comments
Closed

nk_begin no window #5

William-Baker opened this issue Nov 30, 2019 · 14 comments

Comments

@William-Baker
Copy link

William-Baker commented Nov 30, 2019

/*
#define NK_IMPLEMENTATION
#define NK_INCLUDE_DEFAULT_ALLOCATOR //prevents having to manage memory allows us of nk_init_default
#define NK_INCLUDE_FONT_BAKING//allows for use of custom fonts with high level API
#define NK_INCLUDE_DEFAULT_FONT//to allow loading default fon
#define NK_INCLUDE_STANDARD_IO//to allowloading custom fonts
#define _CRT_SECURE_NO_WARNINGS allows importing fonts without errors
*/

#include "Resource.h"
#include <windows.h>
#include <stdlib.h>
#include <malloc.h>
#include <memory.h>
#include <tchar.h>
#include <string>
#include <stdio.h>
#include <iostream>

#include <nuklear.h>





int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
	_In_opt_ HINSTANCE hPrevInstance,
	_In_ LPWSTR    lpCmdLine,
	_In_ int       nCmdShow)
{
	struct nk_context ctx;
	nk_font_atlas atlas;
	struct nk_font_config cfg = nk_font_config(0);
	struct nk_font* font_14;
	cfg.oversample_h = 3;
	cfg.oversample_v = 2;
	cfg.coord_type = NK_COORD_PIXEL;
	const void* image;
	void* image2;
	int w, h;
	nk_font_atlas_init_default(&atlas);
	nk_font_atlas_begin(&atlas);
	//font_14 = nk_font_atlas_add_default(&atlas, 14, &cfg);
	font_14 = nk_font_atlas_add_from_file(&atlas, "Roboto-Light.ttf", 12, &cfg);
	image = nk_font_atlas_bake(&atlas, &w, &h, NK_FONT_ATLAS_ALPHA8);
	image2 = new char[w * h];
	memcpy(image2, image, w * h);
	nk_font_atlas_end(&atlas, nk_handle_id(30), NULL); //30 means nothing?
	nk_init_default(&ctx, &font_14->handle);



	if (nk_begin(&ctx, "Window 1", nk_rect(10, 10, 400, 600), NK_WINDOW_BORDER | NK_WINDOW_MOVABLE)) {
	}
	nk_end(&ctx);
}

The definitions commented at the start have been added within the pre-compiler settings

Am I mistaken in that the above is the minimum required code to create a window? Since it doesn't work :( Are there minimalized examples for simple things like this?

@dumblob
Copy link
Member

dumblob commented Dec 1, 2019

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
Copy link
Author

Thanks for the quick reply!
Whoops, my bad meant Pre-processor
image
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
Copy link
Member

dumblob commented Dec 1, 2019

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
Copy link
Author

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
Copy link
Member

dumblob commented Dec 1, 2019

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
Copy link
Author

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
Copy link
Member

dumblob commented Dec 3, 2019

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
Copy link

samadadi commented Jan 16, 2020

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

@dumblob
Copy link
Member

dumblob commented Jan 16, 2020

@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
Copy link

samadadi commented Jan 17, 2020

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
Copy link
Contributor

exchg commented Jan 17, 2020

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
Copy link

samadadi commented Jan 17, 2020

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
Copy link
Member

dumblob commented Jan 17, 2020

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants