STB sprintf allows extra formats like %b or %$d. If ImGui is configured
to use STB sprintf, it generates warnings with GCC and clang when using
such formats because it keeps applying default printf-style warnings.
This commit disables printf-style warnings when using STB sprintf.
Since the printf-style warnings are defined in imgui.h based on the
compiler, IMGUI_USE_STB_SPRINTF can't just be defined in the cpp file
anymore and it's been moved as a proper config in imconfig.h.
FocusScopeId is tracked by nav scoring/request and stored in result.
It's all rather WIP and we should reorganize the SetNavIDXXX functions fiasco at some point (soon?).
Didn't separate FocusScope from SelectionScope for now, will re-investigate this later, this is the minimum commit to be able to do some styling.
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.
