Note that the ConfigWindowsMoveFromTitleBarOnly path for UpdateMouseMovingWindowEndFrame() would previously test the window->RootWindow title bar instead of window->RootWindowDockStop. This didn't have any side effect afaik because we wouldn't enter that function anyway as clicking on any tab bar would trigger the move before UpdateMouseMovingWindowEndFrame() does it. However for consistency made the UpdateMouseMovingWindowEndFrame()code more correct.
+ minor renaming
In #2906 the zero input came from a minimized viewport, but even without it we cannot prevent DockNode size from eventually reaching zero as padding are taken from the starting size.
In a separate commit we'll however shortcut some of the existing codepath on zero-sized viewport to reduce the likehood of lossy side-effects (just like we don't call ClampWindowRect in Begin)
Added ability to hover over a draw list's summary stats and see all the contents in wireframe
(cherry picked from commit fd808347bd68a07ad318af6c151028bc9f7b82e7)
The issue would generally manifest when laying out multiple items on a same line, with varying heights and text baseline offsets. (#2833)
Some specific examples, e.g. a button with regular frame padding followed by another item with a multi-line label and no frame padding, such as: multi-line text, small button, tree node item, etc. The second item was correctly offset to match text baseline, and would interact/display correctly,but it wouldn't push the contents area boundary low enough.
Note: previously the second parameter to ItemSize() was 0.0f was default, now -1.0f to signify "no text baseline offset request". If you have code using ItemSize() with an hardcoded zero you may need to change it. (+1 squashed commits)
- Begin() [old 5 args version] -> use Begin() [3 args], use SetNextWindowSize() SetNextWindowBgAlpha() if needed
- IsRootWindowOrAnyChildHovered() -> use IsWindowHovered(ImGuiHoveredFlags_RootAndChildWindows)
- AlignFirstTextHeightToWidgets() -> use AlignTextToFramePadding();
- SetNextWindowPosCenter() -> use SetNextWindowPos() with a pivot of (0.5f, 0.5f)
- ImFont::Glyph -> use ImFontGlyph
If you were still using the old names, read "API Breaking Changes" section of imgui.cpp to find out the new names or equivalent features, or see how they were implemented until 1.73.
Macro is used to ensure that flooring operation is always inlined even in debug builds. __forceinline does not force inlining in /Od builds with MSVC.
(cherry picked from commit bc165df6fd7969605bbc07b8a6d3d28f9109e8f3)
IMPORTANT: Renamed internal CalcTypematicPressedRepeatAmount to CalcTypematicRepeatAmount and reordered the t1, t0 arguments to t0, t1 !!
If you were using a non-default value for io.KeyRepeatRate (previous default was 0.250), you can add +io.KeyRepeatDelay to it to compensate for the fix. The function was triggering on: 0.0 and (delay+rate*N) where (N>=1). Fixed formula responds to (N>=0).
Effectively it made io.KeyRepeatRate behave like it was set to (io.KeyRepeatRate + io.KeyRepeatDelay).
Fixed the code and altered default io.KeyRepeatRate,Delay from 0.250,0.050 to 0.300,0.050 to compensate.
If you never altered io.KeyRepeatRate nor used GetKeyPressedAmount() this won't affect you.
This changeset implements several pieces of the puzzle that add up to a narrow ellipsis rendering.
## EllipsisCodePoint
`ImFontConfig` and `ImFont` received `ImWchar EllipsisCodePoint = -1;` field. User may configure `ImFontConfig::EllipsisCodePoint` a unicode codepoint that will be used for rendering narrow ellipsis. Not setting this field will automatically detect a suitable character or fall back to rendering 3 dots with minimal spacing between them. Autodetection prefers codepoint 0x2026 (narrow ellipsis) and falls back to 0x0085 (NEXT LINE) when missing. Wikipedia indicates that codepoint 0x0085 was used as ellipsis in some older windows fonts. So does default Dear ImGui font. When user is merging fonts - first configured and present ellipsis codepoint will be used, ellipsis characters from subsequently merged fonts will be ignored.
## Narrow ellipsis
Rendering a narrow ellipsis is surprisingly not straightforward task. There are cases when ellipsis is bigger than the last visible character therefore `RenderTextEllipsis()` has to hide last two characters. In a subset of those cases ellipsis is as big as last visible character + space before it. `RenderTextEllipsis()` tries to work around this case by taking free space between glyph edges into account. Code responsible for this functionality is within `if (text_end_ellipsis != text_end_full) { ... }`.
## Fallback (manually rendered dots)
There are cases when font does not have ellipsis character defined. In this case RenderTextEllipsis() falls back to rendering ellipsis as 3 dots, but with reduced spacing between them. 1 pixel space is used in all cases. This results in a somewhat wider ellipsis, but avoids issues where spaces between dots are uneven (visible in larger/monospace fonts) or squish dots way too much (visible in default font where dot is essentially a pixel). This fallback method obsoleted `RenderPixelEllipsis()` and this function was removed. Note that fallback ellipsis will always be somewhat wider than it could be, however it will fit in visually into every font used unlike what `RenderPixelEllipsis()` produced.
