|
|
@@ -177,7 +177,7 @@ Each draw command needs the triangle rendered using the clipping rectangle provi
|
|
|
Rectangles provided by Dear ImGui are defined as
|
|
|
`(x1=left,y1=top,x2=right,y2=bottom)`
|
|
|
and **NOT** as
|
|
|
-`(x1,y1,width,height)`
|
|
|
+`(x1,y1,width,height)`.
|
|
|
Refer to rendering backends in the [examples/](https://github.com/ocornut/imgui/tree/master/examples) folder for references of how to handle the `ClipRect` field.
|
|
|
|
|
|
##### [Return to Index](#index)
|
|
|
@@ -196,12 +196,12 @@ A primer on labels and the ID Stack...
|
|
|
|
|
|
Dear ImGui internally needs 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 an unique ID.
|
|
|
|
|
|
-**Unique ID are used internally to track active widgets and occasionally associate state to widgets.<BR>
|
|
|
-Unique ID are implicitly built from the hash of multiple elements that identify the "path" to the UI element.**
|
|
|
+**Unique IDs are used internally to track active widgets and occasionally associate state to widgets.<BR>
|
|
|
+Unique IDs are implicitly built from the hash of multiple elements that identify the "path" to the UI element.**
|
|
|
|
|
|
-Since Dear ImGui 1.85 you can use `Demo>Tools>Stack Tool` or call `ImGui::ShowStackToolWindow()`. The tool display intermediate values leading to the creation of a unique ID, making things easier to debug and understand.
|
|
|
+Since Dear ImGui 1.85, you can use `Demo>Tools>Stack Tool` or call `ImGui::ShowStackToolWindow()`. The tool display intermediate values leading to the creation of a unique ID, making things easier to debug and understand.
|
|
|
|
|
|
|
|
|
|
|
|
@@ -243,9 +243,9 @@ End();
|
|
|
Fear not! This is easy to solve and there are many ways to solve it!
|
|
|
|
|
|
- Solving ID conflict in a simple/local context:
|
|
|
-When passing a label you can optionally specify extra ID information within string itself.
|
|
|
+When passing a label you can optionally specify extra ID information within the string itself.
|
|
|
Use "##" to pass a complement to the ID that won't be visible to the end-user.
|
|
|
-This helps solving the simple collision cases when you know e.g. at compilation time which items
|
|
|
+This helps solve the simple collision cases when you know e.g. at compilation time which items
|
|
|
are going to be created:
|
|
|
```cpp
|
|
|
Begin("MyWindow");
|
|
|
@@ -260,7 +260,7 @@ End();
|
|
|
Checkbox("##On", &b); // Label = "", ID = hash of (..., "##On") // No visible label, just a checkbox!
|
|
|
```
|
|
|
- Occasionally/rarely you might want to change a label while preserving a constant ID. This allows
|
|
|
-you to animate labels. For example you may want to include varying information in a window title bar,
|
|
|
+you to animate labels. For example, you may want to include varying information in a window title bar,
|
|
|
but windows are uniquely identified by their ID. Use "###" to pass a label that isn't part of ID:
|
|
|
```cpp
|
|
|
Button("Hello###ID"); // Label = "Hello", ID = hash of (..., "###ID")
|
|
|
@@ -273,9 +273,9 @@ Begin(buf); // Variable title, ID = hash of "MyGame"
|
|
|
Use `PushID()` / `PopID()` to create scopes and manipulate the ID stack, as to avoid ID conflicts
|
|
|
within the same window. This is the most convenient way of distinguishing ID when iterating and
|
|
|
creating many UI elements programmatically.
|
|
|
-You can push a pointer, a string or an integer value into the ID stack.
|
|
|
-Remember that ID are formed from the concatenation of _everything_ pushed into the ID stack.
|
|
|
-At each level of the stack we store the seed used for items at this level of the ID stack.
|
|
|
+You can push a pointer, a string, or an integer value into the ID stack.
|
|
|
+Remember that IDs are formed from the concatenation of _everything_ pushed into the ID stack.
|
|
|
+At each level of the stack, we store the seed used for items at this level of the ID stack.
|
|
|
```cpp
|
|
|
Begin("Window");
|
|
|
for (int i = 0; i < 100; i++)
|
|
|
@@ -320,8 +320,8 @@ if (TreeNode("node")) // <-- this function call will do a PushID() for you (unl
|
|
|
}
|
|
|
```
|
|
|
|
|
|
-When working with trees, ID are used to preserve the open/close state of each tree node.
|
|
|
-Depending on your use cases you may want to use strings, indices or pointers as ID.
|
|
|
+When working with trees, IDs are used to preserve the open/close state of each tree node.
|
|
|
+Depending on your use cases you may want to use strings, indices, or pointers as ID.
|
|
|
- e.g. when following a single pointer that may change over time, using a static string as ID
|
|
|
will preserve your node open/closed state when the targeted object change.
|
|
|
- e.g. when displaying a list of objects, using indices or pointers as ID will preserve the
|
|
|
@@ -342,10 +342,10 @@ Short explanation:
|
|
|
**Please read documentations or tutorials on your graphics API to understand how to display textures on the screen before moving onward.**
|
|
|
|
|
|
Long explanation:
|
|
|
-- Dear ImGui's job is to create "meshes", defined in a renderer-agnostic format made of draw commands and vertices. 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.).
|
|
|
+- Dear ImGui's job is to create "meshes", defined in a renderer-agnostic format made of draw commands and vertices. 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 APIs (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.
|
|
|
-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.
|
|
|
+ImTextureID is nothing more than a void*, aka 4/8 bytes worth of data: just enough to store one pointer or integer of your choice.
|
|
|
Dear ImGui doesn't know or understand what you are storing in ImTextureID, it merely passes ImTextureID values until they reach your rendering function.
|
|
|
- In the [examples/](https://github.com/ocornut/imgui/tree/master/examples) backends, for each graphics API 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:
|
|
|
```cpp
|
|
|
@@ -371,9 +371,9 @@ DirectX12:
|
|
|
For example, in the OpenGL example backend we store raw OpenGL texture identifier (GLuint) inside ImTextureID.
|
|
|
Whereas in the DirectX11 example backend 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 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 by 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 representation suggested by the example backends 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)
|
|
|
+(Advanced users may also decide to keep a low-level type in ImTextureID, use ImDrawList callback and pass information to their renderer)
|
|
|
|
|
|
User code may do:
|
|
|
```cpp
|
|
|
@@ -387,15 +387,15 @@ The renderer function called after ImGui::Render() will receive that same value
|
|
|
MyTexture* texture = (MyTexture*)pcmd->GetTexID();
|
|
|
MyEngineBindTexture2D(texture);
|
|
|
```
|
|
|
-Once you understand this design you will understand that loading image files and turning them into displayable textures is not within the scope of Dear ImGui.
|
|
|
-This is by design and is actually a good thing, because it means your code has full control over your data types and how you display them.
|
|
|
-If you want to display an image file (e.g. PNG file) into the screen, please refer to documentation and tutorials for the graphics API you are using.
|
|
|
+Once you understand this design, you will understand that loading image files and turning them into displayable textures is not within the scope of Dear ImGui.
|
|
|
+This is by design and is a good thing because it means your code has full control over your data types and how you display them.
|
|
|
+If you want to display an image file (e.g. PNG file) on the screen, please refer to documentation and tutorials for the graphics API you are using.
|
|
|
|
|
|
Refer to [Image Loading and Displaying Examples](https://github.com/ocornut/imgui/wiki/Image-Loading-and-Displaying-Examples) on the [Wiki](https://github.com/ocornut/imgui/wiki) to find simplified examples for loading textures with OpenGL, DirectX9 and DirectX11.
|
|
|
|
|
|
C/C++ tip: a void* is pointer-sized storage. You may safely store any pointer or integer into it by casting your value to ImTextureID / 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 ImTextureID / void*.
|
|
|
-Examples:
|
|
|
+Here are some examples:
|
|
|
```cpp
|
|
|
GLuint my_tex = XXX;
|
|
|
void* my_void_ptr;
|
|
|
@@ -423,7 +423,7 @@ This way you'll be able to use your own types everywhere, e.g. passing `MyVector
|
|
|
---
|
|
|
|
|
|
### Q: How can I interact with standard C++ types (such as std::string and std::vector)?
|
|
|
-- Being highly portable (backends/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.
|
|
|
+- Being highly portable (backends/bindings for several languages, frameworks, programming styles, obscure or older platforms/compilers), and aiming for compatibility & performance suitable for every modern real-time game engine, 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.
|
|
|
- To use ImGui::InputText() with a std::string or any resizable string class, see [misc/cpp/imgui_stdlib.h](https://github.com/ocornut/imgui/blob/master/misc/cpp/imgui_stdlib.h).
|
|
|
- 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.
|
|
|
@@ -432,12 +432,12 @@ Prefer using them over the old and awkward `Combo()/ListBox()` api.
|
|
|
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.
|
|
|
+Please bear in mind that using `std::string` on applications with a 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
|
|
|
-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.
|
|
|
+- If you are finding your UI traversal cost to be too large, make sure your string usage is not leading to an 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 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
|
|
|
provide similar or better string helpers.
|
|
|
@@ -473,7 +473,7 @@ ImGui::End();
|
|
|
- Refer to "Demo > Examples > Custom Rendering" in the demo window and read the code of `ShowExampleAppCustomRendering()` in `imgui_demo.cpp` from more examples.
|
|
|
- To generate colors: you can use the macro `IM_COL32(255,255,255,255)` to generate them at compile time, or use `ImGui::GetColorU32(IM_COL32(255,255,255,255))` or `ImGui::GetColorU32(ImVec4(1.0f,1.0f,1.0f,1.0f))` to generate a color that is multiplied by the current value of `style.Alpha`.
|
|
|
- Math operators: if you have setup `IM_VEC2_CLASS_EXTRA` in `imconfig.h` to bind your own math types, you can use your own math types and their natural operators instead of ImVec2. ImVec2 by default doesn't export any math operators in the public API. You may use `#define IMGUI_DEFINE_MATH_OPERATORS` `#include "imgui_internal.h"` to use the internally defined math operators, but instead prefer using your own math library and set it up in `imconfig.h`.
|
|
|
-- You can use `ImGui::GetBackgroundDrawList()` or `ImGui::GetForegroundDrawList()` to access draw lists which will be displayed behind and over every other dear imgui windows (one bg/fg drawlist per viewport). This is very convenient if you need to quickly display something on the screen that is not associated to a dear imgui window.
|
|
|
+- You can use `ImGui::GetBackgroundDrawList()` or `ImGui::GetForegroundDrawList()` to access draw lists which will be displayed behind and over every other Dear ImGui window (one bg/fg drawlist per viewport). This is very convenient if you need to quickly display something on the screen that is not associated with a Dear ImGui window.
|
|
|
- You can also create your own empty window and draw inside it. Call Begin() with the NoBackground | NoDecoration | NoSavedSettings | NoInputs flags (The `ImGuiWindowFlags_NoDecoration` flag itself is a shortcut for NoTitleBar | NoResize | NoScrollbar | NoCollapse). Then you can retrieve the ImDrawList* via `GetWindowDrawList()` and draw to it in any way you like.
|
|
|
- You can create your own ImDrawList instance. You'll need to initialize them with `ImGui::GetDrawListSharedData()`, or create your own instancing `ImDrawListSharedData`, and then call your renderer function with your own ImDrawList or ImDrawData data.
|
|
|
- Looking for fun? The [ImDrawList coding party 2020](https://github.com/ocornut/imgui/issues/3606) thread is full of "don't do this at home" extreme uses of the ImDrawList API.
|
|
|
@@ -496,16 +496,16 @@ Down the line Dear ImGui will provide a variety of standardized reference values
|
|
|
|
|
|
Applications in the `examples/` folder are not DPI aware partly because they are unable to load a custom font from the file-system (may change that in the future).
|
|
|
|
|
|
-The reason DPI is not auto-magically solved in stock examples is that we don't yet have a satisfying solution for the "multi-dpi" problem (using the `docking` branch: when multiple viewport windows are over multiple monitors using different DPI scale). The current way to handle this on the application side is:
|
|
|
+The reason DPI is not auto-magically solved in stock examples is that we don't yet have a satisfying solution for the "multi-dpi" problem (using the `docking` branch: when multiple viewport windows are over multiple monitors using different DPI scales). The current way to handle this on the application side is:
|
|
|
- Create and maintain one font atlas per active DPI scale (e.g. by iterating `platform_io.Monitors[]` before `NewFrame()`).
|
|
|
- Hook `platform_io.OnChangedViewport()` to detect when a `Begin()` call makes a Dear ImGui window change monitor (and therefore DPI).
|
|
|
-- In the hook: swap atlas, swap style with correctly sized one, remap the current font from one atlas to the other (may need to maintain a remapping table of your fonts at varying DPI scale).
|
|
|
+- In the hook: swap atlas, swap style with correctly sized one, and remap the current font from one atlas to the other (you may need to maintain a remapping table of your fonts at varying DPI scales).
|
|
|
|
|
|
-This approach is relatively easy and functional but come with two issues:
|
|
|
+This approach is relatively easy and functional but comes with two issues:
|
|
|
- It's not possibly to reliably size or position a window ahead of `Begin()` without knowing on which monitor it'll land.
|
|
|
- Style override may be lost during the `Begin()` call crossing monitor boundaries. You may need to do some custom scaling mumbo-jumbo if you want your `OnChangedViewport()` handler to preserve style overrides.
|
|
|
|
|
|
-Please note that if you are not using multi-viewports with multi-monitors using different DPI scale, you can ignore all of this and use the simpler technique recommended at the top.
|
|
|
+Please note that if you are not using multi-viewports with multi-monitors using different DPI scales, you can ignore that and use the simpler technique recommended at the top.
|
|
|
|
|
|
### Q: How can I load a different font than the default?
|
|
|
Use the font atlas to load the TTF/OTF file you want:
|
|
|
@@ -536,11 +536,11 @@ io.Fonts->AddFontFromFileTTF("MyFolder/MyFont.ttf", size); // ALSO CORRECT
|
|
|
---
|
|
|
|
|
|
### Q: How can I easily use icons in my application?
|
|
|
-The most convenient and practical way is to merge an icon font such as FontAwesome inside you
|
|
|
+The most convenient and practical way is to merge an icon font such as FontAwesome inside your
|
|
|
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 [docs/FONTS.md](https://github.com/ocornut/imgui/blob/master/docs/FONTS.md) file for more details about icons font loading.)
|
|
|
-With some extra effort, you may use colorful icon by registering custom rectangle space inside the font atlas,
|
|
|
+With some extra effort, you may use colorful icons by registering custom rectangle space inside the font atlas,
|
|
|
and copying your own graphics data into it. See docs/FONTS.md about using the AddCustomRectFontGlyph API.
|
|
|
|
|
|
##### [Return to Index](#index)
|
|
|
@@ -598,17 +598,17 @@ builder.BuildRanges(&ranges); // Build the final result
|
|
|
io.Fonts->AddFontFromFileTTF("myfontfile.ttf", 16.0f, NULL, ranges.Data);
|
|
|
```
|
|
|
|
|
|
-All your strings needs to use UTF-8 encoding. In C++11 you can encode a string literal in UTF-8
|
|
|
+All your strings need to use UTF-8 encoding. In C++11 you can encode a string literal in UTF-8
|
|
|
by using the u8"hello" syntax. Specifying literal in your source code using a local code page
|
|
|
(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.
|
|
|
+Otherwise, you can convert yourself to UTF-8 or load text data from a 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.
|
|
|
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.
|
|
|
+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 can write your HWND to ImGui::GetMainViewport()->PlatformHandleRaw
|
|
|
-in order for the default the default implementation of io.SetPlatformImeDataFn() to set your Microsoft IME position correctly.
|
|
|
+for the default implementation of io.SetPlatformImeDataFn() to set your Microsoft IME position correctly.
|
|
|
|
|
|
##### [Return to Index](#index)
|
|
|
|
|
|
@@ -631,9 +631,9 @@ You may take a look at:
|
|
|
|
|
|
### Q: Can you create elaborate/serious tools with Dear ImGui?
|
|
|
|
|
|
-Yes. People have written game editors, data browsers, debuggers, profilers and all sort of non-trivial tools with the library. In my experience the simplicity of the API is very empowering. Your UI runs close to your live data. Make the tools always-on and everybody in the team will be inclined to create new tools (as opposed to more "offline" UI toolkits where only a fraction of your team effectively creates tools). The list of sponsors below is also an indicator that serious game teams have been using the library.
|
|
|
+Yes. People have written game editors, data browsers, debuggers, profilers, and all sorts of non-trivial tools with the library. In my experience, the simplicity of the API is very empowering. Your UI runs close to your live data. Make the tools always-on and everybody in the team will be inclined to create new tools (as opposed to more "offline" UI toolkits where only a fraction of your team effectively creates tools). The list of sponsors below is also an indicator that serious game teams have been using the library.
|
|
|
|
|
|
-Dear ImGui is very programmer centric and the immediate-mode GUI paradigm might require you to readjust some habits before you can realize its full potential. Dear ImGui is about making things that are simple, efficient and powerful.
|
|
|
+Dear ImGui is very programmer centric and the immediate-mode GUI paradigm might require you to readjust some habits before you can realize its full potential. Dear ImGui is about making things that are simple, efficient, and powerful.
|
|
|
|
|
|
Dear ImGui is built to be efficient and scalable toward the needs for AAA-quality applications running all day. The IMGUI paradigm offers different opportunities for optimization that the more typical RMGUI paradigm.
|
|
|
|
|
|
@@ -643,9 +643,9 @@ Dear ImGui is built to be efficient and scalable toward the needs for AAA-qualit
|
|
|
|
|
|
### Q: Can you reskin the look of Dear ImGui?
|
|
|
|
|
|
-Somehow. You can alter the look of the interface to some degree: changing colors, sizes, padding, rounding, fonts. However, as Dear ImGui is designed and optimized to create debug tools, the amount of skinning you can apply is limited. There is only so much you can stray away from the default look and feel of the interface. Dear ImGui is NOT designed to create user interface for games, although with ingenious use of the low-level API you can do it.
|
|
|
+Somehow. You can alter the look of the interface to some degree: changing colors, sizes, padding, rounding, and fonts. However, as Dear ImGui is designed and optimized to create debug tools, the amount of skinning you can apply is limited. There is only so much you can stray away from the default look and feel of the interface. Dear ImGui is NOT designed to create a user interface for games, although with ingenious use of the low-level API you can do it.
|
|
|
|
|
|
-A reasonably skinned application may look like (screenshot from [#2529](https://github.com/ocornut/imgui/issues/2529#issuecomment-524281119))
|
|
|
+A reasonably skinned application may look like (screenshot from [#2529](https://github.com/ocornut/imgui/issues/2529#issuecomment-524281119)):
|
|
|
|
|
|
|
|
|
##### [Return to Index](#index)
|
|
|
@@ -654,7 +654,7 @@ A reasonably skinned application may look like (screenshot from [#2529](https://
|
|
|
|
|
|
### Q: Why using C++ (as opposed to C)?
|
|
|
|
|
|
-Dear ImGui takes advantage of a few C++ languages features for convenience but nothing anywhere Boost insanity/quagmire. Dear ImGui doesn't use any C++ header file. Dear ImGui uses a very small subset of C++11 features. In particular, function overloading and default parameters are used to make the API easier to use and code more terse. Doing so I believe the API is sitting on a sweet spot and giving up on those features would make the API more cumbersome. Other features such as namespace, constructors and templates (in the case of the ImVector<> class) are also relied on as a convenience.
|
|
|
+Dear ImGui takes advantage of a few C++ language features for convenience but nothing anywhere Boost insanity/quagmire. Dear ImGui doesn't use any C++ header file. Dear ImGui uses a very small subset of C++11 features. In particular, function overloading and default parameters are used to make the API easier to use and code terser. Doing so I believe the API is sitting on a sweet spot and giving up on those features would make the API more cumbersome. Other features such as namespace, constructors, and templates (in the case of the ImVector<> class) are also relied on as a convenience.
|
|
|
|
|
|
There is an auto-generated [c-api for Dear ImGui (cimgui)](https://github.com/cimgui/cimgui) by Sonoro1234 and Stephan Dilly. It is designed for creating bindings to other languages. If possible, I would suggest using your target language functionalities to try replicating the function overloading and default parameters used in C++ else the API may be harder to use. Also see [Bindings](https://github.com/ocornut/imgui/wiki/Bindings) for various third-party bindings.
|
|
|
|
|
|
@@ -665,11 +665,11 @@ There is an auto-generated [c-api for Dear ImGui (cimgui)](https://github.com/ci
|
|
|
# Q&A: Community
|
|
|
|
|
|
### Q: How can I help?
|
|
|
-- Businesses: please reach out to `contact AT dearimgui.com` if you work in a place using Dear ImGui! We can discuss ways for your company to fund development via invoiced technical support, maintenance or sponsoring contacts. This is among the most useful thing you can do for Dear ImGui. With increased funding, we can hire more people working on this project.
|
|
|
+- Businesses: please reach out to `contact AT dearimgui.com` if you work in a place using Dear ImGui! We can discuss ways for your company to fund development via invoiced technical support, maintenance, or sponsoring contacts. This is among the most useful thing you can do for Dear ImGui. With increased funding, we can hire more people to work on this project.
|
|
|
- Individuals: you can support continued maintenance and development via PayPal donations. See [README](https://github.com/ocornut/imgui/blob/master/docs/README.md).
|
|
|
-- If you are experienced with Dear ImGui and C++, look at [GitHub Issues](https://github.com/ocornut/imgui/issues), [GitHub Discussions](https://github.com/ocornut/imgui/discussions), the [Wiki](https://github.com/ocornut/imgui/wiki), read [docs/TODO.txt](https://github.com/ocornut/imgui/blob/master/docs/TODO.txt) and see how you want to help and can help!
|
|
|
-- Disclose your usage of Dear ImGui via a dev blog post, a tweet, a screenshot, a mention somewhere etc.
|
|
|
-You may post screenshot or links in the [gallery threads](https://github.com/ocornut/imgui/issues/5243). Visuals are ideal as they inspire other programmers. Disclosing your use of Dear ImGui helps the library grow credibility, and help other teams and programmers with taking decisions.
|
|
|
+- If you are experienced with Dear ImGui and C++, look at [GitHub Issues](https://github.com/ocornut/imgui/issues), [GitHub Discussions](https://github.com/ocornut/imgui/discussions), the [Wiki](https://github.com/ocornut/imgui/wiki), read [docs/TODO.txt](https://github.com/ocornut/imgui/blob/master/docs/TODO.txt), and see how you want to help and can help!
|
|
|
+- Disclose your usage of Dear ImGui via a dev blog post, a tweet, a screenshot, a mention somewhere, etc.
|
|
|
+You may post screenshots or links in the [gallery threads](https://github.com/ocornut/imgui/issues/5243). Visuals are ideal as they inspire other programmers. Disclosing your use of Dear ImGui helps the library grow credibility, and helps other teams and programmers with taking decisions.
|
|
|
- If you have issues or if you need to hack into the library, even if you don't expect any support it is useful that you share your issues or sometimes incomplete PR.
|
|
|
|
|
|
##### [Return to Index](#index)
|
Javier Marín