Moving them from examples to backends doesn't change anything. That's likely just a sign that "examples" is now examples of using the API, not examples of integrating with some GPU API.
One of the main reasons/goals/points of Dear ImGUI is being able to ingrate it into existing projects. It's deliberately API agnostic. It generates a very simple command list that you can then trivially render yourself in your own engine.
Everything else, all the platform specific code in the repo is entirely there to help people understand how to use it or to get started.
It's a mistake to think otherwise because it incorrectly limits Dear ImGUI's perceived usefulness. If you believe you have to take a backend or use one of the APIs provided then you'll mistakingly believe it would be hard to put in your existing game. If you understand what it's really about then it's trivial to put it in almost anything. That is by design.
I think it's a bit of both.
From the point of view of game programmers and custom engine users/creators, it's important to know that Dear ImGui will be easy to integrate in whatever odd-custom tech they may have, and I am on the watch to hold that guarantee around, and to keep communicating it.
At the same time, effectively probably 90% of homebrew custom engines not build in a professional context are build over common known technology, Win32 API, SDL/GLFW, DX11 etc. And it makes sense to provide the ready-to-use glue to ensure you can integrate Dear ImGui is most apps with <20 lines of code. It's even more meaningful to have that possibility when you are bootstrapping a new projects or are wholly unfamiliar with programming or graphics technology.
The feature scope of Dear ImGui has grown meaningfully over the years, and although the only "required" elements are still mouse pos/buttons, time and rendering those vertices with scissoring, in reality there are many other desirable things which adds up to more work to provide (clipboard, keyboard, gamepads, mouse cursor shape, IME hooks, dpi queries, not mentioning multi-viewports).
You can see my reasoning for renaming examples/ to backends/ here:
https://github.com/ocornut/imgui/issues/3513
If anything, I found the tendency of my-weekend-engine people to do their first foray into Dear ImGui often improductive and detrimental to the perception of using Dear ImGui. They tend to struggle 4 hours to get a feature-incomplete backends done instead of first plugging fully working existing backends with <20 lines THEN considering if they really need to rewrite that. I believe that did more bad than good to Dear ImGui because they end up using feature incomplete versions. It's also that years fixing those backends to try to have them work everywhere has been helpful in growing the confidence of calling them backends.
I believe this is mostly communication issue: we should keep hammering that backends are reasonably easy to rewrite and keep documenting that process.
I had different feelings about the examples. Seeing example integrations into so many rendering apis reassured me that it would be trivial to add Dear Imgui in to my own projects. Without the examples you have to take it on faith that they designed their api to be easily integrated.
Many libraries claim to be cross platform and turn out to be hugely painful to use on anything outside of a few intended targets. I still have nightmares about Scaleform!
> Moving backends code from examples/ to backends/… 24 days ago