Feedback wanted: Expected refactor in 1.80: Moving backends files? Adding a imgui_tables.cpp file?

[ocornut]

Looking for feedback on those topics. If you have opinions or concerns feel free to voice them :)

1. Moving backends?

For 1.80 we are currently considering moving the examples/imgui_impl_xxx files to backends/imgui_impl_xxx (or backends/imgui_backend_xxx even?). Initially those back-ends were added to examples/ as a way to suggest that there are easy to adapt or write for custom user/engine needs. It was also a way to lower our responsability "this is just an example, tweak it".

Nowadays:

• The backends are for most rather solid. For API like OpenGL, they handle a bunch of cases of saving/restoring random OpenGL context which is very useful for new or casual users. Generally speaking I would want us to keep improving those back-ends if there is a reason too.
• Supporting multi-viewports from the docking branch generally requires more involvement from back-ends writer. Whoever uses default back-ends can benefit from multi-viewports instantly (vs custom back-ends often don't).
• The fact that they are stored in examples/ DOES have the expected effect of passively encouraging my-custom-engine people to rewrite their own. I think this is now becoming counter productive, since it means some people are spending 2-3 days integrating dear imgui for the first time instead of the 30 minutes it should take, because they insist on reimplementing a back-end. When they do, their back-ends often have subtle issues they don't immediately notice. I've seen countless cases of people spending time reimplementing a back-end for their lightweight abstraction, only to scrap it and use the default back-ends eventually. It's absolutely counter-productive because 1) they would be better off starting with available back-ends, even if it means using multiple backends for portability (we should encourage/document that better: if a custom-engine is aimed to be portable, people can use multiple default backends!). 2) anyone can decide to rewrite the back-ends AFTER THE FACT and after they are acquainted with dear imgui, but there's no reason to do it day one.

We're only talking about moving files here... I'm mostly interested in the psychological side effects of this change...

It should be a small, easy to document and convey, one-off project breaking change (e.g. change a file-path). Currently evaluating if it'd be a good occasion to break something else (e.g. explicit back-end context creation).

2. New source file: imgui_tables.cpp?

For 1.80 we are aiming to merge the tables branch into master.
Tables have been developed in imgui_widgets.cpp but seeing that it is now becoming a large file, I was thinking it would be sane to split it and move that code in imgui_tables.cpp. We will also aim to fully rewrite the git history so all tables developments goes directly into imgui_tables.cpp.
If possible I would like to avoid different branches using different files, in order to facilitate switching projects, so I would only do this change just prior to merging in master.
Similarly, for 1.90 (hopefully) I think I'd like to move docking code out of imgui.cpp and into imgui_docking.cpp

[Folling]

+1 for the rename of examples to backends. I think it would make it more obvious for people. Before I checked them out I thought the examples folder was for showcases of Dear ImGui, not of potential backends, so this should help clear up some potential confusion.

Also +1 on the separation of files, it's a subjective topic of course, but in general I like having files be as small as possible whilst remaining as large as necessary to be coherent in and of themselves. imgui.cpp's 10k+ lines are hard enough to maneuver as is for me, so I'm all for some separation there. (even my plain vim editor takes a few seconds to open it :P)

[thedmd]

I'm in favor of all mentioned changes.

[hinxx]

Same here, the proposed changes seem acceptable.

I'm a heavy user of example backend implementations and find them very useful to get a project up and running quickly. What I usually do is take core files + example backend + demo main and drop it into my source folder. Taking files from another sub-folder(s) is a non issue I say.

[twaritwaikar]

I wasn't actually expecting to see backends being in examples/, I somehow forgot about that and assumed something else. But yes, a backends/ folder is good.

EDIT: As for the imgui_docking.cpp and imgui_tables.cpp files, I don't think it would affect the API much because what happens in the .cpp files is often not in my interest as a Dear ImGui API user. So you should feel to do whatever is best to maintain

[kudaba]

+1 on both, you should probably leave the old example files and have them #include the new ones when IMGUI_DISABLE_OBSOLETE_FUNCTIONS is not defined so you don't instantly break everyone.

[RoryO]

1. Moving backends?
   👍 however I strongly suggest you merge or close existing PRs targeting anything in examples before you push a commit that moves them. It will get messy for the contributor trying to sort that out.

[ocornut]

In my experience git handles renaming fairly well there?

[twaritwaikar]

@ocornut I have seen git registering renamed files as deleted files (accompanied with an added file of the new name) if they have been both renamed AND moved to a different directory

[Pagghiu]

Looks all good to me!

[immehulsolanki]

+1 on first idea!

We're only talking about moving files here...

That will really save time for newcomer

My suggestion :
All the specific framework depended files are located inside respective folder with name libs or any other.

Inside backend folder, all the files which are not needed to be modified in any manner(dearimgui implementations). << i am saying forcing user to use imconfig.h

Inside example folder, just one main.cpp demo and its make file pointing its respective lib from backend folder.

i was not sure where to put prerequisites file so i put inside both.
demo:

This will allow user to decide exactly which folder and files needs to be copied for integration.

prerequisites.sh or prerequisites.txt:
.sh or .bat: This files is automatic check step for system dependencies and if not exist it will install it automatic.
Or may be in plain
.text: file suggesting required dependencies.
In simple word command line automation for single click run!
example: "intel openVino toolkit"

Cross Platform IDE:
In windows everything is straight forward, but in Linux its not, it would be great if cross platform IDE integration is provided.
Example:VSCode and Code block
In Vs code all the configuration rest in .vscode folder. User simply open example folder and it runs!!!

I'm mostly interested in the psychological side effects of this change...

Speaking of psychological side effects, this is how it works:
Despite of 2D/3D professional game developer,

Mostly new user searches on search engine with specific keywords:
"Best cpp/c++ gui library"
"Portable c++ gui library"
"Best crossplatfom c++ gui library"
"Light weigh cpp 2d library"
etc...

In this context, this is xyproblem as suggested in doc, people want's simple, fast, effective and minimalist visual controls like button,slider, label, filesystem access, charts and image viewer!!!

but they don't know where to find it, so they will cherry pick 2-3 items from the search results,
now the next search is:
"how to install x library"
"x library helloworld example"
etc...

now if it runs by following certain steps as suggested in official doc or web-tutorials, it will be adopted.

if anyone interested to understand how above thing works then just pick one library that "you have never used" before and try to download, install and integrate in one day.

My suggestions:
Dear Imgui's own website and web-discussion forum or blog.
some mostly used discussion platform for question and answers:
stackoverflow
quora
reddit
etc...
Discord is a great platform, But may be it does not allow Search engine to fetch the contents.
But the thing i suggested above will be, so its more handy. By this way all the repetitive/common errors and questions-Answers will be available directly from the search results.

My suggestion tool:
https://www.doxygen.nl/index.html
Example:OpenCv library.

But why?
Well, C++ Gui is lost kingdom in the era of python,
Apart from game developments, now a days,
Machine learning,
Data science,
Artificial intelligence,
Image processing,
Speech reorganization and
academic researches on mechanical, structural analysis,FEA,FEM,CAD, robotics and other engineering
requires faster computation as well as real time visualizations.
But not enough resources for that....
specking of enough resources I am talking about non CS guys and other programming language programmers tools and tutorials.

Some embedded PCs like RaspberyPi project also requires Faster Gui.

More than 1 million people actively involved in Machine learning filed alone. (According to you tube video views)
Since Qt has restrictive license Dear imgui can hold the spot. ;)

[ocornut]

Pushing WIP branch for backend moving in:
https://github.com/ocornut/imgui/tree/features/moving_backends

[ocornut]

(1) Moved all backends to backends/ in all branches now.

[sonoro1234]

I dont know if it will be enough for users to realize that they can use those imgui_impl_XXX files instead of writting their own ones.
But I have checked in the cimgui usage that many users are not aware of that, so I added a backend_test demonstration with SDL and opengl3.

[ocornut]

(2) tables branch now has all code moved to the new file imgui_tables.cpp
(we fully migrated/rewrote history, thanks to help from rokups, so from early tables commit it now appears in imgui_tables.cpp)

I expect tables branch to be merged in master this week so I'll close this issue now.