Does anyone know of something similarly lightweight but retained mode?
You can check out LVGL: https://github.com/lvgl/lvgl/ It's geared more for embedded, but you can use an sdl back end for desktop (which might kill your light weight requirement depending on your strictness level). I wrote my own tty/framebuffer driver for it and use it directly on the frame buffer (not Linux) but it's pretty nice to work with. But if you need metal/openGL/Vulcan/directX and hardware acceleration, it'…
lvgl uses SDL2 could get access to 2D acceleration I think.
Why is is that some developers stick with C89, whilst in the C++ community, unless you work for some really backwards company, you adopt the latest standard before it's even officially nailed down?
I tend to use ImGui for testbed projects. It's flexible and quick to get up and running. I only have two minor complaints about it. 1. It would be nice to have some built in image handling functions, i.e. to be able to allocate and draw images on the screen. 2. Skinning is currently rather limited. (I know this has been a long requested feature). Other than those minor gripes, I like it a lot.
> 1. It would be nice to have some built in image handling functions, i.e. to be able to allocate and draw images on the screen. I think this would actually be fairly tricky to handle inside Dear ImGui, because the image object must be in a format that's understood by the rendering backend. The way ImGui handles image rendering via an opaque ImTextureID handle which is passed through to the renderer backend is actual…
I can see what you mean - but I would think that an array of int32s representing RGBA would be fairly standard these days. ImGui already draws fonts using textures, if I recall.
Here's a simple WASM version of the Nuklear standard demo: https://floooh.github.io/sokol-html5/nuklear-sapp.html The big difference to Dear ImGui is that Nuklear has a C API and is also implemented in C - and apparently it has more skinning/themeing options, which I haven't tinkered with yet. TBH, for tools I prefer cimgui (a C wrapper around Dear ImGui), my impression is that Nuklear has a 'purer' immediate-mode de…
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.
I tend to use ImGui for testbed projects. It's flexible and quick to get up and running. I only have two minor complaints about it. 1. It would be nice to have some built in image handling functions, i.e. to be able to allocate and draw images on the screen. 2. Skinning is currently rather limited. (I know this has been a long requested feature). Other than those minor gripes, I like it a lot.
I suspect (1) is just because Dear ImGui is BYO graphics backend, so it doing lots of clever texture management stuff for lots of images would increase the surface area of that integration which would make it harder to use for most folks.
I would venture that 99% of people who use ImGui do not create their own graphics backend, but rather use one of the standard ones included (I use the OpenGL backend, for example). Creating a new backend would be more work, for sure - although I think that ImGui is already using textures for its font rendering - so perhaps some of that work could be reused.
The default fonts are just plain awful. It's trivial to drop in a better font and make it indistinguishable from native. Possibly a licensing issue as to why they don't include better ones by default as you have to bake it in? or they want to make the binary as tiny as possible by not using a bigger font file?
Font is one thing. The hard part is text layout which is a very very complicated affair, especially if you want to support different languages and/or writing systems.
Yeah this. Once you get to something more than plain English, it means pulling in HarfBuzz
> * Written in C89 (ANSI C) Just why. C17 exist. Why is is that some developers stick with C89, whilst in the C++ community, unless you work for some really backwards company, you adopt the latest standard before it's even officially nailed down? C89 needs to die. Stop supporting it.