Needlessly introduced in baae057a from WIP tables branch at the time, ended up unused by Tables.
A comment "I find it counter intuitive that hovering supersedes activation." in #3516 led me to this however this is not the cause of said issue.
This commit is a preparation toward adding ImGui apis with explicit context
and making ImGui applications being able to use multiple context at the same time
whatever their concurrency model.
--
Prior to this commit ImGuiInputTextState::OnKeyPressed was depending on the
global context to know which font and font size to use, and if it should
follow MacOSX behaviors or not (c.f ConfigMacOSXBehaviors).
Instead of using the global context, this commit store the context as
attribute of ImGuiInputTextState. Since this state is forwarded to most
of text edit related function, it possible to access font, font size and
ConfigMacOSXBehaviors from everywhere.
NOTE: I have noticed a bug prior to that commit: if the font or font size
change while editing the same widget, the ImGuiInputTextState become invalid
and there is no code to handle this invalidation. Fixing this bug is out
of scope of current pull request.
# Conflicts:
# imgui_internal.h
- Added SetKeyOwner(), SetItemKeyOwner(), TestKeyOwner().
- Added new IsKeyXXX IsMouseXXX functions with ImGuID owner_id and flags.
- Obsoleted SetItemUsingMouseWheel(). (#2891)
- Removed IsKeyPresseedEx() which was a recent internal addition 2022-07-08 deemed to be temporary exactly for this.
- Added ImGuiButtonFlags_NoSetKeyOwner, ImGuiButtonFlags_NoTestKeyOwner
- Added ImGuiSelectableFlags_NoSetKeyOwner.
- Added ImGuiInputFlags_LockThisFrame, ImGuiInputFlags_LockUntilRelease for for SetKeyOwner(), SetItemKeyOwner().
- Added ImGuiInputFlags_CondXXX values for SetItemKeyOwner().
Intended as part of work for input routing + blind menu processing shortcuts. Some of this commit will be stripped by next commit.
Intent was to sort windows along with focus scope to build a hierarchy, but for our needs we'd need a persistant one, so scrapping the idea. Not squashing this with next commit to keep a bit of history for future references.
This put an extra flag check in ItemAdd() but essentially reduce inconsistency with windows decorations not using this. Useful for debugging.
It however buries the info/blurs the line about what it means to not use ItemAdd() since they are now doing it much less.
+ TabBar: starts displaying the unsaved document marker with a frame delay to match how close button is processed, otherwise the transition would be noticeable.
Replace BeginMenu/MenuItem swapping g.NavWindow with a more adequate ImGuiItemFlags_NoWindowHoverableCheck.
Expecting more subtle issues to stem from this.
Note that NoWindowHoverableCheck is not supported by IsItemHovered() but then IsItemHovered() on BeginMenu() never worked: fix should be easy in BeginMenu() + add test is IsItemHovered(), will do later
As it turns out, functions like IsItemHovered() won't work on an open BeginMenu() because LastItemData is overriden by BeginPopup(). Probably an easy fix.
Changed signature of GetKeyChordName() to use ImGuiKeyChord.
Additionally SetActiveIdUsingAllKeyboardKeys() doesn't set ImGuiKey_ModXXX but we never need/use those and the system will be changed in upcoming commits.
Amend bda2cde6
Fixes the case where following menu hover sequence results in incorrect RestoreNavWindow (previously SourceWindow) pointing to opened sub-menu:
1. Hover "Menu -> Options" - Open ##Menu_01 window
2. Hover "Menu -> Colors" - SourceWindow incorrectly points to ##Menu_01 window
