Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies

Dear ImGui

Build Status Static Analysis Status

(This library is available under a free and permissive license, but needs financial support to sustain its continued improvements. In addition to maintenance and stability there are many desirable features yet to be added. If your company is using Dear ImGui, please consider reaching out.)

Businesses: support continued development and maintenance via invoiced technical support, maintenance, sponsoring contracts:
  E-mail: contact @ dearimgui dot com

Individuals: support continued development and maintenance here.

Also see Sponsors page.

Dear ImGui is a bloat-free graphical user interface library for C++. It outputs optimized vertex buffers that you can render anytime in your 3D-pipeline enabled application. It is fast, portable, renderer agnostic and self-contained (no external dependencies).

Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal, and lacks certain features normally found in more high-level libraries.

Dear ImGui is particularly suited to integration in games engine (for tooling), real-time 3D applications, fullscreen applications, embedded applications, or any applications on consoles platforms where operating system features are non-standard.

Usage - How it works - Releases & Changelogs - Demo - Integration
Upcoming changes - Gallery - Support, FAQ - How to help - Sponsors - Credits - License
Wiki - Languages & frameworks backends/bindings - Software using Dear ImGui - User quotes


The core of Dear ImGui is self-contained within a few platform-agnostic files which you can easily compile in your application/engine. They are all the files in the root folder of the repository (imgui.cpp, imgui.h, imgui_demo.cpp, imgui_draw.cpp etc.).

No specific build process is required. You can add the .cpp files to your existing project.

You will need a backend to integrate Dear ImGui in your app. The backend passes mouse/keyboard/gamepad inputs and variety of settings to Dear ImGui, and is in charge of rendering the resulting vertices.

Backends for a variety of graphics api and rendering platforms are provided in the backends/ folder, along with example applications in the examples/ folder. See the Integration section of this document for details. You may also create your own backend. Anywhere where you can render textured triangles, you can render Dear ImGui.

After Dear ImGui is setup in your application, you can use it from _anywhere_ in your program loop:


ImGui::Text("Hello, world %d", 123);
if (ImGui::Button("Save"))
ImGui::InputText("string", buf, IM_ARRAYSIZE(buf));
ImGui::SliderFloat("float", &f, 0.0f, 1.0f);

sample code output (dark) sample code output (light)
(settings: Dark style (left), Light style (right) / Font: Roboto-Medium, 16px)


// Create a window called "My First Tool", with a menu bar.
ImGui::Begin("My First Tool", &my_tool_active, ImGuiWindowFlags_MenuBar);
if (ImGui::BeginMenuBar())
    if (ImGui::BeginMenu("File"))
        if (ImGui::MenuItem("Open..", "Ctrl+O")) { /* Do stuff */ }
        if (ImGui::MenuItem("Save", "Ctrl+S"))   { /* Do stuff */ }
        if (ImGui::MenuItem("Close", "Ctrl+W"))  { my_tool_active = false; }

// Edit a color (stored as ~4 floats)
ImGui::ColorEdit4("Color", my_color);

// Plot some values
const float my_values[] = { 0.2f, 0.1f, 1.0f, 0.5f, 0.9f, 2.2f };
ImGui::PlotLines("Frame Times", my_values, IM_ARRAYSIZE(my_values));

// Display contents in a scrolling region
ImGui::TextColored(ImVec4(1,1,0,1), "Important Stuff");
for (int n = 0; n < 50; n++)
    ImGui::Text("%04d: Some text", n);

sample code output

Dear ImGui allows you to create elaborate tools as well as very short-lived ones. On the extreme side of short-livedness: using the Edit&Continue (hot code reload) feature of modern compilers you can add a few widgets to tweaks variables while your application is running, and remove the code a minute later! Dear ImGui is not just for tweaking values. You can use it to trace a running algorithm by just emitting text commands. You can use it along with your own reflection data to browse your dataset live. You can use it to expose the internals of a subsystem in your engine, to create a logger, an inspection tool, a profiler, a debugger, an entire game making editor/framework, etc.

How it works

Check out the Wiki's About the IMGUI paradigm section if you want to understand the core principles behind the IMGUI paradigm. An IMGUI tries to minimize superfluous state duplication, state synchronization and state retention from the user's point of view. It is less error prone (less code and less bugs) than traditional retained-mode interfaces, and lends itself to create dynamic user interfaces.

Dear ImGui outputs vertex buffers and command lists that you can easily render in your application. The number of draw calls and state changes required to render them is fairly small. Because Dear ImGui doesn't know or touch graphics state directly, you can call its functions anywhere in your code (e.g. in the middle of a running algorithm, or in the middle of your own rendering process). Refer to the sample applications in the examples/ folder for instructions on how to integrate Dear ImGui with your existing codebase.

A common misunderstanding is to mistake immediate mode gui for immediate mode rendering, which usually implies hammering your driver/GPU with a bunch of inefficient draw calls and state changes as the gui functions are called. This is NOT what Dear ImGui does. Dear ImGui outputs vertex buffers and a small list of draw calls batches. It never touches your GPU directly. The draw call batches are decently optimal and you can render them later, in your app or even remotely.

Releases & Changelogs

See Releases page. Reading the changelogs is a good way to keep up to date with the things Dear ImGui has to offer, and maybe will give you ideas of some features that you've been ignoring until now!


Calling the ImGui::ShowDemoWindow() function will create a demo window showcasing variety of features and examples. The code is always available for reference in imgui_demo.cpp.

screenshot demo

You should be able to build the examples from sources (tested on Windows/Mac/Linux). If you don't, let us know! If you want to have a quick look at some Dear ImGui features, you can download Windows binaries of the demo app here:

The demo applications are not DPI aware so expect some blurriness on a 4K screen. For DPI awareness in your application, you can load/reload your font at different scale, and scale your style with style.ScaleAllSizes() (see FAQ).


On most platforms and when using C++, you should be able to use a combination of the imgui_impl_xxxx backends without modification (e.g. imgui_impl_win32.cpp + imgui_impl_dx11.cpp). If your engine supports multiple platforms, consider using more of the imgui_impl_xxxx files instead of rewriting them: this will be less work for you and you can get Dear ImGui running immediately. You can later decide to rewrite a custom backend using your custom engine functions if you wish so.

Integrating Dear ImGui within your custom engine is a matter of 1) wiring mouse/keyboard/gamepad inputs 2) uploading one texture to your GPU/render engine 3) providing a render function that can bind textures and render textured triangles. The examples/ folder is populated with applications doing just that. If you are an experienced programmer at ease with those concepts, it should take you less than two hours to integrate Dear ImGui in your custom engine. Make sure to spend time reading the FAQ, comments, and some of the examples/ application!

Officially maintained backends/bindings (in repository):

  • Renderers: DirectX9, DirectX10, DirectX11, DirectX12, Metal, OpenGL (legacy), OpenGL3/ES/ES2 (modern), Vulkan, WebGPU.
  • Platforms: GLFW, SDL2, Win32, Glut, OSX.
  • Frameworks: Emscripten, Allegro5, Marmalade.

Third-party backends/bindings wiki page:

  • Languages: C, C# and: Beef, ChaiScript, Crystal, D, Go, Haskell, Haxe/hxcpp, Java, JavaScript, Julia, Kotlin, Lobster, Lua, Odin, Pascal, PureBasic, Python, Ruby, Rust, Swift...
  • Frameworks: AGS/Adventure Game Studio, Amethyst, Blender, bsf, Cinder, Cocos2d-x, Diligent Engine, Flexium, GML/Game Maker Studio2, GLEQ, Godot, GTK3+OpenGL3, Irrlicht Engine, LÖVE+LUA, Magnum, Monogame, NanoRT, nCine, Nim Game Lib, Nintendo 3DS & Switch (homebrew), Ogre, openFrameworks, OSG/OpenSceneGraph, Orx, Photoshop, px_render, Qt/QtDirect3D, SDL_Renderer, SFML, Sokol, Unity, Unreal Engine 4, vtk, VulkanHpp, VulkanSceneGraph, Win32 GDI, WxWidgets.
  • Note that C bindings (cimgui) are auto-generated, you can use its json/lua output to generate bindings for other languages.

Useful widgets and extensions wiki page:

  • Text editors, node editors, timeline editors, plotting, software renderers, remote network access, memory editors, gizmos etc.

Also see Wiki for more links and ideas.

Upcoming Changes

Some of the goals for 2021 are:

  • Work on Docking (see #2109, in public docking branch)
  • Work on Multi-Viewport / Multiple OS windows. (see #1542, in public docking branch looking for feedback)
  • Work on gamepad/keyboard controls. (see #787)
  • Work on automation and testing system, both to test the library and end-user apps. (see #435)
  • Make the examples look better, improve styles, improve font support, make the examples hi-DPI and multi-DPI aware.


For more user-submitted screenshots of projects using Dear ImGui, check out the Gallery Threads!

For a list of third-party widgets and extensions, check out the Useful Widgets wiki page.

Custom engine screenshot game

Custom engine screenshot tool

Tracy Profiler tracy profiler

Support, Frequently Asked Questions (FAQ)

See: Frequently Asked Questions (FAQ) where common questions are answered.

See: Wiki for many links, references, articles.

See: Articles about the IMGUI paradigm to read/learn about the Immediate Mode GUI paradigm.

If you are new to Dear ImGui and have issues with: compiling, linking, adding fonts, wiring inputs, running or displaying Dear ImGui: you can use Discord server.

Otherwise, for any other questions, bug reports, requests, feedback, you may post on Please read and fill the New Issue template carefully.

Private support is available for paying business customers (E-mail: contact @ dearimgui dot com).

Which version should I get?

We occasionally tag Releases but it is generally safe and recommended to sync to master/latest. The library is fairly stable and regressions tend to be fixed fast when reported.

Advanced users may want to use the docking branch with Multi-Viewport and Docking features. This branch is kept in sync with master regularly.

Who uses Dear ImGui?

See the Quotes, Sponsors, Software using dear imgui Wiki pages for an idea of who is using Dear ImGui. Please add your game/software if you can! Also see the Gallery Threads!

How to help

How can I help?

  • You may participate in the Discord server, GitHub forum/issues.
  • You may help with development and submit pull requests! Please understand that by submitting a PR you are also submitting a request for the maintainer to review your code and then take over its maintenance forever. PR should be crafted both in the interest in the end-users and also to ease the maintainer into understanding and accepting it.
  • See Help wanted on the Wiki for some more ideas.
  • Have your company financially support this project (please reach by e-mail)

How can I help financing further development of Dear ImGui?

See Sponsors page.


Ongoing Dear ImGui development is currently financially supported by users and private sponsors:

Platinum-chocolate sponsors

Double-chocolate and Salty caramel sponsors

Please see detailed list of Dear ImGui supporters for past sponsors. From November 2014 to December 2019, ongoing development has also been financially supported by its users on Patreon and through individual donations.

THANK YOU to all past and present supporters for helping to keep this project alive and thriving!

Dear ImGui is using software and services provided free of charge for open source projects:


Developed by Omar Cornut and every direct or indirect contributors to the GitHub. The early version of this library was developed with the support of Media Molecule and first used internally on the game Tearaway (PS Vita).

Recurring contributors (2020): Omar Cornut @ocornut, Rokas Kupstys @rokups, Ben Carter @ShironekoBen. A large portion of work on automation systems, regression tests and other features are currently unpublished.

Omar: "I first discovered the IMGUI paradigm at Q-Games where Atman Binstock had dropped his own simple implementation in the codebase, which I spent quite some time improving and thinking about. It turned out that Atman was exposed to the concept directly by working with Casey. When I moved to Media Molecule I rewrote a new library trying to overcome the flaws and limitations of the first one I've worked with. It became this library and since then I have spent an unreasonable amount of time iterating and improving it."

Embeds ProggyClean.ttf font by Tristan Grimmer (MIT license).

Embeds stb_textedit.h, stb_truetype.h, stb_rect_pack.h by Sean Barrett (public domain).

Inspiration, feedback, and testing for early versions: Casey Muratori, Atman Binstock, Mikko Mononen, Emmanuel Briney, Stefan Kamoda, Anton Mikhailov, Matt Willis. Also thank you to everyone posting feedback, questions and patches on GitHub.


Dear ImGui is licensed under the MIT License, see LICENSE.txt for more information.

  • Color picker

    Color picker

    (ADMIN EDIT): COLOR PICKING TOOLS ARE NOW INCLUDED IN IMGUI. From version 1.51 (Aug 2017), ColorEdit3/ColorEdit4 wll allow you to open a picker by clicking on the colored square. Also added right-mouse click to open option. And you can call ColorPicker4 functions to directly embed a picker with custom options in your app. Read the release note and check the demo code.

    I've implemented advanced color picker, maybe somebody find this useful:


        void ImDrawList::AddTriangleFilledMultiColor(const ImVec2& a, const ImVec2& b, const ImVec2& c, ImU32 col_a, ImU32 col_b, ImU32 col_c)
            if (((col_a | col_b | col_c) >> 24) == 0)
            const ImVec2 uv = GImGui->FontTexUvWhitePixel;
            PrimReserve(3, 3);
            PrimWriteIdx((ImDrawIdx)(_VtxCurrentIdx)); PrimWriteIdx((ImDrawIdx)(_VtxCurrentIdx + 1)); PrimWriteIdx((ImDrawIdx)(_VtxCurrentIdx + 2));
            PrimWriteVtx(a, uv, col_a);
            PrimWriteVtx(b, uv, col_b);
            PrimWriteVtx(c, uv, col_c);
        bool ColorPicker(const char* label, ImColor* color)
            static const float HUE_PICKER_WIDTH = 20.0f;
            static const float CROSSHAIR_SIZE = 7.0f;
            static const ImVec2 SV_PICKER_SIZE = ImVec2(200, 200);
            bool value_changed = false;
            ImDrawList* draw_list = ImGui::GetWindowDrawList();
            ImVec2 picker_pos = ImGui::GetCursorScreenPos();
            ImColor colors[] = {ImColor(255, 0, 0),
                ImColor(255, 255, 0),
                ImColor(0, 255, 0),
                ImColor(0, 255, 255),
                ImColor(0, 0, 255),
                ImColor(255, 0, 255),
                ImColor(255, 0, 0)};
            for (int i = 0; i < 6; ++i)
                    ImVec2(picker_pos.x + SV_PICKER_SIZE.x + 10, picker_pos.y + i * (SV_PICKER_SIZE.y / 6)),
                    ImVec2(picker_pos.x + SV_PICKER_SIZE.x + 10 + HUE_PICKER_WIDTH,
                        picker_pos.y + (i + 1) * (SV_PICKER_SIZE.y / 6)),
                    colors[i + 1],
                    colors[i + 1]);
            float hue, saturation, value;
                color->Value.x, color->Value.y, color->Value.z, hue, saturation, value);
            auto hue_color = ImColor::HSV(hue, 1, 1);
                ImVec2(picker_pos.x + SV_PICKER_SIZE.x + 8, picker_pos.y + hue * SV_PICKER_SIZE.y),
                ImVec2(picker_pos.x + SV_PICKER_SIZE.x + 12 + HUE_PICKER_WIDTH,
                    picker_pos.y + hue * SV_PICKER_SIZE.y),
                ImColor(255, 255, 255));
                ImVec2(picker_pos.x + SV_PICKER_SIZE.x, picker_pos.y + SV_PICKER_SIZE.y),
                ImVec2(picker_pos.x, picker_pos.y + SV_PICKER_SIZE.y),
                ImColor(0, 0, 0),
                ImColor(255, 255, 255));
            float x = saturation * value;
            ImVec2 p(picker_pos.x + x * SV_PICKER_SIZE.x, picker_pos.y + value * SV_PICKER_SIZE.y);
            draw_list->AddLine(ImVec2(p.x - CROSSHAIR_SIZE, p.y), ImVec2(p.x - 2, p.y), ImColor(255, 255, 255));
            draw_list->AddLine(ImVec2(p.x + CROSSHAIR_SIZE, p.y), ImVec2(p.x + 2, p.y), ImColor(255, 255, 255));
            draw_list->AddLine(ImVec2(p.x, p.y + CROSSHAIR_SIZE), ImVec2(p.x, p.y + 2), ImColor(255, 255, 255));
            draw_list->AddLine(ImVec2(p.x, p.y - CROSSHAIR_SIZE), ImVec2(p.x, p.y - 2), ImColor(255, 255, 255));
            ImGui::InvisibleButton("saturation_value_selector", SV_PICKER_SIZE);
            if (ImGui::IsItemHovered())
                ImVec2 mouse_pos_in_canvas = ImVec2(
                    ImGui::GetIO().MousePos.x - picker_pos.x, ImGui::GetIO().MousePos.y - picker_pos.y);
                if (ImGui::GetIO().MouseDown[0])
                    mouse_pos_in_canvas.x =
                        ImMin(mouse_pos_in_canvas.x, mouse_pos_in_canvas.y);
                    value = mouse_pos_in_canvas.y / SV_PICKER_SIZE.y;
                    saturation = value == 0 ? 0 : (mouse_pos_in_canvas.x / SV_PICKER_SIZE.x) / value;
                    value_changed = true;
            ImGui::SetCursorScreenPos(ImVec2(picker_pos.x + SV_PICKER_SIZE.x + 10, picker_pos.y));
            ImGui::InvisibleButton("hue_selector", ImVec2(HUE_PICKER_WIDTH, SV_PICKER_SIZE.y));
            if (ImGui::IsItemHovered())
                if (ImGui::GetIO().MouseDown[0])
                    hue = ((ImGui::GetIO().MousePos.y - picker_pos.y) / SV_PICKER_SIZE.y);
                    value_changed = true;
            *color = ImColor::HSV(hue, saturation, value);
            return value_changed | ImGui::ColorEdit3(label, &color->Value.x);
  • Docking / Dock Panel Layout

    Docking / Dock Panel Layout

    [ADMIN] EDIT: There is now an official docking branch. See #2109 for details.

    I'd like to see if somebody is interested in a Mini Dock Panel Layout: I implemented a very basic one a few months ago (I still have to port my code to the new version of ImGui).

    This is an old screenshot of what it looked: imgui mini dockpanel test

    Basically it just supports one docked window per side, with a "hover" window (when the mouse hovers the buttons that are not active), with no animation and no drag and drop at all, and no re-arrangeable buttons and windows.

    This is very limited compared to a "full featured" dock panel implementation but it's better than nothing and is OK for my needs (although it's currently just a proof of the concept not tested for real usage).

  • Auto Generated C Bindings

    Auto Generated C Bindings

    Hi, I was wondering your perspective on what would be the ideal c bindings. Something that resembles cimgui, the main issue with cimgui is that it is not able to compile with a pure C compiler, making a DynamicLibrary a most to be able to link at runtime. I just want to know your thoughts and find a way to help with this task.

  • ImGui Windows not showing

    ImGui Windows not showing

    Sorry if this a stupid question, but, how does DockSpace work? I have no idea what a ImGuiID is but I'd just like to make a opengl window a dockspace, Thanks!

  • New Tables API (alpha available for testing)

    New Tables API (alpha available for testing)


    I have pushed an experimental tables branch: Providing a long awaited full-featured replacement to the old "Columns" API (#125).

    I have been working on this for an embarassingly looong time.. What seemingly started as "let's refactor columns" became a multi-month thing with many rewrites/iterations. A large portion of this work been sponsored by Blizzard Entertainment. Several internal changes pushed to 1.71-1.74 were in preparation for this as I often try to have changes trickle down to master whenever possible to reduce complication of branching.

    Please read <3 (this post will be occasionally updated)

    Basic Usage:

    TODO List:

    WIP API breaking changes Sept 2020

    Question? Feedback? Bug report? Feature request? Please create a NEW ISSUE!


    • Dec 2019: made branch public.
    • (EDIT) Oct 2020: planned for merging in 1.80 (next release). feedback welcome!
    • It is fairly functional but I am sure you will find issues. It can be used in many scenarios down to simple N-way columning without borders.
    • Next post include a TODO list.
    • I'm hoping that this ideally can be in master in 2-3 months (edit: HAHAHA). But that will depends on feedback, how many issues we find and how many we can fix etc.
    • The Columns() api will be marked "obsolete" when this gets merged, it will probably be kept as-is for a few years but we will encourage everyone to use Tables (not harder to use!).

    Looking for early testers

    • Looking for early adopters to experiment with this and provide feedback. When I am confident enough that the API can become stable we will merge the feature in Master.
    • Please create New Issues instead of answering in this thread.
    • Some of the API will evolve in the upcoming few months. I would advise using this if you are confortable with following on some API changes (they will be posted here).
    • There are lots of known issues (see post below), but your feedback will help me prioritize them and will probably expand the feature set.
    • When you provide feedback please make it detailed, specify which flags you are using, provide shots, repros, etc. As with many other features, lots of things here are surprisingly more subtle and complex than you'd expect, magic under the hood, and many flags have subtle side-effects, etc. please don't make me guess.
    • If you use this branch I would appreciate if you tried to update regularly or semi-regularly so you can provide feedback and help detect regression.

    Git Flow

    • Branch is tables (
    • The branch will merge into docking/viewports without conflict.
    • The branch is based off master. I am expecting to merge this into master before the docking/viewports features.
    • I will rebase/push-force this branch over master in the course of the next few weeks/months.


    • Scrolling on both axises
    • Possibility to freeze/lock rows or columns so they are always visible with scrolling
    • Headers (which can be customized)
    • Cells can contains anything (you can output multiple widgets, etc.) it's a regular canvas for your contents.
    • Stretching (weighted) or static size columns
    • Columns can be reordered
    • Columns can be hidden
    • Columns can be resized
    • Columns can be sorted (actual data sorting is done by user, api gives you the sort specs/infos you need)
    • Various bordering and padding options
    • Per-Columns flags (e.g. honor indent)
    • Borders and odd/even row background colors options
    • Clipper can be used on vertical axis (per column clipping possible as visibility is provided to user)
    • Saved settings (storage is font/dpi change friendly)
    • Context menu (should be customizable later)

    Some screenshots






  • Menus API work

    Menus API work

    Discussion for an upcoming menu api (still being designed). If you have ideas or references of menu being implemented in imgui systems please post here!

    Some thoughts:

    • Menu items typically contains a label, an optional checkmark, an optional local shortcut, an optional global shorcut, an optional link to a submenu, an optional Icon. Menus will be created and developed in a way analogous to the existing patterns in ImGui. API needs to be terse for the common case.
    • We should be able to use most types of widgets within a menu. Menu specialize for "menu items" but other widgets should be usable. We should be able to pack sliders or images into a menu.
    • We need "menu bars" as the common way to layout menus. Menu bars can be inside individual windows but we need to provide an easy way to have a "top of the screen" menu bar. Also provide easy way to hide menus.
    • We want popups menu. They are likely spawned from an event (e.g. clicking a button). This is posing a small problem: if a menu appears upon reacting to an event, we need to design a coding pattern that will allow the menu to stay on after the event has happened.
    • Support local keyboard shortcuts, We can use Windows syntax of using & (e.g. "&Save") for convenience.
    • Support general "global" shortcuts (e.g. "CTRL+S"). As a design goal of ImGui we want to avoid code and state duplication, so I'd like the ImGui system to handle shortcuts for the user. It will be optional but likely available by default. So the program can have a single entry point for "Save" whether it is activated via clicking in the menu or via pressing the shortcut. The way it would work is that when a global shortcut scheme is activated, the menu functions always notify the user code to develop its content so ImGui can parse and execute the shortcuts as they are declared, but the actual menu is not layed out nor rendered. The shortcut scheme can be disabled on a per-menu/window/global basis. In particular, procedurally generated menus that may have infinite depth will need to be able to disable the global shortcut scheme. In its "closed" state, the system has to be as lightweight as if the user were testing a bunch of shortcuts themselves. The scope of shortcuts can be dependent on factor such as if the parent window is focused so they aren't always "global". The user should also be able to display the label for a shortcut in the menu without letting ImGui handle the shortcut itself.
    • Menu navigation may requires ImGui to support more thorough keyboard navigation (currently we only handle TAB and Shift+TAB for navigation).
    • Menus needs to scroll if they can't fit in screen.
    • Menus needs to position themselves nicely when opened from a parent menu.
    • Search in menus like OSX does?
  • ImGui needs a better name!

    ImGui needs a better name!

    ImGui is a generic term which makes googling for this library uneasy. While we can keep the git and source code "imgui" (if desired), it would be beneficial to include a keyword or two that would uniquely identify the library. Any suggestions?

  • Columns API work

    Columns API work

    This thread to discuss the existing Columns() system. They are still a bit confusing at times and not as well supported as other part of the API. Some discussions there:

  • Raspberry Pi support

    Raspberry Pi support

    This PR adds support for compiling SDL + opengl3 example on Raspberry Pi (RPi). RPi uses EGL instead of full openGL. Makefile was adjusted to pull in RPi specific headers and libraries found in /opt/vc through pkg-config. Since it seems to be no way of automatically detecting compilation for RPi target, it is essentially ARM CPU, a new define called RPI was introduced in the Makefile and passed to the compiler. The use of opengl ES 2.0 is also forced through -DIMGUI_IMPL_OPENGL_ES2 specified in the Makefile.

    The code was compiled natively and the result was successfully tested on the target.

  • Gamepad / Keyboard navigation and interactions!

    Gamepad / Keyboard navigation and interactions!

    EDIT: The navigation branch has been merged to master. See #1599. Further improvements/fixes will be pushed to mainline.

    Opening a new thread because the old one ( ) became overwhelmingly long and unwelcoming. This is a trimmed post with info that are still relevant.

    TL;DR; there is a new branch that add supports for gamepad/joystick navigation. The same system can be used for keyboard navigation to some degree, but the initial focus is on gamepad. Typically you can use that to access your tools on PS4/XBone/Wii-U/etc without a synergy/mouse/keyboard setup. Best if you can still have even a virtual mouse around (e.g. on DualShock4 touch pad).

    EDIT March 2018 Link to PNG + PSD depicting the controls for DualShock 4 and Joy-Con

    imgui controls v6 - ps4 imgui controls v6 - switch

    EDIT: Now in master! Branch: (checkout branch navigation or download from web and overwrite your imgui_xxx files)


    I'm calling it beta because:

    • This feature required changing lots of code. The branch probably has bugs.
    • It is rough and work in progress. The more I add and fix things the more I see new things to do. My initial schedule projection was a joke. Long tail feature.
    • But it is pretty useful already!
    • I would ideally like to merge this in master but I can only do so with more testing and feedback. Even if you don't need gamepad navigation, using this branch without wiring the inputs would be useful testing.

    What I would like from users:

    • See how it fits in your real-world app and what we need to fix/add.
    • Any bug report, questions, features request, welcome. Please be critical!

    The development of this feature has been partly sponsored by Insomniac Games (thank you!).

    My current mapping for DualShock4

    D-Pad up/down/left/right: navigate, tweak values Cross button: press button, hold to tweak/activate widget, enter child, etc. Circle button: close popup, exit child, clear selection, etc. Square button(TAP): access menu, collapsing, window options, etc. Square button(HOLD)+Dpad: resize window Square button(HOLD)+Analog: move window Square button(HOLD)+L/R trigger changes window focus, ALT-TAB style Triangle button: text input (requires user back-end reading back io.WantTextInput, possibly display an OS keyboard display). L/R Trigger: slow down/speed up tweaking values Analog stick: manual scroll.

    Quick instructions

    // Fill ImGuiIO.NavInputs[] float array every frame to feed gamepad/keyboard navigation inputs.
    // 0.0f= not held. 1.0f= fully held. Pass intermediate 0.0f..1.0f values for analog triggers/sticks.
    // ImGui uses a simple >0.0f for activation testing, and won't attempt to test for a dead-zone.
    // Your code passing analog gamepad values is likely to want to transform your raw inputs, using a dead-zone and maybe a power curve.
    enum ImGuiNavInput_
        ImGuiNavInput_PadActivate,      // press button, tweak value                    // e.g. Circle button
        ImGuiNavInput_PadCancel,        // close menu/popup/child, lose selection       // e.g. Cross button
        ImGuiNavInput_PadInput,         // text input                                   // e.g. Triangle button
        ImGuiNavInput_PadMenu,          // access menu, focus, move, resize             // e.g. Square button
        ImGuiNavInput_PadUp,            // move up, resize window (with PadMenu held)   // e.g. D-pad up/down/left/right, analog
        ImGuiNavInput_PadDown,          // move down
        ImGuiNavInput_PadLeft,          // move left
        ImGuiNavInput_PadRight,         // move right
        ImGuiNavInput_PadScrollUp,      // scroll up, move window (with PadMenu held)   // e.g. right stick up/down/left/right, analog
        ImGuiNavInput_PadScrollDown,    // "
        ImGuiNavInput_PadScrollLeft,    //
        ImGuiNavInput_PadScrollRight,   //
        ImGuiNavInput_PadFocusPrev,     // next window (with PadMenu held)              // e.g. L-trigger
        ImGuiNavInput_PadFocusNext,     // prev window (with PadMenu held)              // e.g. R-trigger
        ImGuiNavInput_PadTweakSlow,     // slower tweaks                                // e.g. L-trigger, analog
        ImGuiNavInput_PadTweakFast,     // faster tweaks                                // e.g. R-trigger, analog

    Current blurb in imgui.cpp (I know it is cropped by github but please read it)

     - Gamepad/keyboard navigation support is available, currently in Beta with some issues. Your feedback and bug reports are welcome.
     - See discussion thread and ask questions there.
     - The current primary focus is to support game controllers.
     - Consider emulating a mouse cursor with DualShock4 touch pad or a spare analog stick as a mouse-emulation fallback.
     - Consider using Synergy host (on your computer) + uSynergy.c (in your console/tablet/phone app) to use PC mouse/keyboard.
     - Your inputs are passed to imgui by filling the io.NavInputs[] array. See 'enum ImGuiNavInput_' in imgui.h for a description of available inputs.
     - For gamepad use, the easiest approach is to go all-or-nothing, with a buttons combo that toggle your inputs between imgui and your game/application.
       Sharing inputs in a more advanced or granular way between imgui and your game/application may be tricky and requires further work on imgui.
       For more advanced uses, you may want to use:
         - io.NavUsable: true when a window is focused and it doesn't have the ImGuiWindowFlags_NoNavInputs flag set.
         - io.NavActive: true when the navigation cursor is visible (and usually goes false when mouse is used).
         - query focus information with IsWindowFocused(), IsAnyWindowFocused(), IsAnyItemFocused() functions.
       The reality is more complex than what those flags can express. Please discuss your issues and usage scenario in the thread above. 
       As we head toward more keyboard-oriented development this aspect will need to be improved.
     - It is recommended that you enable the 'io.NavMovesMouse' option. Enabling it instructs ImGui that it can move your move cursor to track navigated items and ease readability.
       When enabled and using directional navigation (with d-pad or arrow keys), the NewFrame() functions may alter 'io.MousePos' and set 'io.WantMoveMouse' to notify you that it did so.
       When that happens your back-end NEEDS to move the OS or underlying mouse cursor on the next frame. The examples binding in examples/ do that.
       (Important: It you set 'io.NavMovesMouse' to true but don't honor 'io.WantMoveMouse' properly, imgui will misbehave as it will think your mouse is moving back and forth.)
         // Application init
         io.NavMovesMouse = true;
         // Application main loop
         if (io.WantMoveMouse)
            MyFuncToSetMousePosition(io.MousePos.x, io.MousePos.y);
       In a setup when you may not have easy control over the mouse cursor (e.g. uSynergy.c doesn't expose moving remote mouse cursor),
       you might want to set a boolean to ignore your other external mouse positions until they move again
    1. THE INITIAL FOCUS IS ON USING A GAME CONTROLLER! The inputs are explicitly named using the word "pad" because the current scheme is optimized for game controllers. You can however trivially map keyboard keys on those inputs and it'll work if you use mouse+keyboard combo. Later on I will focus on keyboard and add especially named enums for keyboard (user expectation for keyboard controls are much higher/harsher than with gamepad).

    2. Depending on your application using gamepad/keyboard might requires more fine-tuned controls of how inputs are dispatched and shared between your app/game and different parts of your imgui interfaces. We may need better options/tooling for that.

    3. It is very probably missing or failing at something that will appear obvious to you. I've nailed many issues and big technical problems but barely started scrapping the surface of all possible usage scenarios. Please report!

    4. The actual scoring function for navigating the graph hasn't been given a lot of love yet and is failing to behave as expected in various cases. Failure usually mean that you press a direction and don't end up exactly where you intended. Will keep improving it. Please report issues with screenshots!

    5. Addition to the public API are rather minimal. New functions IsItemFocused(), IsAnyItemFocused(), SetItemDefaultFocus(), GetKeyPressedAmount(). I agressively made IsItemHovered() be aware of current navigation focus to maximize existing code just naturally working with Nav (typically tooltip pattern). New window flags ImGuiWindowFlags_NoNavFocus ImGuiWindowFlags_NoNavInputs. New colors ImGuiCol_NavHighlight (make it same or close to ImGuiCol_HeaderActive) ImGuiCol_NavWindowingHighlight (white and very transparent), a bunch of keys (read instructions), 1 IO setting NavMovesMouse, 3 IO outputs WantMoveMouse NavUsable NavActive.

    6. The option io.NavMovesMouse is currently off by default. I recommend enabling it. When enabled. the mouse cursor can be moved by ImGui::NewFrame() when directional navigation is used. It does so by overwriting io.MousePos and set io.WantMoveMouse=true. It is up to your backend when that flag is set to apply the new mouse position in your OS. If you enable the option but don't honor those requests, ImGui will be very confused. (this is why I can't have it on by default).

    7. If you are running this on VR, some suggestions: if you want to display ImGui as a static overlay (not affected by head rotation) you may want to reduce DisplaySize and avoid rendering over your entire framebuffer. You can also increase the style.DisplaySafeAreaPadding value. Popups should stay within this rectangle while you can still partly move regular window outside. It might be just better to display it within the 3D world but I haven't tried.

    Following in the next message will be my test code for GLFW binding to map a DualShock 4.

    TODO list

    • [x] A. Sort-out/finalize all the input bindings correctly.
    • [x] B. Menus: Navigating menus is still awkward in multiple ways.
    • [x] B. Investigate crossing over the boundaries of child windows, in particular those without scroll. Introduce a window flag to flatten child in term of navigation.
    • [ ] C. Menubars inside modals windows are acting weird (broken in master as well)
    • [ ] A. Problem various problem with graph navigation/scoring functions, currently biased toward vertical layouts.
    • [ ] C. ~~Using scrolling should activate scrollbar in a way the user can tell programmatically (e.g. Log window).~~
    • [x] C. NavHighlight clipping issue within child window.
    • [ ] C. Merge all the old FocusIdx tabbing stuff into the new system.
    • [ ] B. Resizing window will currently fail with certain types of resizing constraints/callback applied
    • [ ] C. Popup: introduce a default validation button e.g. SetItemDefaultValidation() activable from anywhere in the window with Enter. Currently can use imgui_internal.h declared ImGui::PushItemFlag(ImGuiItemFlags_SelectableDontClosePopup, true); / ImGui::PopItemFlag()
    • [X] C. TreeNode: NavLeft to close, NavRight on closed node to open. How would it behave with buttons/items after a closed treenode, and/or multiple columns?
    • [x] B. Can't reliably use Left/Right within menus with regular widgets. Need to figure out a way to only use the Left/Right nav requests for menu open/closure as fallback to a failed moving request.
    • [x] C. Drag/Slider: experiment with keeping item active when activated, using cancel to stop editing.
    • [ ] B. ~~Popup: add options to disable auto-closing popups when using a MenuItem/Selectable (#126)~~ (not part of Nav)
    • [ ] C. Lost of currently focused widget when using buttons that changes labels on click (obvious, but only made apparent with directional navigation- can we automagically work around it?)
    • [x] B. Bug with keeping visibility of navigated them within horizontal scrollbar. Stuck nav (visible in Horizontal Scrolling demo corner. Still there?).
  • Automation / Testing / Visual documentation framework

    Automation / Testing / Visual documentation framework

    (EDIT 2019: Even though this is an active topic (in 2019) note that this thread started a looong time ago and the early messages are not representive of where we are going now. When the new testing framework is a mature enough to be shared I'll close this topic and open a new one.)

    Looking for someone who would be interested in working on that, probably under my guidance.

    Mentioned it in #259

    Add a framework for generating screenshots/animations for given pieces of code. This is probably going to be done along with the "testing" framework. I would like the ImGui documentation to be a very visual, well organized listing with C++ code on one side, screenshot (or animated GIF) on the other side and tags + commentary. I think this will easily convey a lot of ideas and tips about ways to use ImGui. Update: I've created some helper to help me take manual screenshots and its been very helpful in the past few days. This will probably evolve into such framework.

    The idea would be have a separate test application, could be or not on the same repo, that would A/ generate screenshots/gif + code markup output for the wiki and B/ defacto run tests.

    So we could describe those documentation elements in the code, the framework would execute the test, simulate inputs to interact, take screenshots or gif, crop them as desired, parse its own .cpp file to retrieve the code (which itself could have marking in comments to hide some lines) and generate the help section that would demonstrate ways to use ImGui by showing the code and the screenshot. We would have hundreds of short examples, grouped, chaptered, tagged, indexed.

    I was originally primarily interested in the value of documentation but I think the overlap with testing will be enormous and natural. Just the act of generating the documentation from runtime will be an act of testing. The testing wouldn't be unit tests at ultra fine granularity but rather functional tests (at least this is what I think they are called in the real world?): say, move mouse to corner, click and drag. We can compare screenshot, regression easily caught. Tests would be merely the unpublished part of the documentation system. Any tricky area of the code or fixed bug can be subject to a test, etc.

    It's not really a trivial task to set all that up and I think it'd be highly valuable to the project. Realistically I don't think I'd be able to tackle by myself this year, so looking around if someone is interested to contribute :)

    The person would be expected to be proficient in writing terse, optimal C++ and willing to adopt the general programming style of ImGui.


  • Dock invisible window to keep user settings for disappearing windows

    Dock invisible window to keep user settings for disappearing windows

    Dear ImGui 1.89.2 WIP (18916)
    sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
    define: __cplusplus=201703
    define: __linux__
    define: __GNUC__=12
    define: IMGUI_HAS_DOCK
    io.BackendPlatformName: imgui_impl_sdl
    io.BackendRendererName: testimgui
    io.ConfigFlags: 0x0000C041
    io.ConfigMemoryCompactTimer = 60.0
    io.BackendFlags: 0x00001C0E
    io.Fonts: 3 fonts, Flags: 0x00000000, TexSize: 2048,4096
    io.DisplaySize: 2560.00,1440.00
    io.DisplayFramebufferScale: 1.00,1.00
    style.WindowPadding: 4.00,4.00
    style.WindowBorderSize: 1.00
    style.FramePadding: 6.00,4.00
    style.FrameRounding: 3.00
    style.FrameBorderSize: 2.00
    style.ItemSpacing: 6.00,2.00
    style.ItemInnerSpacing: 4.00,4.00

    Version/Branch of Dear ImGui:

    Version: 1.89.2 WIP (18916) Branch: docking - 693967637266ff48fd247821acd0c6cdf66eda6d


    Back-ends: imgui_impl_sdl.cpp Operating System: Linux

    My Issue/Question:

    I'm writing an editor with multiple modes for the main viewport. One mode has a few windows that aren't visible in other modes. These windows are docked by

    	_dockIdMain = ImGui::GetID("DockSpace");
    	const bool existingLayout = ImGui::DockBuilderGetNode(_dockIdMain);
    	if (!existingLayout && viewport->WorkSize.x > 0.0f) {
    		ImGui::DockBuilderAddNode(_dockIdMain, ImGuiDockNodeFlags_DockSpace);
    		ImGui::DockBuilderSetNodeSize(_dockIdMain, viewport->WorkSize);
    		ImGuiID dockIdLeft = ImGui::DockBuilderSplitNode(_dockIdMain, ImGuiDir_Left, 0.13f, nullptr, &_dockIdMain);
    		ImGuiID dockIdRight = ImGui::DockBuilderSplitNode(_dockIdMain, ImGuiDir_Right, 0.20f, nullptr, &_dockIdMain);
    		ImGuiID dockIdLeftDown = ImGui::DockBuilderSplitNode(dockIdLeft, ImGuiDir_Down, 0.35f, nullptr, &dockIdLeft);
    		ImGuiID dockIdRightDown = ImGui::DockBuilderSplitNode(dockIdRight, ImGuiDir_Down, 0.50f, nullptr, &dockIdRight);
    		ImGuiID dockIdMainDown = ImGui::DockBuilderSplitNode(_dockIdMain, ImGuiDir_Down, 0.20f, nullptr, &_dockIdMain);
    		ImGui::DockBuilderDockWindow(TITLE_SCRIPT_EDITOR, dockIdMainDown);
    		ImGui::DockBuilderDockWindow(TITLE_ANIMATION_TIMELINE, dockIdMainDown);

    It's about the windows with the ids TITLE_SCRIPT_EDITOR and TITLE_ANIMATION_TIMELINE.

    to preserve the user settings, i do check if the dock node already exists. Thus i don't have the dockIdMainDown in a second run of the application.

    I've tried various ways with ImGui::SetNextWindowDockID(dockId, ImGuiCond_Appearing); and somehow get to the correct dock id. But all of this is a hack and didn't work properly in all situations.

    My question is this: Is it possible to dock an invisible window somehow? Such that I can keep the user settings in the ini files persisted but don't see the empty windows? If the user closes the application with some of the windows being invisible (no ImGui::Begin()) then the settings are lost, too.

    This is rendering the window title - but nothing inside the window - but there is no window flag (afaik) that registers but doesn't render a window.

           if (ImGui::Begin(TITLE_SCRIPT_EDITOR)) {
                   if (editMode != EditMode::Scene) {
                           return false;


    Animation view visible Bildschirmfoto vom 2023-01-02 19-49-32

    Changing the editor mode will hide the animation window (not executing the code path at all Bildschirmfoto vom 2023-01-02 19-49-28

    Always rendering the windows - even if they should be invisible (due to the editor mode) Bildschirmfoto vom 2023-01-02 20-04-49

  • Why a

    Why a "Debug" dialog popup when closing the window ?

    Version/Branch of Dear ImGui:

    Version: 1.88 Branch: docking


    Back-ends: imgui_impl_SDL2.cpp + imgui_impl_OpenGL3.cpp Compiler: vs2019 msvc Operating System: windows 10

    My Issue/Question:

    Hello, I would like to know why does imgui popup an empty dialog when I closed a window which using the docking feature ? How can I solve it ? Thanks.


    Before close window: image After close window: image Codes relative in imgui.cpp.NewFrame() image

  • Rendering issues with UTF-8 text that has been decomposed into a canonical form

    Rendering issues with UTF-8 text that has been decomposed into a canonical form


    I've been having some issues getting UTF-8 strings from filenames that have been decomposed by the operating system( to display correctly in ImGui.


    Notice the top item has "?" marks after accented letters and the Korean letters are decomposed into their composite radicals. Compared to the bottom string which is the same except in non-decomposed UTF-8.

    The attached txt file shows the same UTF-8 string encoded in both of these ways, however only one of them will render correctly in ImGui.


    I believe this might be caused by ImGui not compounding these multi-codepoint characters into a single character and instead tries to render each codepoint separately. Is there anyway to resolve this?



  • Can't enter characters with Alt-Gr modifier on Ubuntu

    Can't enter characters with Alt-Gr modifier on Ubuntu

    Version/Branch of Dear ImGui:

    Version: 1.89.2 (18916) Branch: docking


    Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp Compiler: g++ Operating System: Ubuntu 22.04

    My Issue/Question:

    When entering characters on a keyboard with German-Layout (ISO-Layout, DE-de) that require the use of the Alt-Gr-Key, those get recognized by ImGui, but don't get entered/displayed in InputText fields. Example characters are @ or }. It can be checked, that the right characters are recognized under Inputs/Chars queue in the demo window. When entering those characters, it sometimes tries to do window navigation. Rendering of those characters works perfectly in regular text fields. This issue only exists on Ubuntu, on Windows 10 (same backend with MinGW64 g++ and same code) I'm able to enter those characters.

    Further testing I've done:

    • I was able to reproduce this input-issue also with version 1.89 (18810) from the docking branch under Ubuntu 22.04. Windows 10 is not affected.
    • On an even older version, v1.79 (17900), from the master branch, I wasn't able to reproduce this issue. The input of all characters works perfectly on that version for both Oses (Ubuntu & Windows).

    Expected result: Enter the characters into InputText.



    Preview from the Inputs/Chars queue section in the demo window on Ubuntu

    Standalone, minimal, complete and verifiable example:

    // Include imgui_stdlib
    // Define an input variable outside the render loop
    std::string my_input;
    // Code for the render loop
    ImGui::Begin("Example Bug");
    // Create an example input field
    ImGui::InputText("Test", &my_input);

    Try entering characters ,which require the Alt-Gr modifier, to reproduce it.


    Thanks for the great work on ImGui! This is my first issue to a larger project. I hope I've provided all important information. If further information is needed, I'm happy to help.

  • Metal backend: secondary viewports are not rendered

    Metal backend: secondary viewports are not rendered

    Version: 18916 Branch: docking Backend: + (imgui_impl_sdlrenderer.cpp or imgui_impl_glfw.cpp or Operating System: macOS 12.5 (monterey)

    My Issue/Question:

    The following happens even with example code provided by this repo. On the docking branch with metal backend "child" windows are not rendered if they are outside of the main window (or some part of them is outside, for example a popup or something). Depending on the implementation (sdl vs glfw vs osx) they either completely greyed out or not shown at all. In terminal I get [CAMetalLayer nextDrawable] returning nil because device is nil. every frame.

    Replacing line id<MTLDevice> device = [bd->SharedMetalContext.depthStencilState device]; in the file with id<MTLDevice> device = bd->SharedMetalContext.device; fixes the issue (shown on the video), but I did not investigate this "fix" seriously.

    Screenshots/Video imgui

ROS_Melodic_Qt_GUI_Template is a Graphical User Interface programmed with Qt framework.
ROS_Melodic_Qt_GUI_Template is a Graphical User Interface programmed with Qt framework.

This is a GUI template for ros to control your robot and read data from sensors.

Nov 15, 2022
AnUI is a powerful Graphical User Interface framework made for people that actually care about design!

What's AuUI ** Project is not finished ** AuUI, an abbreviation for "Actual Understandable User Interface" is a graphical user interface framework to

Jun 17, 2022
imgui-filebrowser is a header-only file browser implementation for dear-imgui. C++ 17 is required.
imgui-filebrowser is a header-only file browser implementation for dear-imgui. C++ 17 is required.

imgui-filebrowser imgui-filebrowser is a header-only file browser implementation for dear-imgui. C++ 17 is required. Getting Started imfilebrowser.h s

Jan 1, 2023
GTK is a multi-platform toolkit for creating graphical user interfaces.

GTK — The GTK toolkit General information GTK is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets,

Dec 31, 2022
Advanced 2D Plotting for Dear ImGui
Advanced 2D Plotting for Dear ImGui

ImPlot ImPlot is an immediate mode, GPU accelerated plotting library for Dear ImGui. It aims to provide a first-class API that ImGui fans will love. I

Jan 9, 2023
Real-time GUI layout creator/editor for Dear ImGui
Real-time GUI layout creator/editor for Dear ImGui

ImStudio Real-time GUI layout creator/editor for Dear ImGui Inspired by Code-Building/ImGuiBuilder Features Drag edit Property edit Covers most of the

Jan 9, 2023
Dear ImGui prototyping wrapper.

LabImGui Prototyping framework LabImGui wraps up creating a window, GL bindings, and a full screen docking set up with ImGui so that all of the boiler

Dec 5, 2022
An integrated information center created with dear ImGui using modern C++ design / coding style.

ImGui info-center Introduction An integrated notification and information center created with dear ImGui. Interfaces and variables are designed under

Oct 29, 2022
Addon widgets for GUI library Dear ImGui.
Addon widgets for GUI library Dear ImGui.

ImGui-Addons Addon widgets for GUI library Dear ImGui. File Dialog A simple cross-platform file dialog that uses dirent interface for reading director

Jan 7, 2023
This is a software renderer for Dear ImGui. I built it not out of a specific need, but because it was fun
This is a software renderer for Dear ImGui. I built it not out of a specific need, but because it was fun

Dear ImGui software renderer This is a software renderer for Dear ImGui. I built it not out of a specific need, but because it was fun. The goal was t

Dec 22, 2022
A permissively licensed markdown single-header library for Dear ImGui.
A permissively licensed markdown single-header library for Dear ImGui.

Support development of imgui_markdown through GitHub Sponsors or Patreon imgui_markdown Markdown For Dear ImGui A permissively licensed markdown singl

Jan 8, 2023
Window and GUI system based on Dear ImGui from OCornut
Window and GUI system based on Dear ImGui from OCornut

ImWindow Window and GUI system based on ImGui from OCornut. Include docking/floating window, multi window and multi render support. Platform Actually

Dec 20, 2022
Nice things to use along dear imgui
Nice things to use along dear imgui

Mini hexadecimal editor! Right-click for option menu. Features: Keyboard controls. Read-only mode. Optional Ascii display. Optional HexII display. Goto address. Highlight range/function. Read/Write handlers.

Jan 1, 2023
This is a thin c-api wrapper programmatically generated for the excellent C++ immediate mode gui Dear ImGui.

cimgui This is a thin c-api wrapper programmatically generated for the excellent C++ immediate mode gui Dear ImGui. All imgui.h functions are programm

Jul 5, 2021
Immediate mode 3D gizmo for scene editing and other controls based on Dear Imgui
Immediate mode 3D gizmo for scene editing and other controls based on Dear Imgui

ImGuizmo Latest stable tagged version is 1.83. Current master version is 1.84 WIP. What started with the gizmo is now a collection of dear imgui widge

Dec 27, 2022
Sample Unreal Engine 5.0.1 C++ Project That Incorporates Dear ImGui

UE5 With Dear ImGui A sample Unreal Engine 5.0.1 C++ project that incorporates the Dear ImGui graphical user interface library. YouTube Tutorial This

Dec 25, 2022
Simple ImGui external base. Uses ImGui DX9.
Simple ImGui external base. Uses ImGui DX9.

ImGui External Base ??️ What is this? ⚡ Hello all! I used to use noteffex's loader base for all my external ImGui projects. I got bored of using this

Jun 29, 2022
An addon of imgui for supporting docks in the imgui's window
An addon of imgui for supporting docks in the imgui's window

An addon of imgui for support dock in the window

Nov 29, 2022
GPU Accelerated C++ User Interface, with WYSIWYG developing tools, XML supports, built-in data binding and MVVM features.

GacUI GPU Accelerated C++ User Interface, with WYSIWYG developing tools, XML supports, built-in data binding and MVVM features. Read the LICENSE first

Jan 7, 2023