ImGui.NET VS wxWidgets

Now I'm trying to integrate ImGui into the engine. One solution I found was using this but as far as I can tell it locks you into using OpenGL which is something I would like to avoid as one of the main selling points of SDL2 for me is it's abstraction over the rendering backend.

In additiona to imgui wrapper which works great with NativeAOT, only slight nudge and you have 10Mb executable. With all deps it's 13Mb. Also there Avalonia mentioned in sibling message which work great and in 11.0-preview5 probably would not need any additional configuraiton. In case if OP is have soft spot for web tech, he can use photino.Blazor which also with slight modifications would simply works and produce 27Mb executable.

Imgui gets rendered using ImguiRenderer provided here in the example: https://github.com/mellinoe/ImGui.NET/tree/master/src/ImGui.NET.SampleProgram.XNA

I'm converting rlImGui from C++ to C# so I can use it with ImGui.NET and Raylib-cs but I'm getting stuck at a couple places. I don't know how to convert line 331 to C# since in ImGui.NET cmd.UserCallback is an IntPtr and not something I can call. I did a quick google search and you can use the Marshal library to convert it to a callable delegate but I think you need to also have the delegate known to do that. There's also line 82 but that is specific to Raylib. The function it calls does not seem to be included in Raylib-cs. Also, rlImGui keeps using a Texture type but that is not defined in Raylib-cs or ImGui.NET. I assume I can substitute it with Texture2D from Raylib-cs but I'm not to the point in porting to see if Texture2D has the necessary fields/properties/methods.

ImGui.NET 1.87.3 (using the example implementation)

If you use this example implementation for XNA/MonoGame, you can just use ImGuiRenderer.BindTexture() which returns an IntPtr.

The only thing I could really think of is something like ImGui for C# (https://github.com/mellinoe/ImGui.NET) but I've never used it. It's going to give you some simple wrappers around ImGui (https://github.com/ocornut/imgui) but even this is going to lock you into the UI framework -- you can't just "draw a rectangle" per se and use it as a "control." Do note however this is an "immediate mode" GUI which is different from how most general desktop windowing systems work in "retained mode" (which are typically event driven, which saves on computing power to not draw the same stuff over and over).

The Elixir programming language is no stranger to desktop applications as the language actually supports building them out of the box. It uses wxWidgets: a C++ library that lets developers create applications for Windows, macOS, Linux and other platforms with a single code base. But wxWidgets has a very complex API, and doesn’t solve issues that usually come with desktop applications around packaging.

Qt is also 100% open/free. In fact, both are available under the LGPL, just that wxWidgets also grants an exception to not have to distribute application sources even when statically linked:

https://github.com/wxWidgets/wxWidgets#licence

But for big programs, ones written in C++? Good luck it won’t be easy at all. You might try wxwidgets or qt. I do not predict trying to click box-ify complex cli tools yielding much success.

In theory, you should be able to use FFI to interface with something like wxWindows, but you might again have problems on macOS, I don't know. And to me eyes, Wx looks a bit outdated.

This seems to be like the classic wxWidgets [1], i.e. it's an API that wraps the underlying platform's default toolkit. So on Windows it uses Windows' native controls, in Linux it seems to use GTK, and so on.

That means that the advantage is being able to write against one API, and get cross-platform compatibility, which can be nice. It also means (typically) being limited in what you can do to the least common denominator, or you (=the toolkit author) end up having to re-implement features from one platform that you want to expose but that are missing on some supported target(s). Or, of course, have an API with non-portable parts in it.

In any case, it means the "look and feel" is not the core feature of the API since that is going to be "like the target platform" and that is the point.

Given the origin, I guess Lua support is important too, here.

[1]: https://www.wxwidgets.org/

- So, I found wxWidgets. Which looked good. However, when I followed some tutorials I was getting errors. Even when I copied and pasted the tutorial code. Furthermore, the library still doesn't seem to simplify the process much.

It is the icon for WXWidgets, a programming toolkit for making user interfaces that work on Windows, Mac OS and Linux.

In general, people will use a cross-platform library to port such applications. While QT will likely never really stabilize (I'd flag it unsustainable), the https://www.wxwidgets.org/ is able to be statically linked into commercial and opensource projects at no cost without tripping GPL.

"Hiring a senior C++ developer with GTK experience is costlier"

I think you are confusing skill valuation, and operational productivity. Some have an erroneous notion talent is interchangeable. Likewise, applicants with identical base skill-sets on their CV often mistakenly believe they even have long-term employment options (outsourced, youth tax credit churn, and or senior wage suppression).

Most FOSS people are easier to train, as most already can mitigate utter chaos already. =)

There are a few like that in the C++ community. WxWidgets is the most famous/popular with this approach. But it is a library almost impossible to use in other languages because their api is heavily templated.