ImFrame VS dotnet

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.

Microsoft .NET Blog: https://devblogs.microsoft.com/dotnet/

Just find some good sites, that keep up with the news/changelogs ( one that I like for c# / dotnet stuff is is: https://devblogs.microsoft.com/dotnet/) as well as the whole c# roadmap on github and where they propose features, and design meetings (https://github.com/dotnet/csharplang/tree/main/meetings). It provides a lot of insight on what they plan on doing with the language). That's usually where I go to keep up with c# stuff.

Microsoft's .NET blog is pretty good for seeing what they're up to.

The .NET Blog has great articles about new and upcoming changes.

how exactly does dotnet 5 acheive this? it makes sense for dotnet 6 since we have different TFM's like net6.0-android, net6.0-ios, net6.0-macos etc. however, if you look for dotnet 5 you only have net5.0 and net5.0-windows TFMs as per given link, https://learn.microsoft.com/en-us/dotnet/standard/frameworks also somebody asked the question how to run .net 5 app on android and the answer given was to preferably still use xamarin/mono, https://github.com/microsoft/dotnet/issues/1253 Also what exactly did change in this regard, does it use same core clr, does it use the same base class library as one used in dotnet core?

Bookmark https://devblogs.microsoft.com/dotnet/ and read occasionally. https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh... is good for a quick overview of language features depending on what version you're at.

Most .NET devs only need to be peripherally aware of these changes, as most businesses using .NET will move slower than Core's new pacing. It's even less important for lower seniority devs as you typically need project changes to utilize new features, which is a call a senior would make, which involves approval/testing/deployment, so a slow process which gives you time to read up on the new features as they're needed.

You're better at your "craft" the more tools you know about and how to apply them, but if your day job prevents you from following the new stuff, I wouldn't worry too much about it.

>I feel .NET Core after a good start is falling into the typical Microsoft trap of constantly cranking out new stuff to do the same thing and leaving it to developers to keep up.

Yeah, the pacing has increasing dramatically from .NET Framework days, but that's probably a good thing. I would just stick to learning about what you do in your day job. .NET has a huge ecosystem compared to other languages, so it's going to be very hard to keep up with everything MAUI is doing if you're doing regular ASP.NET core APIs.

Release Notes

.NET home repo - links to hundreds of .NET projects, from Microsoft and the community.