|
@@ -40,19 +40,19 @@ DOCUMENTATION
|
|
|
- How can I tell whether to dispatch mouse/keyboard to imgui or to my application?
|
|
|
- How can I display an image? What is ImTextureID, how does it works?
|
|
|
- How can I have multiple widgets with the same label or with an empty label? A primer on labels and the ID Stack.
|
|
|
- - How can I use my own math types instead of ImVec2/ImVec4?
|
|
|
+ - How can I use my own math types instead of ImVec2/ImVec4?
|
|
|
- How can I load a different font than the default?
|
|
|
- How can I easily use icons in my application?
|
|
|
- How can I load multiple fonts?
|
|
|
- How can I display and input non-latin characters such as Chinese, Japanese, Korean, Cyrillic?
|
|
|
- - How can I interact with standard C++ types (such as std::string and std::vector)?
|
|
|
+ - How can I interact with standard C++ types (such as std::string and std::vector)?
|
|
|
- How can I use the drawing facilities without an ImGui window? (using ImDrawList API)
|
|
|
- How can I use Dear ImGui on a platform that doesn't have a mouse or a keyboard? (input share, remoting, gamepad)
|
|
|
- I integrated Dear ImGui in my engine and the text or lines are blurry..
|
|
|
- I integrated Dear ImGui in my engine and some elements are clipping or disappearing when I move windows around..
|
|
|
- How can I help?
|
|
|
|
|
|
-CODE
|
|
|
+CODE
|
|
|
(search for "[SECTION]" in the code to find them)
|
|
|
|
|
|
// [SECTION] FORWARD DECLARATIONS
|
|
@@ -207,7 +207,7 @@ CODE
|
|
|
ImGui_ImplDX11_RenderDrawData(ImGui::GetDrawData());
|
|
|
g_pSwapChain->Present(1, 0);
|
|
|
}
|
|
|
-
|
|
|
+
|
|
|
// Shutdown
|
|
|
ImGui_ImplDX11_Shutdown();
|
|
|
ImGui_ImplWin32_Shutdown();
|
|
@@ -278,7 +278,7 @@ CODE
|
|
|
// TODO: Setup shader: vertex { float2 pos, float2 uv, u32 color }, fragment shader sample color from 1 texture, multiply by vertex color.
|
|
|
for (int n = 0; n < draw_data->CmdListsCount; n++)
|
|
|
{
|
|
|
- const ImDrawList* cmd_list = draw_data->CmdLists[n];
|
|
|
+ const ImDrawList* cmd_list = draw_data->CmdLists[n];
|
|
|
const ImDrawVert* vtx_buffer = cmd_list->VtxBuffer.Data; // vertex buffer generated by ImGui
|
|
|
const ImDrawIdx* idx_buffer = cmd_list->IdxBuffer.Data; // index buffer generated by ImGui
|
|
|
for (int cmd_i = 0; cmd_i < cmd_list->CmdBuffer.Size; cmd_i++)
|
|
@@ -299,7 +299,7 @@ CODE
|
|
|
// (some elements visible outside their bounds) but you can fix that once everything else works!
|
|
|
// - Clipping coordinates are provided in imgui coordinates space (from draw_data->DisplayPos to draw_data->DisplayPos + draw_data->DisplaySize)
|
|
|
// In a single viewport application, draw_data->DisplayPos will always be (0,0) and draw_data->DisplaySize will always be == io.DisplaySize.
|
|
|
- // However, in the interest of supporting multi-viewport applications in the future (see 'viewport' branch on github),
|
|
|
+ // However, in the interest of supporting multi-viewport applications in the future (see 'viewport' branch on github),
|
|
|
// always subtract draw_data->DisplayPos from clipping bounds to convert them to your viewport space.
|
|
|
// - Note that pcmd->ClipRect contains Min+Max bounds. Some graphics API may use Min+Max, other may use Min+Size (size being Max-Min)
|
|
|
ImVec2 pos = draw_data->DisplayPos;
|
|
@@ -316,13 +316,13 @@ CODE
|
|
|
|
|
|
- The examples/ folders contains many actual implementation of the pseudo-codes above.
|
|
|
- When calling NewFrame(), the 'io.WantCaptureMouse', 'io.WantCaptureKeyboard' and 'io.WantTextInput' flags are updated.
|
|
|
- They tell you if Dear ImGui intends to use your inputs. When a flag is set you want to hide the corresponding inputs
|
|
|
+ They tell you if Dear ImGui intends to use your inputs. When a flag is set you want to hide the corresponding inputs
|
|
|
from the rest of your application. In every cases you need to pass on the inputs to imgui. Refer to the FAQ for more information.
|
|
|
- Please read the FAQ below!. Amusingly, it is called a FAQ because people frequently run into the same issues!
|
|
|
|
|
|
USING GAMEPAD/KEYBOARD NAVIGATION CONTROLS
|
|
|
|
|
|
- - The gamepad/keyboard navigation is fairly functional and keeps being improved.
|
|
|
+ - The gamepad/keyboard navigation is fairly functional and keeps being improved.
|
|
|
- Gamepad support is particularly useful to use dear imgui on a console system (e.g. PS4, Switch, XB1) without a mouse!
|
|
|
- You can ask questions and report issues at https://github.com/ocornut/imgui/issues/787
|
|
|
- The initial focus was to support game controllers, but keyboard is becoming increasingly and decently usable.
|
|
@@ -382,7 +382,7 @@ CODE
|
|
|
- 2018/12/10 (1.67) - renamed io.ConfigResizeWindowsFromEdges to io.ConfigWindowsResizeFromEdges as we are doing a large pass on configuration flags.
|
|
|
- 2018/10/12 (1.66) - renamed misc/stl/imgui_stl.* to misc/cpp/imgui_stdlib.* in prevision for other C++ helper files.
|
|
|
- 2018/09/28 (1.66) - renamed SetScrollHere() to SetScrollHereY(). Kept redirection function (will obsolete).
|
|
|
- - 2018/09/06 (1.65) - renamed stb_truetype.h to imstb_truetype.h, stb_textedit.h to imstb_textedit.h, and stb_rect_pack.h to imstb_rectpack.h.
|
|
|
+ - 2018/09/06 (1.65) - renamed stb_truetype.h to imstb_truetype.h, stb_textedit.h to imstb_textedit.h, and stb_rect_pack.h to imstb_rectpack.h.
|
|
|
If you were conveniently using the imgui copy of those STB headers in your project you will have to update your include paths.
|
|
|
- 2018/09/05 (1.65) - renamed io.OptCursorBlink/io.ConfigCursorBlink to io.ConfigInputTextCursorBlink. (#1427)
|
|
|
- 2018/08/31 (1.64) - added imgui_widgets.cpp file, extracted and moved widgets code out of imgui.cpp into imgui_widgets.cpp. Re-ordered some of the code remaining in imgui.cpp.
|
|
@@ -399,7 +399,7 @@ CODE
|
|
|
old binding will still work as is, however prefer using the separated bindings as they will be updated to be multi-viewport conformant.
|
|
|
when adopting new bindings follow the main.cpp code of your preferred examples/ folder to know which functions to call.
|
|
|
- 2018/06/06 (1.62) - renamed GetGlyphRangesChinese() to GetGlyphRangesChineseFull() to distinguish other variants and discourage using the full set.
|
|
|
- - 2018/06/06 (1.62) - TreeNodeEx()/TreeNodeBehavior(): the ImGuiTreeNodeFlags_CollapsingHeader helper now include the ImGuiTreeNodeFlags_NoTreePushOnOpen flag. See Changelog for details.
|
|
|
+ - 2018/06/06 (1.62) - TreeNodeEx()/TreeNodeBehavior(): the ImGuiTreeNodeFlags_CollapsingHeader helper now include the ImGuiTreeNodeFlags_NoTreePushOnOpen flag. See Changelog for details.
|
|
|
- 2018/05/03 (1.61) - DragInt(): the default compile-time format string has been changed from "%.0f" to "%d", as we are not using integers internally any more.
|
|
|
If you used DragInt() with custom format strings, make sure you change them to use %d or an integer-compatible format.
|
|
|
To honor backward-compatibility, the DragInt() code will currently parse and modify format strings to replace %*f with %d, giving time to users to upgrade their code.
|
|
@@ -579,7 +579,7 @@ CODE
|
|
|
A: Short explanation:
|
|
|
- You may use functions such as ImGui::Image(), ImGui::ImageButton() or lower-level ImDrawList::AddImage() to emit draw calls that will use your own textures.
|
|
|
- Actual textures are identified in a way that is up to the user/engine. Those identifiers are stored and passed as ImTextureID (void*) value.
|
|
|
- - Loading image files from the disk and turning them into a texture is not within the scope of Dear ImGui (for a good reason).
|
|
|
+ - Loading image files from the disk and turning them into a texture is not within the scope of Dear ImGui (for a good reason).
|
|
|
Please read documentations or tutorials on your graphics API to understand how to display textures on the screen before moving onward.
|
|
|
|
|
|
Long explanation:
|
|
@@ -587,10 +587,10 @@ CODE
|
|
|
At the end of the frame those meshes (ImDrawList) will be displayed by your rendering function. They are made up of textured polygons and the code
|
|
|
to render them is generally fairly short (a few dozen lines). In the examples/ folder we provide functions for popular graphics API (OpenGL, DirectX, etc.).
|
|
|
- Each rendering function decides on a data type to represent "textures". The concept of what is a "texture" is entirely tied to your underlying engine/graphics API.
|
|
|
- We carry the information to identify a "texture" in the ImTextureID type.
|
|
|
+ We carry the information to identify a "texture" in the ImTextureID type.
|
|
|
ImTextureID is nothing more that a void*, aka 4/8 bytes worth of data: just enough to store 1 pointer or 1 integer of your choice.
|
|
|
Dear ImGui doesn't know or understand what you are storing in ImTextureID, it merely pass ImTextureID values until they reach your rendering function.
|
|
|
- - In the examples/ bindings, for each graphics API binding we decided on a type that is likely to be a good representation for specifying
|
|
|
+ - In the examples/ bindings, for each graphics API binding we decided on a type that is likely to be a good representation for specifying
|
|
|
an image from the end-user perspective. This is what the _examples_ rendering functions are using:
|
|
|
|
|
|
OpenGL: ImTextureID = GLuint (see ImGui_ImplGlfwGL3_RenderDrawData() function in imgui_impl_glfw_gl3.cpp)
|
|
@@ -598,13 +598,13 @@ CODE
|
|
|
DirectX11: ImTextureID = ID3D11ShaderResourceView* (see ImGui_ImplDX11_RenderDrawData() function in imgui_impl_dx11.cpp)
|
|
|
DirectX12: ImTextureID = D3D12_GPU_DESCRIPTOR_HANDLE (see ImGui_ImplDX12_RenderDrawData() function in imgui_impl_dx12.cpp)
|
|
|
|
|
|
- For example, in the OpenGL example binding we store raw OpenGL texture identifier (GLuint) inside ImTextureID.
|
|
|
- Whereas in the DirectX11 example binding we store a pointer to ID3D11ShaderResourceView inside ImTextureID, which is a higher-level structure
|
|
|
+ For example, in the OpenGL example binding we store raw OpenGL texture identifier (GLuint) inside ImTextureID.
|
|
|
+ Whereas in the DirectX11 example binding we store a pointer to ID3D11ShaderResourceView inside ImTextureID, which is a higher-level structure
|
|
|
tying together both the texture and information about its format and how to read it.
|
|
|
- If you have a custom engine built over e.g. OpenGL, instead of passing GLuint around you may decide to use a high-level data type to carry information about
|
|
|
the texture as well as how to display it (shaders, etc.). The decision of what to use as ImTextureID can always be made better knowing how your codebase
|
|
|
is designed. If your engine has high-level data types for "textures" and "material" then you may want to use them.
|
|
|
- If you are starting with OpenGL or DirectX or Vulkan and haven't built much of a rendering engine over them, keeping the default ImTextureID
|
|
|
+ If you are starting with OpenGL or DirectX or Vulkan and haven't built much of a rendering engine over them, keeping the default ImTextureID
|
|
|
representation suggested by the example bindings is probably the best choice.
|
|
|
(Advanced users may also decide to keep a low-level type in ImTextureID, and use ImDrawList callback and pass information to their renderer)
|
|
|
|
|
@@ -612,7 +612,7 @@ CODE
|
|
|
|
|
|
// Cast our texture type to ImTextureID / void*
|
|
|
MyTexture* texture = g_CoffeeTableTexture;
|
|
|
- ImGui::Image((void*)texture, ImVec2(texture->Width, texture->Height));
|
|
|
+ ImGui::Image((void*)texture, ImVec2(texture->Width, texture->Height));
|
|
|
|
|
|
The renderer function called after ImGui::Render() will receive that same value that the user code passed:
|
|
|
|
|
@@ -645,7 +645,7 @@ CODE
|
|
|
// Now that we have an OpenGL texture, assuming our imgui rendering function (imgui_impl_xxx.cpp file) takes GLuint as ImTextureID, we can display it:
|
|
|
ImGui::Image((void*)(intptr_t)my_opengl_texture, ImVec2(my_image_width, my_image_height));
|
|
|
|
|
|
- C/C++ tip: a void* is pointer-sized storage. You may safely store any pointer or integer into it by casting your value to ImTexture / void*, and vice-versa.
|
|
|
+ C/C++ tip: a void* is pointer-sized storage. You may safely store any pointer or integer into it by casting your value to ImTexture / void*, and vice-versa.
|
|
|
Because both end-points (user code and rendering function) are under your control, you know exactly what is stored inside the ImTexture / void*.
|
|
|
Examples:
|
|
|
|
|
@@ -667,7 +667,7 @@ CODE
|
|
|
|
|
|
Dear ImGui internally need to uniquely identify UI elements.
|
|
|
Elements that are typically not clickable (such as calls to the Text functions) don't need an ID.
|
|
|
- Interactive widgets (such as calls to Button buttons) need a unique ID.
|
|
|
+ Interactive widgets (such as calls to Button buttons) need a unique ID.
|
|
|
Unique ID are used internally to track active widgets and occasionally associate state to widgets.
|
|
|
Unique ID are implicitly built from the hash of multiple elements that identify the "path" to the UI element.
|
|
|
|
|
@@ -777,7 +777,7 @@ CODE
|
|
|
e.g. when displaying a list of objects, using indices or pointers as ID will preserve the
|
|
|
node open/closed state differently. See what makes more sense in your situation!
|
|
|
|
|
|
- Q: How can I use my own math types instead of ImVec2/ImVec4?
|
|
|
+ Q: How can I use my own math types instead of ImVec2/ImVec4?
|
|
|
A: You can edit imconfig.h and setup the IM_VEC2_CLASS_EXTRA/IM_VEC4_CLASS_EXTRA macros to add implicit type conversions.
|
|
|
This way you'll be able to use your own types everywhere, e.g. passsing glm::vec2 to ImGui functions instead of ImVec2.
|
|
|
|
|
@@ -787,7 +787,7 @@ CODE
|
|
|
io.Fonts->AddFontFromFileTTF("myfontfile.ttf", size_in_pixels);
|
|
|
io.Fonts->GetTexDataAsRGBA32() or GetTexDataAsAlpha8()
|
|
|
Default is ProggyClean.ttf, monospace, rendered at size 13, embedded in dear imgui's source code.
|
|
|
- (Tip: monospace fonts are convenient because they allow to facilitate horizontal alignment directly at the string level.)
|
|
|
+ (Tip: monospace fonts are convenient because they allow to facilitate horizontal alignment directly at the string level.)
|
|
|
(Read the 'misc/fonts/README.txt' file for more details about font loading.)
|
|
|
|
|
|
New programmers: remember that in C/C++ and most programming languages if you want to use a
|
|
@@ -798,7 +798,7 @@ CODE
|
|
|
|
|
|
Q: How can I easily use icons in my application?
|
|
|
A: The most convenient and practical way is to merge an icon font such as FontAwesome inside you
|
|
|
- main font. Then you can refer to icons within your strings.
|
|
|
+ main font. Then you can refer to icons within your strings.
|
|
|
You may want to see ImFontConfig::GlyphMinAdvanceX to make your icon look monospace to facilitate alignment.
|
|
|
(Read the 'misc/fonts/README.txt' file for more details about icons font loading.)
|
|
|
|
|
@@ -850,14 +850,14 @@ CODE
|
|
|
(such as CP-923 for Japanese or CP-1251 for Cyrillic) will NOT work!
|
|
|
Otherwise you can convert yourself to UTF-8 or load text data from file already saved as UTF-8.
|
|
|
|
|
|
- Text input: it is up to your application to pass the right character code by calling io.AddInputCharacter().
|
|
|
- The applications in examples/ are doing that.
|
|
|
+ Text input: it is up to your application to pass the right character code by calling io.AddInputCharacter().
|
|
|
+ The applications in examples/ are doing that.
|
|
|
Windows: you can use the WM_CHAR or WM_UNICHAR or WM_IME_CHAR message (depending if your app is built using Unicode or MultiByte mode).
|
|
|
You may also use MultiByteToWideChar() or ToUnicode() to retrieve Unicode codepoints from MultiByte characters or keyboard state.
|
|
|
- Windows: if your language is relying on an Input Method Editor (IME), you copy the HWND of your window to io.ImeWindowHandle in order for
|
|
|
+ Windows: if your language is relying on an Input Method Editor (IME), you copy the HWND of your window to io.ImeWindowHandle in order for
|
|
|
the default implementation of io.ImeSetInputScreenPosFn() to set your Microsoft IME position correctly.
|
|
|
|
|
|
- Q: How can I interact with standard C++ types (such as std::string and std::vector)?
|
|
|
+ Q: How can I interact with standard C++ types (such as std::string and std::vector)?
|
|
|
A: - Being highly portable (bindings for several languages, frameworks, programming style, obscure or older platforms/compilers),
|
|
|
and aiming for compatibility & performance suitable for every modern real-time game engines, dear imgui does not use
|
|
|
any of std C++ types. We use raw types (e.g. char* instead of std::string) because they adapt to more use cases.
|
|
@@ -865,18 +865,18 @@ CODE
|
|
|
- To use combo boxes and list boxes with std::vector or any other data structure: the BeginCombo()/EndCombo() API
|
|
|
lets you iterate and submit items yourself, so does the ListBoxHeader()/ListBoxFooter() API.
|
|
|
Prefer using them over the old and awkward Combo()/ListBox() api.
|
|
|
- - Generally for most high-level types you should be able to access the underlying data type.
|
|
|
+ - Generally for most high-level types you should be able to access the underlying data type.
|
|
|
You may write your own one-liner wrappers to facilitate user code (tip: add new functions in ImGui:: namespace from your code).
|
|
|
- Dear ImGui applications often need to make intensive use of strings. It is expected that many of the strings you will pass
|
|
|
to the API are raw literals (free in C/C++) or allocated in a manner that won't incur a large cost on your application.
|
|
|
Please bear in mind that using std::string on applications with large amount of UI may incur unsatisfactory performances.
|
|
|
- Modern implementations of std::string often include small-string optimization (which is often a local buffer) but those
|
|
|
- are not configurable and not the same across implementations.
|
|
|
- - If you are finding your UI traversal cost to be too large, make sure your string usage is not leading to excessive amount
|
|
|
+ Modern implementations of std::string often include small-string optimization (which is often a local buffer) but those
|
|
|
+ are not configurable and not the same across implementations.
|
|
|
+ - If you are finding your UI traversal cost to be too large, make sure your string usage is not leading to excessive amount
|
|
|
of heap allocations. Consider using literals, statically sized buffers and your own helper functions. A common pattern
|
|
|
- is that you will need to build lots of strings on the fly, and their maximum length can be easily be scoped ahead.
|
|
|
+ is that you will need to build lots of strings on the fly, and their maximum length can be easily be scoped ahead.
|
|
|
One possible implementation of a helper to facilitate printf-style building of strings: https://github.com/ocornut/Str
|
|
|
- This is a small helper where you can instance strings with configurable local buffers length. Many game engines will
|
|
|
+ This is a small helper where you can instance strings with configurable local buffers length. Many game engines will
|
|
|
provide similar or better string helpers.
|
|
|
|
|
|
Q: How can I use the drawing facilities without an ImGui window? (using ImDrawList API)
|
|
@@ -890,15 +890,15 @@ CODE
|
|
|
Q: How can I use this without a mouse, without a keyboard or without a screen? (gamepad, input share, remote display)
|
|
|
A: - You can control Dear ImGui with a gamepad. Read about navigation in "Using gamepad/keyboard navigation controls".
|
|
|
(short version: map gamepad inputs into the io.NavInputs[] array + set io.ConfigFlags |= ImGuiConfigFlags_NavEnableGamepad)
|
|
|
- - You can share your computer mouse seamlessly with your console/tablet/phone using Synergy (https://symless.com/synergy)
|
|
|
- This is the preferred solution for developer productivity.
|
|
|
+ - You can share your computer mouse seamlessly with your console/tablet/phone using Synergy (https://symless.com/synergy)
|
|
|
+ This is the preferred solution for developer productivity.
|
|
|
In particular, the "micro-synergy-client" repository (https://github.com/symless/micro-synergy-client) has simple
|
|
|
- and portable source code (uSynergy.c/.h) for a small embeddable client that you can use on any platform to connect
|
|
|
+ and portable source code (uSynergy.c/.h) for a small embeddable client that you can use on any platform to connect
|
|
|
to your host computer, based on the Synergy 1.x protocol. Make sure you download the Synergy 1 server on your computer.
|
|
|
Console SDK also sometimes provide equivalent tooling or wrapper for Synergy-like protocols.
|
|
|
- - You may also use a third party solution such as Remote ImGui (https://github.com/JordiRos/remoteimgui) which sends
|
|
|
+ - You may also use a third party solution such as Remote ImGui (https://github.com/JordiRos/remoteimgui) which sends
|
|
|
the vertices to render over the local network, allowing you to use Dear ImGui even on a screen-less machine.
|
|
|
- - For touch inputs, you can increase the hit box of widgets (via the style.TouchPadding setting) to accommodate
|
|
|
+ - For touch inputs, you can increase the hit box of widgets (via the style.TouchPadding setting) to accommodate
|
|
|
for the lack of precision of touch inputs, but it is recommended you use a mouse or gamepad to allow optimizing
|
|
|
for screen real-estate and precision.
|
|
|
|
|
@@ -911,7 +911,7 @@ CODE
|
|
|
Rectangles provided by ImGui are defined as (x1=left,y1=top,x2=right,y2=bottom) and NOT as (x1,y1,width,height).
|
|
|
|
|
|
Q: How can I help?
|
|
|
- A: - If you are experienced with Dear ImGui and C++, look at the github issues, look at the Wiki, read docs/TODO.txt
|
|
|
+ A: - If you are experienced with Dear ImGui and C++, look at the github issues, look at the Wiki, read docs/TODO.txt
|
|
|
and see how you want to help and can help!
|
|
|
- Businesses: convince your company to fund development via support contracts/sponsoring! This is among the most useful thing you can do for dear imgui.
|
|
|
- Individuals: you can also become a Patron (http://www.patreon.com/imgui) or donate on PayPal! See README.
|
|
@@ -970,7 +970,9 @@ CODE
|
|
|
#pragma clang diagnostic ignored "-Wsign-conversion" // warning : implicit conversion changes signedness //
|
|
|
#pragma clang diagnostic ignored "-Wformat-pedantic" // warning : format specifies type 'void *' but the argument has type 'xxxx *' // unreasonable, would lead to casting every %p arg to void*. probably enabled by -pedantic.
|
|
|
#pragma clang diagnostic ignored "-Wint-to-void-pointer-cast" // warning : cast to 'void *' from smaller integer type 'int'
|
|
|
+#if __has_warning("-Wzero-as-null-pointer-constant")
|
|
|
#pragma clang diagnostic ignored "-Wzero-as-null-pointer-constant" // warning : zero as null pointer constant // some standard header variations use #define NULL 0
|
|
|
+#endif
|
|
|
#if __has_warning("-Wdouble-promotion")
|
|
|
#pragma clang diagnostic ignored "-Wdouble-promotion" // warning: implicit conversion from 'float' to 'double' when passing argument to function // using printf() is a misery with this as C++ va_arg ellipsis changes float to double.
|
|
|
#endif
|
|
@@ -1065,11 +1067,19 @@ static int FindPlatformMonitorForRect(const ImRect& r);
|
|
|
//-----------------------------------------------------------------------------
|
|
|
|
|
|
// Current context pointer. Implicitly used by all Dear ImGui functions. Always assumed to be != NULL.
|
|
|
-// CreateContext() will automatically set this pointer if it is NULL. Change to a different context by calling ImGui::SetCurrentContext().
|
|
|
-// If you use DLL hotreloading you might need to call SetCurrentContext() after reloading code from this file.
|
|
|
-// ImGui functions are not thread-safe because of this pointer. If you want thread-safety to allow N threads to access N different contexts, you can:
|
|
|
-// - Change this variable to use thread local storage. You may #define GImGui in imconfig.h for that purpose. Future development aim to make this context pointer explicit to all calls. Also read https://github.com/ocornut/imgui/issues/586
|
|
|
-// - Having multiple instances of the ImGui code compiled inside different namespace (easiest/safest, if you have a finite number of contexts)
|
|
|
+// ImGui::CreateContext() will automatically set this pointer if it is NULL. Change to a different context by calling ImGui::SetCurrentContext().
|
|
|
+// 1) Important: globals are not shared across DLL boundaries! If you use DLLs or any form of hot-reloading: you will need to call
|
|
|
+// SetCurrentContext() (with the pointer you got from CreateContext) from each unique static/DLL boundary, and after each hot-reloading.
|
|
|
+// In your debugger, add GImGui to your watch window and notice how its value changes depending on which location you are currently stepping into.
|
|
|
+// 2) Important: Dear ImGui functions are not thread-safe because of this pointer.
|
|
|
+// If you want thread-safety to allow N threads to access N different contexts, you can:
|
|
|
+// - Change this variable to use thread local storage so each thread can refer to a different context, in imconfig.h:
|
|
|
+// struct ImGuiContext;
|
|
|
+// extern thread_local ImGuiContext* MyImGuiTLS;
|
|
|
+// #define GImGui MyImGuiTLS
|
|
|
+// And then define MyImGuiTLS in one of your cpp file. Note that thread_local is a C++11 keyword, earlier C++ uses compiler-specific keyword.
|
|
|
+// - Future development aim to make this context pointer explicit to all calls. Also read https://github.com/ocornut/imgui/issues/586
|
|
|
+// - If you need a finite number of contexts, you may compile and use multiple instances of the ImGui code from different namespace.
|
|
|
#ifndef GImGui
|
|
|
ImGuiContext* GImGui = NULL;
|
|
|
#endif
|
|
@@ -2961,7 +2971,7 @@ void* ImGui::MemAlloc(size_t size)
|
|
|
|
|
|
void ImGui::MemFree(void* ptr)
|
|
|
{
|
|
|
- if (ptr)
|
|
|
+ if (ptr)
|
|
|
if (ImGuiContext* ctx = GImGui)
|
|
|
ctx->IO.MetricsActiveAllocations--;
|
|
|
return GImAllocatorFreeFunc(ptr, GImAllocatorUserData);
|
|
@@ -4170,8 +4180,8 @@ void ImGui::CalcListClipping(int items_count, float items_height, int* out_items
|
|
|
}
|
|
|
|
|
|
// Find window given position, search front-to-back
|
|
|
-// FIXME: Note that we have an inconsequential lag here: OuterRectClipped is updated in Begin(), so windows moved programatically
|
|
|
-// with SetWindowPos() and not SetNextWindowPos() will have that rectangle lagging by a frame at the time FindHoveredWindow() is
|
|
|
+// FIXME: Note that we have an inconsequential lag here: OuterRectClipped is updated in Begin(), so windows moved programatically
|
|
|
+// with SetWindowPos() and not SetNextWindowPos() will have that rectangle lagging by a frame at the time FindHoveredWindow() is
|
|
|
// called, aka before the next Begin(). Moving window isn't affected.
|
|
|
static void FindHoveredWindow()
|
|
|
{
|
|
@@ -7333,8 +7343,8 @@ void ImGui::ClosePopupToLevel(int remaining, bool apply_focus_to_window_under)
|
|
|
|
|
|
// FIXME: This code is faulty and we may want to eventually to replace or remove the 'apply_focus_to_window_under=true' path completely.
|
|
|
// Instead of using g.OpenPopupStack[remaining-1].Window etc. we should find the highest root window that is behind the popups we are closing.
|
|
|
- // The current code will set focus to the parent of the popup window which is incorrect.
|
|
|
- // It rarely manifested until now because UpdateMouseMovingWindow() would call FocusWindow() again on the clicked window,
|
|
|
+ // The current code will set focus to the parent of the popup window which is incorrect.
|
|
|
+ // It rarely manifested until now because UpdateMouseMovingWindow() would call FocusWindow() again on the clicked window,
|
|
|
// leading to a chain of focusing A (clicked window) then B (parent window of the popup) then A again.
|
|
|
// However if the clicked window has the _NoMove flag set we would be left with B focused.
|
|
|
// For now, we have disabled this path when called from ClosePopupsOverWindow() because the users of ClosePopupsOverWindow() don't need to alter focus anyway,
|
|
@@ -9274,8 +9284,8 @@ static void ImGui::NavUpdateWindowing()
|
|
|
// Move to parent menu if necessary
|
|
|
ImGuiWindow* new_nav_window = g.NavWindow;
|
|
|
while (new_nav_window->ParentWindow
|
|
|
- && (new_nav_window->DC.NavLayerActiveMask & (1 << 1)) == 0
|
|
|
- && (new_nav_window->Flags & ImGuiWindowFlags_ChildWindow) != 0
|
|
|
+ && (new_nav_window->DC.NavLayerActiveMask & (1 << 1)) == 0
|
|
|
+ && (new_nav_window->Flags & ImGuiWindowFlags_ChildWindow) != 0
|
|
|
&& (new_nav_window->Flags & (ImGuiWindowFlags_Popup | ImGuiWindowFlags_ChildMenu)) == 0)
|
|
|
new_nav_window = new_nav_window->ParentWindow;
|
|
|
if (new_nav_window != g.NavWindow)
|
|
@@ -9761,7 +9771,7 @@ bool ImGui::BeginDragDropSource(ImGuiDragDropFlags flags)
|
|
|
if (!(flags & ImGuiDragDropFlags_SourceNoPreviewTooltip))
|
|
|
{
|
|
|
// Target can request the Source to not display its tooltip (we use a dedicated flag to make this request explicit)
|
|
|
- // We unfortunately can't just modify the source flags and skip the call to BeginTooltip, as caller may be emitting contents.
|
|
|
+ // We unfortunately can't just modify the source flags and skip the call to BeginTooltip, as caller may be emitting contents.
|
|
|
BeginTooltip();
|
|
|
if (g.DragDropAcceptIdPrev && (g.DragDropAcceptFlags & ImGuiDragDropFlags_AcceptNoPreviewTooltip))
|
|
|
{
|