Nonblock popup/Passthrough input

[Jukaio]

Thanks for Nuklear. It's my favourite immidiate gui api :)

In any case, I'm having a bang on docking and window layouts, and I'd need a way to display a window always on top but never consume the input. I'd then do any sort of checks with widget bounds and do other state changes manually.

I want this kind of overlay window to propagate the layouting visually to the user

So pretty much, draw window, ignore all input, but always stay on top.

How would I go on about this? If it's even possible to begin with.

[RobLoach]

Could disable the elemeents?

[Jukaio]

But the input is not going through then, no? Let me attach a screenshot to show you what I am asking about, I managed to make it work with one or two line changes in Nuklear.h which is fine for me, but I thought maybe there is a better way. :D

I am dragging the window, and I need to still be able to window to get dragged around. I am not doing much to remember which window is still dragged, i.e., continue making the owner of the pop-up follow the cursor by remembering the offset from cursor to point in title bar, etc.
Instead, I simply made the pop-up "pass-through" so it does not block any input anymore. (I added a NK_WINDOW_INPUT_PASSTHROUGH) flag (just called window_* to stay coherent with the other flags) which only works with popups though and windows assert on it.

Then all the issues I had before disappeared.

So my question is: Is there a way to get that logic in without Nuklear.h changes so a window receives input even if a pop-up is open or in the way? (I am completely fine if the answer is a simple "no, not supported")

[sleeptightAnsiC]

I'm afraid this is currently not supported, and not possible to do reliably.
I would expect such feature to exist as part of nk_popup_* but those are broken right now due to #842
However, feel free to share your patch, maybe there is something I am missing.

As a workaround, you may try following:

1. create two separate nk_context and set them up
2. to the 1st context, record all widgets as usual
3. to the 2nd context, only record widgets that must appear "on top"
4. apply all input to the 1st context as usual (and NEVER apply any input to the 2nd context)
5. draw 1st context
6. draw 2nd context

^ This should (in theory) solve every single problem similar to the one you have here. It might be an overkill because our backends preallocate bunch of memory for each context, but this is something you have control of, anyway.

[sleeptightAnsiC]

I honestly always wanted to try it, so here is a snippet that makes it possible with demo/sdl3_renderer. Some backends hardcode reference to only one context, so it might not be possible to get it working there, but the sdl3_renderer one should be fine:

CLICK ME

diff --git a/demo/sdl3_renderer/main.c b/demo/sdl3_renderer/main.c
index d7e54e2..2d0d807 100644
--- a/demo/sdl3_renderer/main.c
+++ b/demo/sdl3_renderer/main.c
@@ -171,6 +171,7 @@ struct nk_sdl_app {
     SDL_Window* window;
     SDL_Renderer* renderer;
     struct nk_context * ctx;
+    struct nk_context * ctx2;
     struct nk_colorf bg;
     enum nk_anti_aliasing AA;
 };
@@ -187,6 +188,7 @@ SDL_AppInit(void** appstate, int argc, char* argv[])
 {
     struct nk_sdl_app* app;
     struct nk_context* ctx;
+    struct nk_context* ctx2;
     float font_scale;
     NK_UNUSED(argc);
     NK_UNUSED(argv);
@@ -228,7 +230,9 @@ SDL_AppInit(void** appstate, int argc, char* argv[])
     }
 
     ctx = nk_sdl_init(app->window, app->renderer, nk_sdl_allocator());
+    ctx2= nk_sdl_init(app->window, app->renderer, nk_sdl_allocator());
     app->ctx = ctx;
+    app->ctx2= ctx2;
 
 #if 0
     {
@@ -277,11 +281,16 @@ SDL_AppInit(void** appstate, int argc, char* argv[])
         /*font = nk_font_atlas_add_from_file(atlas, "../../../extra_font/Cousine-Regular.ttf", 13 * font_scale, &config);*/
         nk_sdl_font_stash_end(ctx);
 
+        atlas = nk_sdl_font_stash_begin(ctx2);
+        font = nk_font_atlas_add_default(atlas, 13 * font_scale, &config);
+        nk_sdl_font_stash_end(ctx2);
+
         /* this hack makes the font appear to be scaled down to the desired
          * size and is only necessary when font_scale > 1 */
         font->handle.height /= font_scale;
         /*nk_style_load_all_cursors(ctx, atlas->cursors);*/
         nk_style_set_font(ctx, &font->handle);
+        nk_style_set_font(ctx2, &font->handle);
 
         app->AA = NK_ANTI_ALIASING_ON;
     }
@@ -321,6 +330,7 @@ SDL_AppIterate(void *appstate)
 {
     struct nk_sdl_app* app = (struct nk_sdl_app*)appstate;
     struct nk_context* ctx = app->ctx;
+    struct nk_context* ctx2= app->ctx2;
 
 #ifdef INCLUDE_CONFIGURATOR
     static struct nk_color color_table[NK_COLOR_COUNT];
@@ -364,6 +374,14 @@ SDL_AppIterate(void *appstate)
     }
     nk_end(ctx);
 
+    if (nk_begin(ctx2, "always on to", nk_rect(200, 200, 300, 100), NK_WINDOW_BORDER|NK_WINDOW_TITLE))
+    {
+        nk_layout_row_dynamic(ctx2, 20, 1);
+        nk_label(ctx2, "this thing is always on top", NK_TEXT_LEFT);
+        nk_label(ctx2, "and should never block your input", NK_TEXT_LEFT);
+    }
+    nk_end(ctx2);
+
     /* -------------- EXAMPLES ---------------- */
     #ifdef INCLUDE_CALCULATOR
         calculator(ctx);
@@ -386,6 +404,7 @@ SDL_AppIterate(void *appstate)
     SDL_RenderClear(app->renderer);
 
     nk_sdl_render(ctx, app->AA);
+    nk_sdl_render(ctx2, app->AA);
     nk_sdl_update_TextInput(ctx);
 
     /* show if TextInput is active for debug purpose. Feel free to remove this. */

2026-03-02_19-19-32.mp4

[Jukaio]

Two contexts! Oh my God!
That is actually incredibly smart. I cannot believe I did not think about layering nk_context.
Thank you, this idea might not be as handy right now for me cause it will add a bit too much code for my taste for something as simple as a single pass-through popup, but it will be super beneficial for the long term.

As you said, a bit overkill. Let me share the changes I made (Maybe it is a direction the project likes): Jukaio/pillow@cd1d2df#diff-8c75d2ca0784f9f5bbf70fb8aec63e963ae7bd9beed24d9f4c1c6933a23f34f8R1518

Again, thank you very much and I really like your suggestion. Especially if I find more than just the window-tiling popup :D

Also, my github skills are limited, so I am not as well equipped as you do share the code as nicely as you did @sleeptightAnsiC

[sleeptightAnsiC]

[...] create two separate nk_context and set them up [...] It might be an overkill because our backends preallocate bunch of memory for each context

[...] it will add a bit too much code for my taste for something as simple as a single pass-through popup [...] As you said, a bit overkill.

Yea, but it should be an "ultimate" solution, and in case you need even more layers, this will also work. With a little bit of hackery you might be able to just "clone" the 2nd context from the 1st one, right after the 1st was setup, so it won't have to go through font baking (and so on...)

Let me share the changes I made (Maybe it is a direction the project likes): Jukaio/pillow@cd1d2df

Scrapped that patch and reapplied it by hand. It looks like this:

CLICK ME

diff --git a/src/nuklear.h b/src/nuklear.h
index 6fa6220..7cecd59 100644
--- a/src/nuklear.h
+++ b/src/nuklear.h
@@ -1307,7 +1307,8 @@ enum nk_panel_flags {
     NK_WINDOW_SCROLL_AUTO_HIDE  = NK_FLAG(7),
     NK_WINDOW_BACKGROUND        = NK_FLAG(8),
     NK_WINDOW_SCALE_LEFT        = NK_FLAG(9),
-    NK_WINDOW_NO_INPUT          = NK_FLAG(10)
+    NK_WINDOW_NO_INPUT          = NK_FLAG(10),
+    NK_WINDOW_PASSTHROUGH       = NK_FLAG(11)
 };
 
 /**
diff --git a/src/nuklear_popup.c b/src/nuklear_popup.c
index 6091a85..7b81e68 100644
--- a/src/nuklear_popup.c
+++ b/src/nuklear_popup.c
@@ -63,6 +63,8 @@ nk_popup_begin(struct nk_context *ctx, enum nk_popup_type type,
     popup->layout = (struct nk_panel*)nk_create_panel(ctx);
     popup->flags = flags;
     popup->flags |= NK_WINDOW_BORDER;
+    /* TODO: This needs to get fixed so the passthrough control is coherent with the rest of the APIs here!*/
+    popup->flags = popup->flags & (~NK_WINDOW_PASSTHROUGH);
     if (type == NK_POPUP_DYNAMIC)
         popup->flags |= NK_WINDOW_DYNAMIC;
 
@@ -73,17 +75,19 @@ nk_popup_begin(struct nk_context *ctx, enum nk_popup_type type,
 
     if (nk_panel_begin(ctx, title, NK_PANEL_POPUP)) {
         /* popup is running therefore invalidate parent panels */
-        struct nk_panel *root;
-        root = win->layout;
-        while (root) {
-            root->flags |= NK_WINDOW_ROM;
-            root->flags &= ~(nk_flags)NK_WINDOW_REMOVE_ROM;
-            root = root->parent;
+        if((flags & NK_WINDOW_PASSTHROUGH) == 0) {
+            struct nk_panel* root;
+            root = win->layout;
+            while (root) {
+                root->flags |= NK_WINDOW_ROM;
+                root->flags &= ~(nk_flags)NK_WINDOW_REMOVE_ROM;
+                root = root->parent;
+            }
         }
         win->popup.active = 1;
+        popup->layout->parent = win->layout;   // FIXME: move that line back where it was (see Jukaio's comment)
         popup->layout->offset_x = &popup->scrollbar.x;
         popup->layout->offset_y = &popup->scrollbar.y;
-        popup->layout->parent = win->layout;
         return 1;
     } else {
         /* popup was closed/is invalid so cleanup */
diff --git a/src/nuklear_window.c b/src/nuklear_window.c
index 4cd0c19..1a2dc71 100644
--- a/src/nuklear_window.c
+++ b/src/nuklear_window.c
@@ -153,6 +153,7 @@ nk_begin_titled(struct nk_context *ctx, const char *name, const char *title,
     NK_ASSERT(title);
     NK_ASSERT(ctx->style.font && ctx->style.font->width && "if this triggers you forgot to add a font");
     NK_ASSERT(!ctx->current && "if this triggers you missed a `nk_end` call");
+    NK_ASSERT(!(flags & NK_WINDOW_PASSTHROUGH) && "Windows cannot be passthrough - Not implemented, only popups!");
     if (!ctx || ctx->current || !title || !name)
         return 0;
 

Didn't have any time to test, but just from experience, it will most likely break when you start using anything else based on nk_popup (again, it would probably be fault of #842)

Also, why did you move the popup->layout->parent = win->layout; line? I found it suspicious so I left this change in the diff, but I don't really see the reason.

Thanks anyway. I may take a look into this someday. I think we'll need something more general than just a flag for window/popup, something that would allow for having different layers entirely, and for stopping/starting input recording. (DISCLAIMER: not promising anything 😅 )

my github skills are limited, so I am not as well equipped as you do share the code as nicely as you did

Hah, not the first time hearing this. Take a look at the very very bottom of this comment: #779 (comment)

[sleeptightAnsiC]

Also, what was the reason for NOT using NK_WINDOW_NO_INPUT in the first place? It would still block the input, right? My guess would be to just spawn a window with said flag and programmatically raise it on top (don't remember exactly how to do this) but I guess this would still cause some problems?

[Jukaio]

Moved it by accident since it is simple "working" code on my end 😄
There is zero reason why I moved it.

Cheers for the code suggestion. So it is common markdown for code. Keep forgetting GitHub supports it.

Also, what was the reason for NOT using NK_WINDOW_NO_INPUT in the first place? It would still block the input, right? My guess would be to just spawn a window with said flag and programmatically raise it on top (don't remember exactly how to do this), but I guess this would still cause some problems?

I tried it, and there were always small issues. Input not getting picked up, for example. It was mostly due to my esoteric usage, and popups working with pass-through input haven't gotten much thought.

Personally, I am fine using my own fork/version of Nuklear.h, but I also try to work as much with the public API as possible to add convenient additions on top of Nuklear.
Small usage example:

		if (nk_begin(ctx, "Editor N", bounds, flags)) {
			if (nk_dock_popup(ctx, bounds.x, bounds.y, bounds.w, bounds.h)) {
				nk_layout_row_dynamic(ctx, 42.0f, 1);
				nk_button_label(ctx, "Docked");
			}
		}

And then each user of nk_dock_popup would receive the functionality. With the pop-up limitation in mind, I just thought that if a pop-up is active, I do not show the tiling pop-up since the default behaviour is not allowing input to go through anyway, at least to the window spawning the pop-up. Unless I miss something about pop-ups.

Another approach of mine was to piggyback on the overlay command buffer, but sadly, it seems to only work for the mouse cursor.

When I have finished a window dock, I might come back with a pull request, and we can discuss the approach. Worst case is a simple diff that can easily get applied, best case is that we find a nice common ground.

I am very satisfied with your answers btw. It was extremely helpful :D So besides discussing the future, there is not much more from my end haha

[sleeptightAnsiC]

@RobLoach I don't mind keeping this Issue open. None of our workarounds seem "elegant" enough so the problem still exists. Given all the context, I don't believe this will be possible to solve any time soon, but I'll try to revisit it in the future. Feel free to reopen. I'll trust your judgement here ;)

[RobLoach]

Seems rather niche? As a user, if I have a window that's always-on-top, I'd still expect to be able to interact with it. Clicking on the window and having the input pass through seems like a bug 🙃

[Jukaio]

Passing-through shouldn't be that niche.
Press CTRL to make the first window pass-through so you can click on the window behind it. As soon as this concept translates to widgets, I think it's rather reasonable to have.

Ignore input would also be an acceptable term, and might be better than calling it pass-through.

From my experience being able to ignore input (not just no input, but instead letting the input just go through) is a simple step to enable tools through imgui to enable more complex compositions... All my use cases just happen to be overlays cause apparently I really like overlays.

With the unity ongui callback I've done all sorts of these shenanigans. I don't even remember if they had ignore input or if I also just emulated it. The need for it usually comes as soon as you allow transparency. Or if you don't want to stop the user doing her action, and you let input pass through until the mouse button is back up, and then the user can put her attention to the new window or popup that showed up during a user's resize, move, or worse, text input event.
But these are just my two cents and I wanted to propagate my "user opinion". You can just ignore if it doesn't align with you.

Anyway, I implemented the first big steps of what I wanted to achieve - that gives a rounder and final perspective for the sake of the issue ticket:

Cutting.mp4