cimgui VS scratch

I would recommend C bindings for the Dear ImGui (https://github.com/cimgui/cimgui)

For GUI, there are lots, most well-known of course being Dear Imgui, for which people have made auto-generated C bindings. Another mature but a lot simpler option is Nuklear, as others have mentioned. Even more minimalistic (it's just 1KLOC) is microui. There are a lot more, just google "imgui library c".

DearIMGUI has both an unofficial C wrapper and a new official C binding generator. I have personally used the CIMGUI wrapper with C99 apps using the Direct3D11 backend and it works great. The new API is started by the DearIMGUI creator but is still adding features that are available in CIMGUI.

Unofficial C API - https://github.com/cimgui/cimgui

I would give ImGui a look, it is technically a c++ api, but there is a plain c version https://github.com/cimgui/cimgui/tree/docking_inter which is a free cross platform gui toolset

Whilst this is great. I have a (slightly dumb) question -What advantage does using these bindings give us over just using the generated C IMGUI bindings (cimgui) directly in Zig??Especially given the fact that that the latter are autogenerated from the original C++ IMGUI.

cimgui

This is worth a look: https://github.com/cimgui/cimgui

Dear ImGui is a C++ library, however a C port exists.

Explore GUI frameworks for C Here's another and another

pbmview, an image viewer (windows subsystem).

For comparison (for those following along): https://github.com/skeeto/scratch/blob/master/parsers/qoi.c https://github.com/skeeto/scratch/blob/master/parsers/ini.c

Another option I learned a couple years ago is embedding a UTF-8 manifest ([details])[https://github.com/skeeto/scratch/tree/master/libwinsane]. Also put the console in UTF-8 mode (SetConsoleOutputCP(CP_UTF8)), and you're done. Works on Windows 10 and later. This covers everything: argv is UTF-8 and fopen accepts UTF-8 paths. (This is exactly how CRTs should have worked all along.)

I was thinking more about this and I realized it's quite easy to do it in arbitrary precision, so here's my take: https://github.com/skeeto/scratch/blob/master/misc/bswap.c

As was linked from my QOI article, here's my full decoder with comments: qoi.c. Each pixel decodes to a 32-bit integer, ABGR. That corresponds to SDL's SDL_PIXELFORMAT_ABGR8888. SDL_UpdateTexture copies that data into the texture's internal storage, and font is no longer needed. (In a real program I'd allocate it in a scratch arena, reset after initialization.)

A recent, interesting experience with function+context allocation: For more than a decade, Windows accidentally exposed part of zlib in a public DLL, and (overly-)clever applications can exploit this as a "system zlib." Though it doesn't export the "end" functions, so cleanup seems impossible. However, custom allocation works, so doesn't matter. I plugged it into an arena.