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

Usage

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:

Code:

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

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

Code:

// 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; }
        ImGui::EndMenu();
    }
    ImGui::EndMenuBar();
}

// 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");
ImGui::BeginChild("Scrolling");
for (int n = 0; n < 50; n++)
    ImGui::Text("%04d: Some text", n);
ImGui::EndChild();
ImGui::End();

Result:
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!

Demo

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).

Integration

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/ES/ES2, Vulkan, WebGPU.
  • Platforms: GLFW, SDL2, Win32, Glut, OSX, Android.
  • 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.

Gallery

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.

For questions, bug reports, requests, feedback, you may post on GitHub Issues or GitHub Discussions. 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?

  • See GitHub Forum/issues and Github Discussions.
  • 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.

Sponsors

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:

Credits

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.

License

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

Comments
  • 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:

    color_picker

    
        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)
                return;
    
            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)
            {
                draw_list->AddRectFilledMultiColor(
                    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],
                    colors[i],
                    colors[i + 1],
                    colors[i + 1]);
            }
    
            float hue, saturation, value;
            ImGui::ColorConvertRGBtoHSV(
                color->Value.x, color->Value.y, color->Value.z, hue, saturation, value);
            auto hue_color = ImColor::HSV(hue, 1, 1);
    
            draw_list->AddLine(
                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));
    
            draw_list->AddTriangleFilledMultiColor(picker_pos,
                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),
                hue_color,
                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)

    TABLES ARE NOW MERGED, MOVING THIS TO #3740

    I have pushed an experimental tables branch: https://github.com/ocornut/imgui/tree/tables 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: https://github.com/ocornut/imgui/issues/2957#issuecomment-569725733

    TODO List: https://github.com/ocornut/imgui/issues/2957#issuecomment-569726095

    WIP API breaking changes Sept 2020 https://github.com/ocornut/imgui/issues/2957#issuecomment-698317698

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

    Status

    • 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 (https://github.com/ocornut/imgui/tree/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.

    Features

    • 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

    image

    image

    image

    image

    image

  • 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:

    https://github.com/ocornut/imgui/issues/124 https://github.com/ocornut/imgui/issues/85

  • 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 ( https://github.com/ocornut/imgui/issues/323 ) 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 https://drive.google.com/open?id=1k4328OV-w20pWZfNcfpH0UoxHHQRkbQi

    imgui controls v6 - ps4 imgui controls v6 - switch

    EDIT: Now in master! Branch: https://github.com/ocornut/imgui/tree/navigation (checkout branch navigation or download from web and overwrite your imgui_xxx files)

    imgui-nav-20160821b

    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
        ImGuiNavInput_COUNT,
    };
    

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

     USING GAMEPAD/KEYBOARD NAVIGATION [BETA]
    
     - Gamepad/keyboard navigation support is available, currently in Beta with some issues. Your feedback and bug reports are welcome.
     - See https://github.com/ocornut/imgui/issues/323 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);
         ImGui::NewFrame();
    
       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.

    Thanks!

  • Menu bar is off by one pixel from the top

    Menu bar is off by one pixel from the top

    Version/Branch of Dear ImGui:

    Version: v1.87 WIP Branch: docking

    Back-end/Renderer/Compiler/OS

    Back-ends: custom, Win32 + D3D12 Compiler: MSVC 2022 Operating System: Windows 10

    My Issue/Question:

    I have an app with a menu bar and I noticed that the menu bar starts at y-coordinate of 1, not zero, so it's one pixel away from the top of the window. Ideally, it'd extend all the way to the top so as to become an infinite-height target and easier to reach with the mouse via sliding the cursor all the way to the top of the window when in fullscreen mode.

    Screenshots/Video

    Screenshot 2023-01-04 212153 Screenshot 2023-01-04 212148

    Standalone, minimal, complete and verifiable example: N/A

  • Win32 backend: can't hover over nonclient areas when window does not have focus

    Win32 backend: can't hover over nonclient areas when window does not have focus

    Version: 1.88 Branch: master/viewport/docking

    Back-ends: imgui_impl_win32.cpp Compiler: vs2022 Operating System: Windows 11

    imgui buttons that are part of the nonclient area of the window behave correctly only when the window has focus:

    When creating a frameless window with owner draw captions you can use imgui buttons for min/max/close buttons, by appropriately processing WM_NCHITTEST on the button regions. This works fine when the window has focus (is foreground). In this case AddMousePosEvent is not called from ImGui_ImplWin32_WndProcHandler's WM_MOUSEMOVE handler since they are considered nonclient areas. Instead, AddMousePosEvent is called from ImGui_ImplWin32_UpdateMouseData(). However, UpdateMouseData checks first that the window has focus, so that when the window does not have focus AddMousePosEvent is never called and hover tests fail.

    ImGui_ImplWin32_WndProcHandler should probably handle WM_NCMOUSEMOVE as well as WM_MOUSEMOVE.

  • Custom draw widget/Using images in widgets?

    Custom draw widget/Using images in widgets?

    I’ve been using ImGui for some simple UI need and like it a lot.

    I do feel that the look and feel of the widgets are very “structured”, in the sense that they resemble those in a desktop application. And most efforts to customize it are limited to colors and styles.

    Is it possible to completely customize how a widget is drawn? I know there’s an ImageButton. What about using an image (or two) for a SliderFloat for example? If so are there any examples how this can be done? I want to create an “unstructured” effect like UIs in a game.

  • Clipping for differing row heights

    Clipping for differing row heights

    Version/Branch of Dear ImGui:

    Version: 1.89.1 Branch: master

    Back-end/Renderer/Compiler/OS

    Back-ends: imgui_impl_sdl.cpp + imgui_impl_opengl3.cpp (using GLEW) Operating System: Windows 10

    My Issue/Question:

    I am trying to implement clipping behavior for a table with rows of different heights. (Some of my rows are single-line and some are multi-line; I would like to avoid pagination, if possible.) From what I can tell, the ImGuiListClipper assumes that all the rows are the same height.

    Is there a reasonable way to emulate some sort of clipper for my requirements with the current tools Dear ImGui provides (without rewriting a lot of what Dear ImGui does under the hood)? I was thinking of doing something along the lines of caching the size/geometry information of each row, eliminating the need for Dear ImGui to recalculate it every time and avoiding extra conversions of my data to string representations (I would store this size/geometry information with each of my rows and update it for a given row whenever it is modified); however, I am unsure how I would go about "providing" that information to Dear ImGui.

    Simple Screenshot of the Differing Heights:

    image

  • Popup auto-resize goes beyond windows limit if content is added

    Popup auto-resize goes beyond windows limit if content is added

    Hello,

    I am using version 1.89.1, main branch, and is facing an issue with popup since some time. Basically everything is fine, but when some content is added to an existing popup then its is resized (as per ImGuiWindowFlags_AlwaysAutoResize flag), but it can grow beyond the window size (so the last widgets are not accessible nor visible).

    What I would expect in this case is to resize the popup until the bottom of the window, and then add a vertical scroll bar if required.

    If I close the popup and open it again, it is ok : the popup will be displayed higher on the screen so that all the content is visible. This is not a major issue, but it would be nice to have a fix to improve user experience.

    image

    Basic code in imgui_demo.cpp

          // Showing a menu with toggles
           if (ImGui::Button("Toggle.."))
               ImGui::OpenPopup("my_toggle_popup");
           if (ImGui::BeginPopup("my_toggle_popup"))
           {
               for (int i = 0; i < IM_ARRAYSIZE(names); i++)
                   ImGui::MenuItem(names[i], "", &toggles[i]);
    //--- added code start ----
               static bool addLines = false;
               ImGui::Checkbox("add items", &addLines);
               if (addLines) for (int i = 0; i < IM_ARRAYSIZE(names); i++) ImGui::MenuItem(names[i], "", &toggles[i]);
    //--- added code end----
               if (ImGui::BeginMenu("Sub-menu"))
               {
                   ImGui::MenuItem("Click me");
                   ImGui::EndMenu();
               }
    

    Regards

Cross platform rapid GUI framework for golang based on Dear ImGui.
Cross platform rapid GUI framework for golang based on Dear ImGui.

giu Cross platform rapid GUI framework for golang based on Dear ImGui and the great golang binding imgui-go. Any contribution (features, widgets, tuto

Dec 28, 2022
A unified graphical user experience toolkit for Go desktop applications

Unison A unified graphical user experience toolkit for Go desktop applications. macOS, Windows, and Linux are supported. Required setup Unison is buil

Dec 20, 2022
Native Go (golang) Graphical Interface system (2D and 3D), built on GoKi tree framework
Native Go (golang) Graphical Interface system (2D and 3D), built on GoKi tree framework

GoGi is part of the GoKi Go language (golang) full strength tree structure system (ki = 木 = tree in Japanese) package gi is a scenegraph-based 2D and

Dec 25, 2022
Windows GUI library for Go (Golang). Comes with a graphical UI designer.

Version 2 Please go to Version 2 of this library for the latest version. Windows GUI Library This is a pure Go library to create native Windows GUIs.

Jan 1, 2023
Hedgex Single User Interface With Golang

Hedgex Single User Interface With Golang

Nov 3, 2021
Super minimal, rock-solid foundation for concurrent GUI in Go.
Super minimal, rock-solid foundation for concurrent GUI in Go.

faiface/gui Super minimal, rock-solid foundation for concurrent GUI in Go. Installation go get -u github.com/faiface/gui Currently uses GLFW under th

Dec 23, 2022
A minimal material design based UI toolkit for Tiny Go projects
A minimal material design based UI toolkit for Tiny Go projects

A minimal material design based UI toolkit for Tiny Go projects.

Sep 3, 2022
Wmi - One hot Go WMI package. Package wmi provides an interface to WMI. (Windows Management Instrumentation)

wmi Package wmi provides an interface to WMI. (Windows Management Instrumentation) Install go get -v github.com/moonchant12/wmi Import import "github.

Apr 22, 2022
Go wrapper library for "Dear ImGui" (https://github.com/ocornut/imgui)
Go wrapper library for

Dear ImGui for Go This library is a Go wrapper for Dear ImGui. This wrapper started as a special-purpose wrapper for use within InkyBlackness. However

Jan 2, 2023
Cross platform rapid GUI framework for golang based on Dear ImGui.
Cross platform rapid GUI framework for golang based on Dear ImGui.

giu Cross platform rapid GUI framework for golang based on Dear ImGui and the great golang binding imgui-go. Any contribution (features, widgets, tuto

Dec 28, 2022
Like tar but different. PitCH is an archive file format that aims for high performance and minimal bloat.

Like tar but different. PitCH is an archive file format that aims for high performance and minimal bloat.

Feb 17, 2022
A unified graphical user experience toolkit for Go desktop applications

Unison A unified graphical user experience toolkit for Go desktop applications. macOS, Windows, and Linux are supported. Required setup Unison is buil

Dec 20, 2022
Native Go (golang) Graphical Interface system (2D and 3D), built on GoKi tree framework
Native Go (golang) Graphical Interface system (2D and 3D), built on GoKi tree framework

GoGi is part of the GoKi Go language (golang) full strength tree structure system (ki = 木 = tree in Japanese) package gi is a scenegraph-based 2D and

Dec 25, 2022
“Dear Port80” is a zero-config TCP proxy server that hides SSH connection behind a HTTP server!

Dear Port80 About The Project: “Dear Port80” is a zero-config TCP proxy server that hides SSH connection behind a HTTP server! +---------------------

Jun 29, 2022
word2text - a tool is to convert word documents (DocX) to text on the CLI with zero dependencies for free
word2text - a tool is to convert word documents (DocX) to text on the CLI with zero dependencies for free

This tool is to convert word documents (DocX) to text on the CLI with zero dependencies for free. This tool has been tested on: - Linux 32bit and 64 bit - Windows 32 bit and 64 bit - OpenBSD 64 bit

Apr 19, 2021
A minimal analytics package to start collecting traffic data without client dependencies.

go-web-analytics A minimal analytics package to start collecting traffic data without client dependencies. Logging incoming requests import "github.co

Nov 23, 2021
CLI client (and Golang module) for deps.dev API. Free access to dependencies, licenses, advisories, and other critical health and security signals for open source package versions.
CLI client (and Golang module) for deps.dev API. Free access to dependencies, licenses, advisories, and other critical health and security signals for open source package versions.

depsdev CLI client (and Golang module) for deps.dev API. Free access to dependencies, licenses, advisories, and other critical health and security sig

May 11, 2023
Hassle-free minimal CI/CD for git repositories with docker or docker-compose projects.
Hassle-free minimal CI/CD for git repositories with docker or docker-compose projects.

GIT-PIPE Hassle-free minimal CI/CD for git repos for docker-based projects. Features: zero configuration for repos by default automatic encrypted back

Sep 23, 2022
A graphical text editor
A graphical text editor

A A is a text editor inspired by the Sam and Acme text editors for the Plan 9 operating system. binary Latest Binaries https://github.com/as/a/release

Dec 13, 2022