ImFrame VS copperspice

If you need a quick way to start a C++ ImGui app, you can use my ImFrame library. It's essentially a C++ application wrapper around glfw + ImGUI, along with a few handy additions that applications might need, like native file and folder dialogs, automatic windows settings / persistence, etc.

If you want a demo, you can use my starter framework to see if it would work for you, or check out Implot's repository directly.

If you want a Dear Imgui "starter kit", you can try ImFrame. It packages a few libraries into a very lightweight cross-platform application framework.

If you just want an empty app in which you can play with ImGui, you can use a lightweight framework like ImFrame.

To help with this, I made a framework that makes it much easier to use like a more traditional application framework, providing a few handy features you'd expect, like native file dialogs, window position save/restore, native macOS windows, platform-appropriate settings storage, image loading, a selection of fonts, etc.

Probably the fastest way to do that is to use something like my ImFrame library, which is designed to get Dear ImGui and ImPlot up and running inside an app with minimal fuss and bother. You'll need to use CMake to build the project, but it's pretty simple, as there are batch files to build in the /Bin folder for Windows, Mac, or Linux.

Dear ImGUI - Unlike the others, is designed for applications with a real-time rendering loop, such as games. Was originally designed for creating debugging UIs, although has expanded far beyond this, and is now used for full-featured applications. Requires an existing back-end to plug into. If you need an application framework for Dear ImGUI, you can use my own project ImFrame, or something similar.

I use CMake as my (meta) build system, and generate VS projects on Windows, Xcode projects on Mac, and Code::Blocks projects/makefiles on Linux. Example of one such project of mine: https://github.com/JamesBoer/ImFrame

I'm currently writing a Dear Imgui framework called ImFrame. It handles the work of creating an application loop with an appropriate renderer, using GLFW and other open source libraries, and then exposing the Dear Imgui API for your use to do what you want with it.

For example, in one of my libraries (you can see the whole thing here), I'm including the single-header library stb_image.h as a separate project, so it shows up with all the other external libraries. It's not necessary for compilation, but is just there to assist with browsing / seeing all the external libraries.

Tangentially, I just listened to an old cppcast about https://www.copperspice.com/, a QT fork with ambitions of being more c++-ey.

There was already a fork of Qt 4. It is tootling along fine: https://www.copperspice.com/

BTW, CopperSpice sounds pretty close to what you're mentioning: https://www.copperspice.com

If you already have a lot of use of Qt your might find CopperSpice to be a reasonable compromisehttps://www.copperspice.com/

exactly I'm quite happy to have my code written for me. If you don't like the moc you can use CopperSpice https://www.copperspice.com/

CopperspiceCopperspice

CopperSpice might be worth looking at too. Coming from Qt you're probably going to like it better than wxWidgets.

So I strongly dislike Qt. It's got a predatory vision for open source enforcement where they mislead their customers with spoopy language and make it harder and harder to download. In addition, they continue to insist on an architecture that's not even actually C++ (it's got a different grammar) despite it being completely possible to architect a better version of their designs in standard C++.

See copperspice project. Originally forked to work around short coming of Meta-Object Compilation.