IsWindowAppearing + SetKeyboardFocusHere not focusing keyboard on first open

[ghost]

No description provided.

[ocornut]

Please specify which exact version because we made changes to those functions recently.

[ocornut]

Thank you for confirming this. I think this is the same as #343. I'm going to look at this now.

[ocornut]

Also, I was previously using a copy of dear imgui from about August 2020, and I wasn't getting this bug then. I upgraded to master HEAD yesterday, and this bug appeared.

Having investigated I believe this statement may be incorrect, I also know understand how subtle factors can invalidate some tests you could have done. Since this is a clipping issue, last known window size would affect it, and e.g not using ImGuiWindowFlags_AlwaysAutoResize would in most cases reduce the issue to the first session (before .ini file is created) as on next sessions the window would have a stored size, leading the widget to not be clipped.
If you are firmly convinced it worked in the August 2020 I would be interested in you double-checking that with a clean state (including same or cleared .ini data), but I suspect the different may be due to different window size or .ini data.

Actually spent a while digging on this but it is a rather nasty problem to fully solve (had a bunch of related work done a while ago, almost spent a week on this but didn't finish). I would want to solve it.

I just committed some partial refactor (393941c) which is getting us closer to being able to move the focusable registration before clipping, as it is now performed in ItemAdd() literally clipping and focus registration are now next to each others...

...However they can't be trivially swapped yet because it would require us to scroll to keep target item visible in order to be useful (if you Tab out of sight it would be wrong). So while doing that simple swap would fix #4079 and #343 it would currently come with a bigger regression in term of user experience.

Given the current code we have access to the positional data too late in the frame since scroll needs to be locked in Begin(). So with current code structure the dumb solution would requires us to first focus/tab the next widget on frame N and then scroll on frame N+1, which is the kind of horrible scrolling experience you'd expect from an Android TV.

So right now I don't have a nice answer for it but

• the commit above makes further experiments easier to do
• I sense we may be able to come up with a partial solution which would at least satisfy this and SetKeyboardFocusHere focus broken in popups / with clipping #343
• will dig further into my unfinished branches which once finished could positively impact this, SetKeyboardFocusHere focus broken in popups / with clipping #343, as well as Clipper & Vertical scrolling. Unsure how to scroll to active item when it's no longer visible? #3578, Programmatically activating widget? #3949, Explicitly setting widget state / activating widget? #3985 and probably other issues.
• doing this today also made me add a few extra regression tests and fix another tabbing issues.

Repro

ImGui::Begin("Another Window", &show_another_window, ImGuiWindowFlags_AlwaysAutoResize);   // Pass a pointer to our bool variable (the window will have a closing button that will clear the bool when clicked)

static char query[256] = "";

ImGui::Text("Search for file:");
if (ImGui::IsWindowAppearing())
    ImGui::SetKeyboardFocusHere();
ImGui::InputText("##search_for_file", query, 256);

ImGui::Text("Hello from another window!");
if (ImGui::Button("Close Me"))
    show_another_window = false;
ImGui::End();

[ocornut]

Better late than never.... using SetKeyboardFocusHere() on non-visible item is finally fixed by 31d033c + 8f495e5.
It was particularly trickier than meet-the-eyes but satisfied with current version.

(I'm not done with the refactor as Tabbing currently doesn't scroll, I still have a few things I don't yet know how to solve for the tabbing but we are nearly there).