Merge branch 'master' into docking

# Conflicts:
#	imgui.cpp

docs/CHANGELOG.txt

@@ -47,7 +47,14 @@ Breaking Changes:
   of directly poking to io.ConfigColorEditFlags. More consistent and easier to discover.
 - Drag and Drop: commented out legacy name `ImGuiDragDropFlags_SourceAutoExpirePayload`
   which obsoleted in 1.90.9 (July 2024). Use `ImGuiDragDropFlags_PayloadAutoExpire`.
-
+- DragXXX, SliderXXX, InputScalar: with `ImGuiItemFlags_LiveEditOnInputScalar` now
+  defaulting to being disabled: inputting a value with the keyboard doesn't write
+  intermediate values to the backing variable. (#9476)
+    Before: DragFloat() with user typing "123" --> write back 1, then 12, then 123.
+    After:  DragFloat() with user typing "123" --> write back 123 when validated/unfocused.
+  You can enable the flag back for a given scope if needed by specific widget/behavior.
+- ImDrawData: marked `CmdListsCount` as obsolete (technically was obsoleted in 1.89.8).
+    Before: `draw_data->CmdListsCount`, After: `draw_data->CmdLists.Size`.
 
 Other Changes:
 
@@ -63,9 +70,13 @@ Other Changes:
 - Added `ImGuiItemFlags_LiveEditOnInputText` and `ImGuiItemFlags_LiveEditOnInputScalar`
   flags to configure the timing of applying edits of backing variables when typing
   values using a keyboard.
-  (#701, #9476, #3936, #3946, #5904, #6284, #8149, #8065, #8665, #9117, #9299, #700, #1351,
+  (#9476, #701, #3936, #3946, #5904, #6284, #8149, #8065, #8665, #9117, #9299, #700, #1351,
    #1875, #2060, #2215, #2380, #2550, #3083, #3338, #3556, #4373, #4714, #4885, #5184,
    #5777, #6707, #6766, #8004, #8303, #8915, #9308)
+  - ImGuiItemFlags_LiveEditOnInputText is enabled by default (same as before):
+    - The expectation is that for strings/text, enabling LiveEdit is a better default.
+  - ImGuiItemFlags_LiveEditOnInputScalar is disabled by default (new behavior):
+    - The expectation is that for numeric/scalars values, disabling LiveEdit is a better default.
   - Until now:
     - Edits where always applied immediately to backing variable, which is equivalent
       to the `ImGuiItemFlags_LiveEditXXX` flags being enabled.
@@ -76,28 +87,25 @@ Other Changes:
       Workarounds often required a backing store for scalar values, and there were
       also a few niggles related to `IsItemDeactivatedAfterEdit()` when using +/-
       buttons of an `InputInt()` widgets.
-      Many of those situations can now be naturally simplified by disabling
-      `ImGuiItemFlags_LiveEditOnInputScalar`, which is expected to become the default.
+    - Many of those situations can now be naturally simplified when disabling
+      `ImGuiItemFlags_LiveEditOnInputScalar` is disabled.
   - The new flags allows disabling this behavior selectively for strings fields
     such as `InputText()` vs scalar fields: `SliderInt()`, `InputFloat()`, etc.
     - When LiveEdit is disabled, edits are applied when pressing enter, tabbing out,
       clearing a field or deactivating due to a focus loss.
-    - The flag may be altered programmatically:
-        PushItemFlag(ImGuiItemFlags_LiveEditOnInputScalar, false); // Disable for scalars
+    - The flag may be altered programmatically, e.g. for the entire frame scope:
+        NewFrame();
+        PushItemFlag(ImGuiItemFlags_LiveEditOnInputScalar, true); // Enable for scalars for the whole frame
+        ....
+        PopItemFlag();
+        EndFrame();
+      Or for a specific widget:
+        PushItemFlag(ImGuiItemFlags_LiveEditOnInput, true);       // Enable for one widget
         SliderInt(...);
         PopItemFlag();
-        PushItemFlag(ImGuiItemFlags_LiveEditOnInput, true);        // Enable for all
-        SliderInt(...);
-        PopItemFlag();
-      But with upcoming new defaults it is expected you shouldn't touch them much.
-  - Both flags currently defaults to true, which matches previous behavior.
-    - The expectation is that for strings/text, enabling LiveEdit is a better default.
-    - The expectation is that for scalars, disable LiveEdit is a better default.
-    - The short-term intent is to change `ImGuiItemFlags_LiveEditOnInputScalar` to
-      default to being disabled, as soon as we get more feedback from users (SOON).
   - We intentionally are not adding `io.ConfigLiveEditXXX` fields to dictate the
-    default value of each `ImGuiItemFlags_LiveEditXXX`, because this is not
-    expected to be a user preference but a programmer/widget preferences.
+    default value of each `ImGuiItemFlags_LiveEditXXX`, because this is not expected
+    to be a user preference but a programmer/widget preferences.
     Also, we strive to make the toolkit consistent.
 - InputText:
   - Added `style.InputTextCursorSize` to configure cursor/caret thickness. (#7031, #9409)
@@ -3929,8 +3937,10 @@ Breaking changes:
   input queue. This is automatically cleared by io.ClearInputKeys(). (#4921)
 - ImDrawData: CmdLists[] array is now owned, changed from 'ImDrawList**' to
   'ImVector<ImDrawList*>'. Majority of users shouldn't be affected, but you
-  cannot compare to NULL nor reassign manually anymore.
-  Instead use AddDrawList(). Allocation count are identical. (#6406, #4879, #1878)
+  cannot compare to NULL nor reassign manually anymore. (#6406, #4879, #1878)
+  - Allocation count are identical.
+  - Use `draw_data->CmdLists.Size` instead of `draw_list->CmdListsCount`!
+  - Use `AddDrawList()` to add to a `ImDrawData`.
 
 Other changes:
 

docs/FAQ.md

@@ -25,7 +25,7 @@ or view this file with any Markdown viewer.
 | [I integrated Dear ImGui in my engine and some elements are clipping or disappearing when I move windows around...](#q-i-integrated-dear-imgui-in-my-engine-and-some-elements-are-clipping-or-disappearing-when-i-move-windows-around) |
 | [I integrated Dear ImGui in my engine and some elements are displaying outside their expected windows boundaries...](#q-i-integrated-dear-imgui-in-my-engine-and-some-elements-are-displaying-outside-their-expected-windows-boundaries) |
 | **Q&A: Usage** |
-| **[About the ID Stack system...](#q-about-the-id-stack-system)**<br>**[How can I have multiple widgets with the same label?](#q-how-can-i-have-multiple-widgets-with-the-same-label) (using `##` or `PushID()`)**<br>**[How can I have widgets with an empty label?](#q-how-can-i-have-widgets-with-an-empty-label) (using `##`)**<br>**[How can I animate the label of an existing widget?](#q-how-can-i-change-the-label-of-an-existing-widget) (using `###`)**<br>**[General description of the label and ID Stack system.](#general-description-of-the-label-and-id-stack-system)** |
+| **[About the ID Stack system...](#q-about-the-id-stack-system)**<br>**[How can I have multiple widgets with the same label?](#q-how-can-i-have-multiple-widgets-with-the-same-label) (using `##` or `PushID()`)**<br>**[How can I have widgets with an empty label?](#q-how-can-i-have-widgets-with-an-empty-label) (using `##`)**<br>**[How can I make a label dynamic?](#q-how-can-i-make-a-label-dynamic) (using `###`)**<br>**[General description of the label and ID Stack system.](#general-description-of-the-label-and-id-stack-system)** |
 | [How can I display an image?](#q-how-can-i-display-an-image)<br>[What are ImTextureID/ImTextureRef?](#q-what-are-imtextureidimtextureref)|
 | [How can I use maths operators with ImVec2?](#q-how-can-i-use-maths-operators-with-imvec2) |
 | [How can I use my own maths types instead of ImVec2/ImVec4?](#q-how-can-i-use-my-own-maths-types-instead-of-imvec2imvec4) |
@@ -85,16 +85,17 @@ Here's a very simplified comparison between the approach taken by Dear ImGui vs
 |--------------------------|--------------------------|
 | UI fully issued on every update. | UI issued once then later modified. |
 | UI layout is fully dynamic and can change at any time.<BR>UI is generally emitted programmatically, which empowers reflecting a dynamic set of data. | UI layout is mostly static.<BR>UI may be emitted programmatically or from data created by offline tools. UI need extra code to evolve, which is often tedious and error-prone if it needs to be reflecting dynamic data and systems. |
-| Application can submit UI based on arbitrary logic and then forget about it. | Application needs more bookkeeping of UI elements. |
+| UI system is optimized for the worst case and designed to be optimal even under frequent changes. | UI system is optimized for the case where nothing changes. Performances tends to degrade when anything changes. |
+| Application can submit UI based on arbitrary logic without bookkeeping all aspects of that logic. | Application needs more bookkeeping of UI elements. |
 | UI library stores minimal amounts of data. At one point in time, it typically doesn't know or remember which other widgets are displayed and which widgets are coming next. As a result, certain layout features (alignment, resizing) are not as easy to implement or require ad-hoc code. | UI library stores entire widgets tree and state. UI library can use this retained data to easily layout things. |
 | UI code may be added anywhere.<BR>You can even create UI to edit a local variable! | UI code needs to be added in dedicated spots. |
 | UI layout/logic/action/data bindings are all nearby in the code. | UI layout/logic/action/data bindings in distinct functions, files or formats. |
 | Data is naturally always synchronized. | Use callback/signal/slot for synchronizing data (error-prone). |
-| API is simple and easy to learn. In particular, doing basic things is very easy. | API is more complex and specialized. |
-| API is low-level (raw language types). | API are higher-level (more abstractions, advanced language features). |
-| Less fancy look and feel. | Standard look and feel. |
+| API is simple and easy to learn. In particular, doing basic things is very easy.<BR>Attractive to more programmers. | API is more complex and specialized.<BR>Tends to require specialized programmers. |
+| API is low-level. Few abstractions, uses raw language types and your existing data. | API are higher-level. More abstractions, advanced language features. |
+| Less fancy look and feel. But keeps improving :) | Standard look and feel. |
 | Compile yourself. Easy to debug, hack, modify, study. | Mostly use precompiled libraries. Compiling, modifying or studying is daunting if not impossible. |
-| Run on every platform. | Run on limited desktop platforms. |
+| Run on every platform (incl. web, consoles, mobiles, legacy systems). | Run on major desktop platforms. |
 
 Idiomatic Dear ImGui code:
 ```cpp