SetNextFrameWantCaptureKeyboard() not setting WantCaptureKeyboard

[microlith57]

On the current latest docking commit; running example_sdl2_opengl3 on Linux Mint.

Dear ImGui 1.90 WIP (18998)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=201103
define: __linux__
define: __GNUC__=11
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_sdl2
io.BackendRendererName: imgui_impl_opengl3
io.ConfigFlags: 0x00000443
 NavEnableKeyboard
 NavEnableGamepad
 DockingEnable
 ViewportsEnable
io.ConfigViewportsNoDecoration
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x00001C0E
 HasMouseCursors
 HasSetMousePos
 PlatformHasViewports
 HasMouseHoveredViewport
 RendererHasVtxOffset
 RendererHasViewports
--------------------------------
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,64
io.DisplaySize: 1280.00,720.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00

My Issue/Question:

When hovering over (and clicking on) the pink rectangle in the WantCapture override demo, with the SetNextFrameWantCaptureKeyboard toggle set to false, WantCaptureKeyboard is not actually set to false (which is what I expected).
This is not the case for the mouse.

Screenshots/Video

Standalone, minimal, complete and verifiable example: If the demo does not suffice for this I can create one.

[ocornut]

Keyboard navigation currently always enforces it:

// Update io.WantCaptureKeyboard for the user application (true = dispatch keyboard info to Dear ImGui only, false = dispatch keyboard info to Dear ImGui + underlying app)
if (g.WantCaptureKeyboardNextFrame != -1)
    io.WantCaptureKeyboard = (g.WantCaptureKeyboardNextFrame != 0);
else
    io.WantCaptureKeyboard = (g.ActiveId != 0) || (modal_window != NULL);

if (io.NavActive && (io.ConfigFlags & ImGuiConfigFlags_NavEnableKeyboard) && !(io.ConfigFlags & ImGuiConfigFlags_NavNoCaptureKeyboard))
    io.WantCaptureKeyboard = true;

Which perhaps makes the SetNextFrameWantCaptureKeyboard() function misleading, but I would worry if you can override it everytime it'd be easier to make mistakes.

I would need to dig/design further. I'd be also interested in know about your use case for SetNextFrameWantCaptureKeyboard(), so we can design with a use case in context.

Thanks!

[microlith57]

I hadn't got a specific use case in mind; I found this when browsing the demos trying to understand keyboard capturing and thought it might be a bug.
It makes sense that keyboard navigation overrides it, though I think that probably deserves a mention in the demo.

The use case I have that lead me to this was to allow my application to capture keyboard inputs when the mouse is not hovering any ImGui windows; having to click on empty space is cumbersome (as I have an ImGui window for tool selection, and clicking in empty space would apply the newly selected tool, which is not always what the user wants).
I'm fairly certain that NavNoCaptureKeyboard will work well for this (thank you for pointing that out!)

[ocornut]

I have pushed 6f171a0 to make an explicit call to SetNextFrameWantCaptureKeyboard(false) the definitive source of truth, seems more consistent. In case people were relying on the other behavior they can always reproduce it locally, while it's not possible in the other direction.