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.
In particular:
- imgui.cpp : move UpdateInputEvents() higher in NewFrame() to match docking + update RenderMouseCursor() to match.
- imgui_draw.cpp: ImDrawList::_ResetForNewFrame() change from c807192ab
- Backends: SDL2. Add MouseWindowID + change SDL_CaptureMouse() test to match docking branch. Not strictly necessary but aimed at reducing drift because we go on and fork this file.
+ moved responsability of checking valid names to TabBarGetTabName() to simplify both branches.
Only exception being TableSetColumnIndex() with same column number but that's an odd case.
Will break PR #6094#3572#5305#4876 but those not need to be necessarily updated: we got enough reference to finish that feature.
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 is not strictly required presently, but will be consistent with adding inner decoration sizes in next commit, as well as generally being sane.
Locking TitleBarHeight() / MenuBarHeight() values per-window probably have side-effects in ill-defined situation related to changing font size per window.
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
Marc Delorme
ocornut
nahkhiir
Manuel Floruß
assiduous
Teselka