> 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 actually quite elegant IMHO.
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.
I suspect that the majority of ImGui users use one of the included, ready-to-use backends. For example, I use the OpenGL one. I work around the lack of images, handling the textures myself, but it's always struck me as an odd omission.
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.
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.