Tagging #6344#6003#2694#1688 as it relates to scoring, however this doesn't technically fix any of them fully yet.
But e.g. once we restore axial path for #2694 this commit will allow going back and forth to initial location.
+ Demo: use BeginDisabled() block in BackendFlags section.
I'd still consider this undefined behavior as some combination may not work properly, but let's fix things while we can as we encounter them.
Altered ItemAdd() clipping rule to keep previous-frame ActiveId unclipped to support that late commit.
Also, MarkItemEdited() may in theory need to do:
if (g.ActiveIdPreviousFrame == id)
g.ActiveIdPreviousFrameHasBeenEditedBefore = true;
But this should already be set so not adding now.
- Afaik the "to allow ImGuiListClipper to function" was added early during Tables development (prior to commit 55) and later replaced by support in ImGuiListCipper, it seems unnecessary.
- Also removed RowPosY2 being accted in TableEndCell().
+ Comments about 2bb9e35 + fix example bb224c8
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.
This commit modifies ImGuiInputTextCallback, ImGuiListClipper and ImGuiStackSize so those classes do not to depend on GImGui context anymore.
About ImGuiInputTextCallback:
- ImGuiInputTextCallback depends on ImGuiContext because it has a
`InsertChars` method adding character to `g.InputTextState`
- To make ImGuiInputTextCallback aware of which context to use, the
appropriate context is given as argument of ImGuiInputTextCallback
constructor.
About ImGuiListClipper:
- ImGuiListClipper apply to a context through its `Begin`, `End`, and `Step`
method.
- To make ImGuiListClipper aware of which context to use, the
appropriate context is given as argument of ImGuiListClipper
constructor.
- Since the behavior is different than previously the class has been
renamed ImGuiListClipperEx
- In order to preserve backward compatibility, a subclass of ImGuiListClipperEx
named ImGuiListClipper has been defined and forward the implicit context
to ImGuiListClipperEx parent.
About ImGuiTextFilter:
- ImGuiTextFilter depends on the implicit context because the Draw(..)
method call ImGui::InputText(...)
- Instead from that commit the Draw(...) method takes an explicit context
as first argument
- Since the behavior is different than previously the class has been
renamed ImGuiTextFilterEx
- In order to preserve backward compatibility, a subclass of ImGuiTextFilterEx
named ImGuiTextFilter has been defined. This subclass has a draw method
override which and forward the implicit context to the parent class Draw(...)
About ImGuiStackSizes:
- ImGuiStackSizes was depending on ImGuiContext because of its
`SetToCurrentState` and `CompareWithCurrentState` method
- ImGuiStackSizes is an helper object use
for comparing state of context. It does not necessarily need to
compare the same context. For that reason, as opposed to previous
classes it takes the context it wants to compare to as argument of
its method.
- For this occasion `SetToCurrentState` and `CompareWithCurrentState`
have been renamed `SetToContextState` and `CompareWithContextState`
to match the new method signature.
ImGuiListClipper
ImGuiInputTextCallbackData
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.
About ImGuiIO:
- ImGuiIO depends on ImGuiContext because some of its method want to event to `g.InputEventQueue`.
- To make ImGuiIO aware of the context to use, context which creates the ImGuiIO is given as argument of ImGuiIO constructor.
- The assert `IM_ASSERT(&g.IO == this && "Can only add events to current context.")` has been removed since it does not make sense anymore
NOTE: ImGuiIO could be completely independent of ImGuiContext if the InputEventQueue was moved from ImGuiContext to ImGuiIO, but since
ImGuiIO is a public class it would expose InputEvent type. Solving this problem is out of the current scope, but it is interesting to notice.
- 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.
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
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.
