How to disable Ctrl-tab menu ?

[DaveInDev]

Version: Dear ImGui 1.77 WIP (17601)
Branch: master
Back-ends: SFML
Compiler: VS2019 c++
Operating System: win10x64

Hi,

How do I disable the Ctrl-tab menu ?
Because I would like to use ctrl-tab to manage my own window navigation logic, including other Non-Imgui windows.

[ocornut]

Hello,

Ctrl+Tab handling is currently enabled with keyboard navigation, aka setting the ImGuiConfigFlags_NavEnableKeyboard configuration flag.

In theory we could add detailed flags to enable/disable subfeatures of keyboard navigation but I'd be interested in figuring out a more general way of dispatching inputs where you would somehow mark the ctrl+tab as handled and nav system won't handle that.

Pragmatically it may be faster to expose those enable/disable flags sooner (I can think of situation where e.g. it would also be good to selectively enable/disable page up/page down).

[DaveInDev]

Thanks. Reading the comments in the main code, I did not figure out what was covered by the term "navigation" : now I understand better (I just found in the demo code the explanation that I missed ).

Alas, the other features of navigation (esc, space, enter) were useful to me. But infact I am stupid : I just can steal this precise ctrl-tab event just before the call to ImGui::ProcessEvent... It should not be a problem, is it ?

For your suggestions, indead, a way to handle these inputs separately, or maybe to reaffect theses naviguation keys would be great. By the way, what do you mean by "expose flags sooner" ? I read this expression a lot of time in the issues, but I do not understand what it means.

[ocornut]

I just can steal this precise ctrl-tab event just before the call to ImGui::ProcessEvent

You can't really steal or claim to handle inputs, that's my point. The only think you can do is to clear inputs manually before passing them to NewFrame() but that's not going to work for operations that rely on more context (Ctrl+Tab doesn't rely on much context, but say, PageUp depends on the active widget). Additionally there's no ProcessEvent function in dear imgui so I'm not sure what you are referring to. Inputs are exposed and available thorough the frame.

"Expose flags" = "add flags"
"Sooner" as is, not "later" ??

I'm saying we could always add flags to select which feature to enable, but this is ultimately not the right solution (the right solution is to have a way to dispatch inputs, and it's going to be complex considering how dear imgui work), but the right solution being complex maybe it's ok to add the flags soon instead of waiting forever for the right solution..

[DaveInDev]

Sorry, the ProcessEvent function is from the SFML backend, to send an event to ImGui from the event polling loop of my app : ImGui::SFML::ProcessEvent(event) .

So, by stealing, I really mean not sending this particular ctrl-tab event to ImGui at all (thru the ImGuiIO object I suppose). I agree that it cannot be a solution for more complex keys that works only on some precise widgets.

"Sooner" as is, not "later" ??

:-D I was more interested in the meaning you were giving to "expose".

For the perfect solution of "dispatching inputs", as ImGui is always working "one frame later" (or is not aware of its full state until the end of the frame due to its inherent immediate mode), I cannot figure out how you could dispatch inputs ahead.

Imho, a few flags could definitely do the job.

[ocornut]

Moving followup to #4828

[ocornut]

Pushed a few new features and you can now do:

#include "imgui_internal.h"

// Disable CTRL+Tab shortcuts (global): assign a "None" route to steal the route to our two shortcuts
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiKey_Tab, ImGuiKeyOwner_None);
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiMod_Shift | ImGuiKey_Tab, ImGuiKeyOwner_None);

or

// Disable CTRL+Tab shortcuts (if focused): assign a "None" route to steal the route to our two shortcuts, applies focus testing so will only apply if window is in focus chain
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiKey_Tab, ImGuiKeyOwner_None, ImGuiInputFlags_RouteFocused);
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiMod_Shift | ImGuiKey_Tab, ImGuiKeyOwner_None, ImGuiInputFlags_RouteFocused);

However, as per #4828 we made the exception to allow remapping CTRL+Tab windowing system. Therefore technically the right shortcut needs to be pulled:

if (g.ConfigNavWindowingKeyNext)
    ImGui::SetShortcutRouting(g.ConfigNavWindowingKeyNext, ImGuiKeyOwner_None);
if (g.ConfigNavWindowingKeyPrev)
    ImGui::SetShortcutRouting(g.ConfigNavWindowingKeyPrev, ImGuiKeyOwner_None);

But this is only if you want to both allow remapping AND disabling of the shortcuts.

(cross posted to #3255 and #5641)

[liamwhan]

Can I ask where this is supposed to happen? When I try to call the first (global) example I hit this IM_ASSERT in imgui.cpp L8583 in commit 6ccc561:

 IM_ASSERT(owner_id != ImGuiKeyOwner_Any && owner_id != ImGuiKeyOwner_None);

Pushed a few new features and you can now do:

#include "imgui_internal.h"

// Disable CTRL+Tab shortcuts (global): assign a "None" route to steal the route to our two shortcuts
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiKey_Tab, ImGuiKeyOwner_None);
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiMod_Shift | ImGuiKey_Tab, ImGuiKeyOwner_None);

or

// Disable CTRL+Tab shortcuts (if focused): assign a "None" route to steal the route to our two shortcuts, applies focus testing so will only apply if window is in focus chain
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiKey_Tab, ImGuiKeyOwner_None, ImGuiInputFlags_RouteFocused);
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiMod_Shift | ImGuiKey_Tab, ImGuiKeyOwner_None, ImGuiInputFlags_RouteFocused);

However, as per #4828 we made the exception to allow remapping CTRL+Tab windowing system. Therefore technically the right shortcut needs to be pulled:

if (g.ConfigNavWindowingKeyNext)
    ImGui::SetShortcutRouting(g.ConfigNavWindowingKeyNext, ImGuiKeyOwner_None);
if (g.ConfigNavWindowingKeyPrev)
    ImGui::SetShortcutRouting(g.ConfigNavWindowingKeyPrev, ImGuiKeyOwner_None);

But this is only if you want to both allow remapping AND disabling of the shortcuts.

(cross posted to #3255 and #5641)

[dimateos]

Yep I also crash when trying to redirect the routing to ImGuiKeyOwner_NoOwner as explained in #5641, same assert as you. Seems like this is disallowed explicitly:

imgui/imgui.cpp

Line 9226 in d78e823

IM_ASSERT(owner_id != ImGuiKeyOwner_Any && owner_id != ImGuiKeyOwner_NoOwner);

❓ :: Is it still possible to "steal" routings and assign them to nothing? So far, the current issue is the only time I actually needed it tho (due to it being an internal imgui routing).

Also note that some of the API has changed:

• ImGuiKeyOwner_None -> ImGuiKeyOwner_NoOwner
• SetShortcutRouting function signature
  • The second param now indicates ImGuiInputFlags, not the owner_id
  • By default the routing is ImGuiInputFlags_RouteFocused, so I guess here we would want ImGuiInputFlags_RouteAlways instead

#include "imgui_internal.h"

// REF:: https://github.com/ocornut/imgui/issues/5641 -> crashes with last master branch?
// called every frame, right?
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiKey_Tab, ImGuiInputFlags_RouteAlways, ImGuiKeyOwner_NoOwner);
ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiMod_Shift | ImGuiKey_Tab, ImGuiInputFlags_RouteAlways, ImGuiKeyOwner_NoOwner);

But editing the context navkeys as in #4828 works:

#include "imgui_internal.h"

// REF:: https://github.com/ocornut/imgui/issues/4828
// called once! at some point will be moved to `ImGuiIO`, so there will be no need to include imgui_internal.h
ImGuiContext& g = *GImGui;
g.ConfigNavWindowingKeyNext = 0;
g.ConfigNavWindowingKeyPrev = 0;

[ocornut]

@liamwhan

Can I ask where this is supposed to happen? When I try to call the first (global) example I hit this IM_ASSERT in imgui.cpp L8583 in commit 6ccc561:

Sorry for my late answer.
The instructions in this thread for generic rerouting are obsolete.

---

About specifically disabling CTRL+TAB ONLY
However as pushed by 6ccc561 and mentioned above if you specifically only want to disable CTRL+Tab you can do:

g.ConfigNavWindowingKeyNext = 0; // replace the default which is `ImGuiMod_Ctrl | ImGuiKey_Tab`
g.ConfigNavWindowingKeyPrev = 0; // replace the default which is `ImGuiMod_Ctrl | ImGuiMod_Shift | ImGuiKey_Tab`.

Full details there: #4828 (comment)

---

About GENERIC shortcut routing (which can be leverage for everything, not just CTRL+Tab).
Since I posted this thread, those API have been reworked and some have been moving to public space.

• (1) Parameters 2 and 3 have been swapped since the prototype.
  So ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiKey_Tab, ImGuiKeyOwner_None);
  Should be ImGui::SetShortcutRouting(ImGuiMod_Ctrl | ImGuiKey_Tab, ImGuiInputFlags_None, ImGuiKeyOwner_NoOwner);
• (2) ImGuiKeyOwner_None was previously accepted by SetShortcutRouting() was a shortcut to use the current focus scope, but it's been disallowed because it is error prone. However the higher level Shortcut() accept this.
• (As for ImGuiInputFlags_None, it is guaranteed to be 0 like every other value called _None value in dear imgui. I have renamed ImGuiKeyOwner_None to ImGuiKeyOwner_NoOwner partly to keep that distinction.)

So effectively now you can do:

ImGui::Shortcut(ImGuiMod_Ctrl | ImGuiKey_Tab, ImGuiInputFlags_RouteGlobal);
ImGui::Shortcut(ImGuiMod_Ctrl | ImGuiMod_Shift | ImGuiKey_Tab, ImGuiInputFlags_RouteGlobal);

Some examples have been added in the demo:

And there are more examples in a temporary "demo_input_owner_and_routing" branch:
master...features/demo_input_owner_and_routing
The reason those examples are currently in a branch is because the third parameter "owner_id" wasn't added to the public API yet, so any example that uses them is still in this branch, but you can refer to it for more ways to take advantage of those features.

[ocornut]

Strangely I have replied to Liam before seeing Diego answer, which says basically the same thing. Both answers complement each others and are going in the same direction.