Nuklear
Nuklear copied to clipboard
Immediate-Mode-UI
Add SDL3
@zoogies I've removed the sdl_gpu stuff, since it wasn't there yet, and cleaned up the CMake a bit. Mind a review?
Also made it thread-safe. There are a couple things that I think could improve. I'm not 100% sure it's cleaning up the memory correctly tho
I don't have push access to this branch, but this patch fixes the casting klei mentioned:
index 5a8c589..e819169 100644
--- a/demo/sdl3/nuklear_sdl3_renderer.h
+++ b/demo/sdl3/nuklear_sdl3_renderer.h
@@ -308,10 +308,10 @@ nk_sdl_handle_event(struct nk_context* ctx, SDL_Event *evt)
case SDL_EVENT_MOUSE_MOTION:
if (ctx->input.mouse.grabbed) {
- int x = (int)ctx->input.mouse.prev.x, y = (int)ctx->input.mouse.prev.y;
- nk_input_motion(ctx, x + evt->motion.xrel, y + evt->motion.yrel);
+ float x = ctx->input.mouse.prev.x, y = ctx->input.mouse.prev.y;
+ nk_input_motion(ctx, (int)(x + evt->motion.xrel), (int)(y + evt->motion.yrel));
}
- else nk_input_motion(ctx, evt->motion.x, evt->motion.y);
+ else nk_input_motion(ctx, (int)evt->motion.x, (int)evt->motion.y);
return 1;
case SDL_EVENT_TEXT_INPUT:
@@ -323,7 +323,7 @@ nk_sdl_handle_event(struct nk_context* ctx, SDL_Event *evt)
return 1;
case SDL_EVENT_MOUSE_WHEEL:
- nk_input_scroll(ctx,nk_vec2((float)evt->wheel.x,(float)evt->wheel.y));
+ nk_input_scroll(ctx, nk_vec2(evt->wheel.x, evt->wheel.y));
return 1;
}
return 0;
The first casting change is technically unnecessary, but it allows adding the prev and rel values as floats before converting them back to ints.
I believe all that's really missing is...
- Testing
- Figure out the best method around SDL_StartTextInput() usage
- UTF-8 support in SDL_EVENT_TEXT_INPUT
Cool, for SDL_StartTextInput(), running this once on init should be okay unless we are on a non-desktop platform.
Sam told me in the SDL Discord to "Remember [that] this will bring up the on-screen keyboard on some platforms, so you should only do this when you're ready for text input".
We could macro guard it or put a comment above it so people are aware of its behavior. I treat the source files for the backends as examples, but the header files for the backends as Nuklear vendored, so IMO it's not unreasonable to just put a disclaimer since it's "just an example".
Alternatively, you could place the start and stop calls inside the focus/defocus events for text inputs or windows, but that might interfere with some edge cases.
ref: https://wiki.libsdl.org/SDL3/SDL_StartTextInput
Actually, Sam also said that:
Conceptually it should be tied to an input box getting focus.
So it sounds like the latter is the best option. Any ideas on where we should hook into the input focus? I'm not too familiar on whether that should lie at a window focus or input focus boundary. Are there any cases of keyboard navigation that would make sense on desktop but not on other platforms?
I've fully integrated this into my own project, and it's working nicely so far except for one minor issue.
This is observable in demo/sdl3, but repeated clicking (a checkbox or other input) only registers the first click, and then drops subsequent clicks until a set amount of time has elapsed without a click. ie: spam clicking only registers the first click
Also, I started looking into the SDL TextInput stuff and it looks like the most trivial solution would be to somehow insert the calls into nk_edit_focus and nk_edit_unfocus. There doesn't seem to be a great way to do that exclusively from the SDL3 backend though. @RobLoach, do you have any guidance on a possible refactor to make this doable?
looking into the SDL TextInput stuff and it looks like the most trivial solution would be to somehow insert the calls into nk_edit_focus and nk_edit_unfocus.
Agreed. Not an elegant solution currently. Are you proposing some kind of event callback system for them?
I've fully integrated this into my own project
The other thing I'd like to see incorporated into this is a clearer implementation of detailing with the global object state. Or something like encorporating https://github.com/Immediate-Mode-UI/Nuklear/pull/799 into here.
Are you proposing some kind of event callback system for them?
That's the first thing that comes to mind. I don't have deep knowledge of the Nuklear codebase, so I wasn't sure if that's done in other places, or what the best way to integrate something like that would be. Do you have any opinions?
The other thing I'd like to see incorporated into this is a clearer implementation of detailing with the global object state. Or something like encorporating https://github.com/Immediate-Mode-UI/Nuklear/pull/799 into here.
This is interesting. Personally, I'm fine with the global state for my purposes. Does it make more sense to integrate these changes here, or have #799 tackle it for all of the SDL demos, once we have nailed down the API?
but repeated clicking (a checkbox or other input) only registers the first click
Did you have any thoughts on why this may be?
Are you proposing some kind of event callback system for them?
That's the first thing that comes to mind. I don't have deep knowledge of the Nuklear codebase, so I wasn't sure if that's done in other places, or what the best way to integrate something like that would be. Do you have any opinions?
Maybe a strict callback isn't necessary as that would incur a small but present overhead for all backends. I could see it being 2 (mutually inclusive) optional macros that are called if they exist at appropriate places in Nuklear. It wouldn't just be nk_edit_focus/nk_edit_unfocus, because that's just for the manually forcing focus/unfocus, not from the user actually clicking on an edit field or something else. I'm not sure what the best name is but something like NK_ON_EDIT_FOCUS()/UNFOCUS() might work. Not sure about any necessary parameters either.
Just my two cents till I actually have the chance to review/test this and have a more informed opinion.
How about the dependency on NK_INCLUDE_DEFAULT_ALLOCATOR (default malloc/free from libc) ?
This PR tries to solve this by providing NK_MALLOC/NK_MFREE macros but this does not seem like the right approach. There is already a solution to this problem: instead of using nk_*_init_default() functions, one could use nk_*_init() and pass custom nk_allocator to them. Adding new macros while this whole nk_allocator mechanism exists feels quite confusing.
EDIT: The patch bellow works with nk_allocator approach. I would also suggest moving NK_MALLOC/NK_MFREE to another PR (or just removing it).
patch
diff --git a/demo/sdl3/nuklear_sdl3_renderer.h b/demo/sdl3/nuklear_sdl3_renderer.h
index c57a423..4b67310 100644
--- a/demo/sdl3/nuklear_sdl3_renderer.h
+++ b/demo/sdl3/nuklear_sdl3_renderer.h
@@ -16,6 +16,12 @@
#error "nuklear_sdl3_renderer requires at least SDL 3.0.0"
#endif
+/* We have to redefine it because demos do not include any headers
+ * This is the same default value as the one from "src/nuklear_internal.h" */
+#ifndef NK_BUFFER_DEFAULT_INITIAL_SIZE
+ #define NK_BUFFER_DEFAULT_INITIAL_SIZE (4*1024)
+#endif
+
NK_API struct nk_context* nk_sdl_init(SDL_Window *win, SDL_Renderer *renderer);
NK_API struct nk_font_atlas* nk_sdl_font_stash_begin(struct nk_context* ctx);
NK_API void nk_sdl_font_stash_end(struct nk_context* ctx);
@@ -79,6 +85,27 @@ NK_API void nk_sdl_set_userdata(struct nk_context* ctx, nk_handle userdata) {
sdl->userdata = userdata;
}
+NK_INTERN void *
+nk_sdl_alloc(nk_handle user, void *old, nk_size size)
+{
+ NK_UNUSED(user);
+ NK_UNUSED(old);
+ return SDL_malloc(size);
+}
+
+NK_INTERN void
+nk_sdl_free(nk_handle user, void *old)
+{
+ NK_UNUSED(user);
+ SDL_free(old);
+}
+
+NK_GLOBAL const struct nk_allocator nk_sdl_allocator = {
+ .userdata = NULL,
+ .alloc = nk_sdl_alloc,
+ .free = nk_sdl_free,
+};
+
NK_INTERN void
nk_sdl_device_upload_atlas(struct nk_context* ctx, const void *image, int width, int height)
{
@@ -146,8 +173,8 @@ nk_sdl_render(struct nk_context* ctx, enum nk_anti_aliasing AA)
config.line_AA = AA;
/* convert shapes into vertexes */
- nk_buffer_init_default(&vbuf);
- nk_buffer_init_default(&ebuf);
+ nk_buffer_init(&vbuf, &nk_sdl_allocator, NK_BUFFER_DEFAULT_INITIAL_SIZE);
+ nk_buffer_init(&ebuf, &nk_sdl_allocator, NK_BUFFER_DEFAULT_INITIAL_SIZE);
nk_convert(&sdl->ctx, &sdl->ogl.cmds, &vbuf, &ebuf, &config);
/* iterate over and execute each draw command */
@@ -230,12 +257,12 @@ nk_sdl_init(SDL_Window *win, SDL_Renderer *renderer)
nk_zero(sdl, sizeof(struct nk_sdl));
sdl->win = win;
sdl->renderer = renderer;
- nk_init_default(&sdl->ctx, 0);
+ nk_init(&sdl->ctx, &nk_sdl_allocator, NULL);
sdl->ctx.userdata = nk_handle_ptr((void*)sdl);
sdl->ctx.clip.copy = nk_sdl_clipboard_copy;
sdl->ctx.clip.paste = nk_sdl_clipboard_paste;
sdl->ctx.clip.userdata = nk_handle_ptr(0);
- nk_buffer_init_default(&sdl->ogl.cmds);
+ nk_buffer_init(&sdl->ogl.cmds, &nk_sdl_allocator, NK_BUFFER_DEFAULT_INITIAL_SIZE);
return &sdl->ctx;
}
@@ -246,7 +273,7 @@ nk_sdl_font_stash_begin(struct nk_context* ctx)
NK_ASSERT(ctx);
sdl = (struct nk_sdl*)ctx->userdata.ptr;
NK_ASSERT(sdl);
- nk_font_atlas_init_default(&sdl->atlas);
+ nk_font_atlas_init(&sdl->atlas, &nk_sdl_allocator);
nk_font_atlas_begin(&sdl->atlas);
return &sdl->atlas;
}
Small thing that I'm trying to solve: How can I get SDL's internal debug font (the one from SDL_RenderDebugText) and use it inside of Nuklear? I don't believe that PR would need this functionality but I'm trying to remove any significant dependency on Nuklear's Font handling (especially NK_INCLUDE_FONT_BAKING because it pulls STB libraries).
@sleeptightAnsiC I'm glad to see someone else thinking about this PR!
IMO the biggest unknown right now is solving how we can call SDL_StartTextInput and SDL_StopTextInput in nk_input_focus and nk_input_unfocus, respectively.
From the original thread, I believe everything else is reasonably resolved except for UTF-8 support in SDL_EVENT_TEXT_INPUT.
, one could use nk_*_init() and pass custom nk_allocator to them. Adding new macros while this whole nk_allocator mechanism exists feels quite confusing
agreed, and your solution seems reasonable.
@RobLoach thoughts?
Small thing that I'm trying to solve: How can I get SDL's internal debug font (the one from SDL_RenderDebugText) and use it inside of Nuklear?
Interesting, although likely not relevant to this exact PR (but it is a new feature in SDL3 iirc)
You might have luck looking at the atlas implementation, but there are definitely a few downsides to using this: (from the docs)
- It accepts UTF-8 strings, but will only renders ASCII characters.
- It has a single, tiny size (8x8 pixels). One can use logical presentation or scaling to adjust it, but it will be blurry.
- It uses a simple, hardcoded bitmap font. It does not allow different font selections and it does not support truetype, for proper scaling.
- It does no word-wrapping and does not treat newline characters as a line break. If the text goes out of the window, it's gone.
Something that I noticed while looking at other similar PR https://github.com/Immediate-Mode-UI/Nuklear/pull/825#discussion_r2331685368 :
Is
sdl.ctx.delta_time_secondsbeing used anywhere? I think that #779 is missing this one. [...] EDIT: ahh, now I understand, Nuklear needs this for hiding scroll bar!
So we forgot to set sdl.ctx.delta_time_seconds (?)
Small thing that I'm trying to solve: How can I get SDL's internal debug font (the one from SDL_RenderDebugText) and use it inside of Nuklear? I don't believe that PR would need this functionality but I'm trying to remove any significant dependency on Nuklear's Font handling (especially NK_INCLUDE_FONT_BAKING because it pulls STB libraries).
Interesting, although likely not relevant to this exact PR (but it is a new feature in SDL3 iirc) You might have luck looking at the atlas implementation, but there are definitely a few downsides to using this: (from the docs)
Got it! :smiley:
I was able to implement this by recreating the atlas texture with SDL_RenderDebugText. The code is not perfect and needs some additional work but should be enough for anyone who wants to display simple debug font.
screenshot
code
diff --git a/demo/sdl3/nuklear_sdl3_renderer.c b/demo/sdl3/nuklear_sdl3_renderer.c
index b407af0..1d63d7b 100644
--- a/demo/sdl3/nuklear_sdl3_renderer.c
+++ b/demo/sdl3/nuklear_sdl3_renderer.c
@@ -129,6 +129,7 @@ SDL_AppResult SDL_AppInit(void** appstate, int argc, char* argv[]) {
struct nk_context* ctx = nk_sdl_init(appContext->window, appContext->renderer);
appContext->ctx = ctx;
+#if 0
{
struct nk_font_atlas *atlas;
struct nk_font_config config = nk_font_config(0);
@@ -152,6 +153,9 @@ SDL_AppResult SDL_AppInit(void** appstate, int argc, char* argv[]) {
/*nk_style_load_all_cursors(ctx, atlas->cursors);*/
nk_style_set_font(ctx, &font->handle);
}
+#else
+ nk_sdl_style_set_font_debug(ctx);
+#endif
return SDL_APP_CONTINUE;
}
diff --git a/demo/sdl3/nuklear_sdl3_renderer.h b/demo/sdl3/nuklear_sdl3_renderer.h
index c57a423..dc22ded 100644
--- a/demo/sdl3/nuklear_sdl3_renderer.h
+++ b/demo/sdl3/nuklear_sdl3_renderer.h
@@ -24,6 +24,7 @@ NK_API void nk_sdl_render(struct nk_context* ctx, enum nk_anti_a
NK_API void nk_sdl_shutdown(struct nk_context* ctx);
NK_API nk_handle nk_sdl_userdata(struct nk_context* ctx);
NK_API void nk_sdl_set_userdata(struct nk_context* ctx, nk_handle userdata);
+NK_API void nk_sdl_style_set_font_debug(struct nk_context* ctx);
#endif /* NK_SDL3_RENDERER_H_ */
@@ -371,7 +372,8 @@ void nk_sdl_shutdown(struct nk_context* ctx)
sdl = (struct nk_sdl*)ctx->userdata.ptr;
NK_ASSERT(sdl);
- nk_font_atlas_clear(&sdl->atlas);
+ if (sdl->atlas.font_num > 0)
+ nk_font_atlas_clear(&sdl->atlas);
nk_buffer_free(&sdl->ogl.cmds);
if (sdl->ogl.font_tex != NULL) {
@@ -384,5 +386,116 @@ void nk_sdl_shutdown(struct nk_context* ctx)
nk_free(ctx);
}
+/* FIXME: width/height of the debug font atlas (integer)
+ * Probably needs better name... */
+#define WH (10)
+
+NK_INTERN float
+nk_sdl_query_debug_font_width(nk_handle handle, float height,
+ const char *text, int len)
+{
+ NK_UNUSED(handle);
+ NK_UNUSED(text);
+ /* FIXME: does this thing need to handle newlines and tabs ??? */
+ return height * len;
+}
+
+NK_INTERN void
+nk_sdl_query_debug_font_glypth(nk_handle handle, float font_height,
+ struct nk_user_font_glyph *glyph,
+ nk_rune codepoint, nk_rune next_codepoint)
+{
+ char ascii;
+ int idx, x, y;
+ NK_UNUSED(next_codepoint);
+
+ ascii = (codepoint > (nk_rune)'~' || codepoint < (nk_rune)' ')
+ ? '?' : (char)codepoint;
+ NK_ASSERT(ascii <= '~' && ascii >= ' ');
+
+ idx = (int)(ascii - ' ');
+ NK_ASSERT(idx >= 0 && idx <= (WH * WH));
+
+ x = idx / WH;
+ y = idx % WH;
+
+ glyph->height = font_height;
+ glyph->width = font_height;
+ glyph->xadvance = font_height;
+ glyph->uv[0].x = (float)(x + 0) / WH;
+ glyph->uv[0].y = (float)(y + 0) / WH;
+ glyph->uv[1].x = (float)(x + 1) / WH;
+ glyph->uv[1].y = (float)(y + 1) / WH;
+ glyph->offset.x = 0.0f;
+ glyph->offset.y = 0.0f;
+}
+
+NK_API void
+nk_sdl_style_set_font_debug(struct nk_context* ctx)
+{
+ struct nk_user_font* font;
+ struct nk_sdl* sdl;
+ SDL_Surface *surface;
+ SDL_Renderer *renderer;
+ char buf[2];
+ int x, y;
+ bool success;
+ NK_ASSERT(ctx);
+
+ /* FIXME: For now, use another software Renderer just to make sure
+ * that we won't change any state in the main Renderer,
+ * but it would be nice to reuse the main one */
+ surface = SDL_CreateSurface(WH * SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE,
+ WH * SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE,
+ SDL_PIXELFORMAT_RGBA32);
+ NK_ASSERT(surface);
+ renderer = SDL_CreateSoftwareRenderer(surface);
+ NK_ASSERT(renderer);
+ success = SDL_SetRenderDrawColor(renderer, 0xFF, 0xFF, 0xFF, 0xFF);
+ NK_ASSERT(success);
+
+ /* SPACE is the first printable ASCII character */
+ buf[0] = ' ';
+ buf[1] = '\0';
+ for (x = 0; x < WH; x++)
+ {
+ for (y = 0; y < WH; y++)
+ {
+ success = SDL_RenderDebugText(renderer,
+ (float)(x * SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE),
+ (float)(y * SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE),
+ buf);
+ NK_ASSERT(success);
+
+ buf[0]++;
+ /* TILDE is the last printable ASCII character */
+ if (buf[0] > '~')
+ break;
+ }
+ }
+ success = SDL_RenderPresent(renderer);
+ NK_ASSERT(success);
+
+ font = SDL_malloc(sizeof(*font));
+ NK_ASSERT(font);
+ font->userdata.ptr = NULL;
+ font->height = SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE;
+ font->width = &nk_sdl_query_debug_font_width;
+ font->query = &nk_sdl_query_debug_font_glypth;
+
+ /* HACK: nk_sdl_device_upload_atlas turns pixels into SDL_Texture
+ * and sets said Texture into sdl->ogl.font_tex
+ * then nk_sdl_render expects same Texture at font->texture */
+ sdl = (struct nk_sdl*)ctx->userdata.ptr;
+ nk_sdl_device_upload_atlas(&sdl->ctx, surface->pixels, surface->w, surface->h);
+ font->texture.ptr = sdl->ogl.font_tex;
+
+ /* FIXME: font is passed but never free'd (memleak) */
+ nk_style_set_font(ctx, font);
+
+ SDL_DestroyRenderer(renderer);
+ SDL_DestroySurface(surface);
+}
+
#endif /* NK_SDL3_RENDERER_IMPLEMENTATION_ONCE */
#endif /* NK_SDL3_RENDERER_IMPLEMENTATION */
Figure out the best method around SDL_StartTextInput() usage
IMO the biggest unknown right now is solving how we can call SDL_StartTextInput and SDL_StopTextInput in nk_input_focus and nk_input_unfocus, respectively.
Are you proposing some kind of event callback system for them?
That's the first thing that comes to mind. I don't have deep knowledge of the Nuklear codebase, so I wasn't sure if that's done in other places, or what the best way to integrate something like that would be. Do you have any opinions?
Maybe a strict callback isn't necessary as that would incur a small but present overhead for all backends.
I've started experimenting with this and found small solution. This is very much work in progress but already seems to behave just fine. I have to test few cases to make sure it isn't buggy.
patch
diff --git a/demo/sdl3/nuklear_sdl3_renderer.h b/demo/sdl3/nuklear_sdl3_renderer.h
index c57a423..1eb61f1 100644
--- a/demo/sdl3/nuklear_sdl3_renderer.h
+++ b/demo/sdl3/nuklear_sdl3_renderer.h
@@ -274,6 +274,20 @@ nk_sdl_handle_event(struct nk_context* ctx, SDL_Event *evt)
NK_ASSERT(ctx);
NK_ASSERT(evt);
+ static bool was_active = false;
+ const bool active = (ctx->active && ctx->active->edit.active) ||
+ (ctx->active && ctx->active->popup.win && ctx->active->popup.win->edit.active);
+ SDL_Window *win = SDL_GetWindowFromEvent(evt);
+ struct nk_sdl* sdl = (struct nk_sdl*)ctx->userdata.ptr;
+ if (active != was_active && win == sdl->win)
+ {
+ if (!was_active && active)
+ SDL_StartTextInput(win);
+ else if (was_active && !active)
+ SDL_StopTextInput(win);
+ was_active = active;
+ SDL_LogInfo(SDL_LOG_CATEGORY_APPLICATION, "text input %s", active ? "started" : "stopped");
+ }
+
switch(evt->type)
{
case SDL_EVENT_KEY_UP: /* KEYUP & KEYDOWN share same routine */
video
https://github.com/user-attachments/assets/0882456f-55c1-48ad-9c3c-1d420178f297
EDIT: I had to add additional branch for detecting Input from Popup. I tweaked the patch by hand, I hope it still applies.
Working with pixel art or low art res viewport requires changing the viewport, if you call SDL_SetRenderLogicalPresentation the motion position events will be wrong since the viewport != window size, so here is the simplest solution.
Good job y'all, since i dont have much knowledge about patching, i'll just post the solution fix here if anyone encounter the same problem as me:
// must be called int `nk_sdl_handle_event`
SDL_ConvertEventToRenderCoordinates(sdl->renderer, evt);
I'm thinking about creating new PR with all the changes mentioned here. I'm pretty sure, I fixed most of the stuff from the comments. What's left is just merging, some additional polishing, adding Makefile (instead of CMake) and some minor stuff.
Would anyone here be interested? or shall we keep our focus on this PR?
CC @RobLoach (sorry for pinging but I think you silenced this thread and this message is quite important)
Rob, do you have any feedback on the state of this PR? I want to make sure we have a sense of what needs to be changed before this would be considered for a merge. Thanks!
@sleeptightAnsiC You had some additions over at https://github.com/Immediate-Mode-UI/Nuklear/compare/master...sleeptightAnsiC:Nuklear:personal ... Anything you think we should bring in? Would you like to add these in once the PR is merged, or prior?
@sleeptightAnsiC You had some additions over at https://github.com/Immediate-Mode-UI/Nuklear/compare/master...sleeptightAnsiC:Nuklear:personal ... Anything you think we should bring in? Would you like to add these in once the PR is merged, or prior?
@RobLoach That's my working branch where I test things and push stuff for my personal use. No worries, I will upstream all of those changes as separate PRs/Issues when I consider them stable and reasonable. Everything related to this PR is already mentioned in comments above.
That said, I will create a new PR for the SDL3 renderer demo as I mentioned in https://github.com/Immediate-Mode-UI/Nuklear/pull/779#issuecomment-3429841640 . I just wanted to wait a bit and give others in this thread a chance to share any final thoughts, since there were a lot of people involved here.
Figure out the best method around SDL_StartTextInput() usage
IMO the biggest unknown right now is solving how we can call SDL_StartTextInput and SDL_StopTextInput in nk_input_focus and nk_input_unfocus, respectively.
Are you proposing some kind of event callback system for them?
That's the first thing that comes to mind. I don't have deep knowledge of the Nuklear codebase, so I wasn't sure if that's done in other places, or what the best way to integrate something like that would be. Do you have any opinions?
Maybe a strict callback isn't necessary as that would incur a small but present overhead for all backends.
I've started experimenting with this and found small solution. This is very much work in progress but already seems to behave just fine. I have to test few cases to make sure it isn't buggy.
I'm sorry for chiming in so late but I dealt with some headaches with getting this to work in my own SDL3 backend back in June and want to know if you ran into the same issues.
Does it handle multiple windows correctly? Have you tried it on Android/mobile? Honestly I can't remember everything I ran into exactly but based on my commit message the multiple windows thing was a issue that led to my current version.
My current method required adding a few lines to nuklear proper but it simplified the backend code to this:
// Nuklear keeps track of it but we only use it if we need it for our
// backend/platform
if (ctx->input.text_input_active != ctx->input.text_input_active_prev) {
if (ctx->input.text_input_active) {
SDL_PropertiesID props = SDL_CreateProperties();
SDL_SetNumberProperty(props, SDL_PROP_TEXTINPUT_CAPITALIZATION_NUMBER, SDL_CAPITALIZE_NONE);
//SDL_StartTextInput(g->win);
//props = SDL_PROP_TEXTINPUT_ANDROID_INPUTTYPE_NUMBER |
//props = SDL_PROP_TEXTINPUT_CAPITALIZATION_NUMBER |
SDL_StartTextInputWithProperties(g->win, props);
} else {
SDL_StopTextInput(g->win);
}
}
Obviously the general case would look cleaner/simpler but you get the idea. BTW, how do you do the collapsible patch in a comment? Is that automatic when you upload a patch file?
@rswinkle
Does it handle multiple windows correctly?
It handles whatever SDL_Window is referenced by nk_sdl context. This should work just fine if you have one context per window, but will most likely fail if you need to share and/or pass the same context between several windows.
Have you tried it on Android/mobile?
No, I haven't tried it (yet). I'm searching for any platform that utilizes Start/StopTextInput calls and would let me test it quickly. Maybe Steam in BigPicture mode? I've heard that Steam-runtime ships with a modified version of SDL with some virtual-keyboard support.
I'm also thinking about hooking SDL_SetTextInputArea into this demo, but for this one I definitely need a better testing environment.
Honestly I can't remember everything I ran into exactly but based on my commit message the multiple windows thing was a issue that led to my current version.
Hard to tell. If you've used the code from this PR in unchanged form, then it had no chance to work out of the box in multi-window scenario. The working copy I'm using right now has a lot of fixes for this, so maybe I fixed some of those issues already. I might be able to help with more specific info.
Obviously the general case would look cleaner/simpler but you get the idea.
Yea, I understand. I will be posting a new PR in few days. I'm working on it right now, but I've encountered some issues. It's taking way more time than I expected... and I don't want to Draft it, because I already have to keep track of several related PRs/Issues (https://github.com/Immediate-Mode-UI/Nuklear/pull/779, https://github.com/Immediate-Mode-UI/Nuklear/pull/772, https://github.com/Immediate-Mode-UI/Nuklear/pull/834, https://github.com/Immediate-Mode-UI/Nuklear/pull/825, https://github.com/Immediate-Mode-UI/Nuklear/issues/768) :weary:
BTW, how do you do the collapsible patch in a comment? Is that automatic when you upload a patch file?
Just type / on the beginning of newline, and you will get a lot of Markdown templates. The one you're asking for is /Details. For syntax highlight for patches, you need to use a code-block like so:
```diff
patch content here
```
or patch instead of diff, but diff is enough when its content was generated with git diff <file>
(there are a lot of features like this one, take a look at some docs https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github )
@rswinkle
Does it handle multiple windows correctly?
It handles whatever
SDL_Windowis referenced bynk_sdlcontext. This should work just fine if you have one context per window, but will most likely fail if you need to share and/or pass the same context between several windows.
Haha, I meant multiple nuklear windows. The issue was related to how nuklear keeps track of its internal state relative to multiple windows and clicking between them. Going from an input field in one to an input field in another and every other possible focus transition you can think of but between windows rather than within one.
Hard to tell. If you've used the code from this PR in unchanged form, then it had no chance to work out of the box in multi-window scenario. The working copy I'm using right now has a lot of fixes for this, so maybe I fixed some of those issues already. I might be able to help with more specific info.
I think I took what the latest version was back then and made lots of changes/fixes. I had recently done several pull requests that touched most/all of the backends so some of that was just bringing those same fixes to the SDL3 backend.
Yea, I understand
I completely understand and empathize. It gets overwhelming fast when you're working on a simple fix/PR and then you find another issue, and another, and oh we should totally change this, but these should probably be different PRs, and that would be too big of a change without pre-approval, and then other stuff is being changed out from under you as well and you just want to be done. sigh
Just type
/
Thanks, my google fu was really weak at 3 am last night. Will try it out later.
Also, I can probably test it out on Android once it's ready. My project was primarily for Android and SDL3's Android build script works pretty well for simple structured projects.
I think we can closed this. All work has moved to https://github.com/Immediate-Mode-UI/Nuklear/pull/852 and was already merged.