Please make Axial check optional in NavScoreItem

[hippydave]

My Issue/Question:

I was happy to find the Axial check code as enabling it instantly fixed the issue I was having, navigating horizontally between two "columns" (not imgui columns but Childs) using a gamepad when there are gaps on one side - with it disabled there were places on the other side where trying to move horizontally just did nothing, but in my use case it's desirable to always be able to switch columns.

The code comment suggests you were considering making it an option, I'd appreciate it if you do so I don't have to maintain my modification on updates. Many thanks for the really useful library!

[ocornut]

Please provide screenshot/gifs to showcase exactly the issue you are talking about (without the modification applied).

As well as point out exactly the modification you made. And fill the imgui version number and branch as requested. Thank you!

[hippydave]

Thanks for the reply.

Version/Branch of Dear ImGui:

Version: v1.72 WIP, commit/b443bc0a64d5e22d445d2c9cb52f7f39da6b98c9
Branch: master

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp
Operating System: Nintendo Switch homebrew (compiling on MacOS)

My Issue/Question:

As above, I have a window with two Childs side by side, each using ImGuiWindowFlags_NavFlattened flag so navigation passes between them. The left column has a scrolling list of Selectables, the right column has a checkbox at the top that, when checked, reveals a series of lines with more checkboxes (no scrolling).

Without Axial check, if the navigation is on the left and not reasonably lined up with something on the right, then pressing right does nothing. This is particularly drastic when the top checkbox on the right is unchecked and the rest of the right column is blank, but even when the right column is mostly filled with entries, there are a couple of gaps, so navigating right from the second item in the left hand list does nothing, and (not shown in screenshot) if scrolled down so an item at the very bottom of the screen is selected on the left, navigating right also does nothing.

I couldn't figure out making gifs for this, and it's hard to show no-movement in a gif, so I marked up some screenshots. Green line shows where pressing right from that selection on the left navigates to on the right, red cross means pressing right does nothing.

Screenshots/Video

Original

Mod

Original

Mod

Modification was just changing this line
from
if (g.NavLayer == 1 && !(g.NavWindow->Flags & ImGuiWindowFlags_ChildMenu))

to
if (true)

[ocornut]

Adding note to myself as I am trying to untangle variety of nav issue.
This specific check you are removing was added by ecd72cc with the explanation:

"Nav: Disabled the final axial check when considering candidates in most situations except menubars.
It's definitively undesirable inside Menu as we want to catch nav request failures reliably.
I think it may be considered as an option if we find this desirable i some circumstances. Right now ideally I'd remove it totally but with current scoring setup, without it we can't easily reach the Window Close button."

I think this was a bad take my side, interestingly if the intent was to be able to catch nav request failures (for special handling or for looping/wrapping) we could find another solution.
Some of the context of that old commit was work on e.g.

• 0046c61 Allow to collapse tree nodes with NavLeft and open them with NavRight
• 88a3545 Navigate sibling of a menu-bar while navigating inside one of their child. If a Left<>Right navigation request fails to find a match we forward the request to the root menu

My intuition is that:

• We should re-introduce the axial fallback in more/all cases (which align with intent of this question), in a way that works with aforementioned problem.
• And to counter-balance this, cardinal navigation scoring should be a little more strict.

Among my tests cases, the case of evenly layouted 2D grid of items is particularly interesting:

With traditional scoring, there is a possibility to move from 3.1 to 2.2 using Right Arrow, or 2.2 to 3.1 using Down Arrow.

• This is undesirable with this particular regular layout and an explicitly configured looping/wrapping behavior. But if only 3.1 and 2.2 existed (and no other items) this would be a desirable link.
• So that type of movement should be resolved by the axial fallback and not by typical cardinal scoring.