TestSuite: imgui_app.h for Metal

[jacobfriedman]

OF course, "// THIS IS FOR OUR OWN USE AND IS NOT SUPPORTED."
It would be nice to have the struct / types / etc clearly defined in the header rather than in the cpp file.

Please let me know if you'd rather not have me add 'issues' such as this. Alternatively, when I have some free time I can tackle it myself and make a request (lmk)

[ocornut]

Why would you need those structures? What are you trying to solve?

(additionally: what is unclear about that statement in bold that you pasted? ;)

[jacobfriedman]

Ah, nothing is unclear (re: statement in bold)- simply that I understand it's not a priority.

The cpp didn't care to pick up my #define s , even though I scattered them at every point I could. I believe it was a complex issue with my compiler or pipeline (one that I've run out of time to solve).

Nevertheless, it's usually best practice to put those declarations in the header files.

Goal: I'm trying to imbue imgui_app in my program.

[jacobfriedman]

Adding to the "why would you need those structures"- I wanted to access GLFW* window after converting the ImGuiApp type to the ImGuiAppGLFW type, but the struct wasn't found (neither was window).

[ocornut]

Goal: I'm trying to imbue imgui_app in my program.

That's the problem.

The whole point is we don't want to provide imgui_app as a general-purpose service for users. Maintaining public backends and examples has been a problematic source of energy drain, taking us away from development of actual dear imgui, we don't want this meta backend to be used by people.

The cpp didn't care to pick up my #define s , even though I scattered them at every point I could.

If your cpp file is compiled from a project definition the define needs to in a project. It's an issue with you using your build system.

e (one that I've run out of time to solve).

Then you are asking about a XY Problem.

[ocornut]

, it's usually best practice to put those declarations in the header files.

I wholly disagree, what's "best practice" in some internet circles are not best practices in some pro circles.
If we were to follow stack-overflow-hacker-news-clique best practices Dear ImGui absolutely wouldn't exist.

[ocornut]

I'm closing this as invalid use, part of the reason those structs are not in .h is we don't want user app to use that code and it is clearly stated in bold in the header. This is internal use. If you want to use it, copy modify it a you wish that's fine but we can't maintain this as a service.

[jacobfriedman]

Thanks. Sorry for taking your time, and I appreciate the quick response- in future I'll have more concrete examples to contribute to this tester.

[ocornut]

Absolutely happy you ask questions and open issues. Anything that can be improved and sturdied should be. In this instance, what should be sturdied is the understanding that this is not code designed to be maintained for others :)

[jacobfriedman]

I've changed the title of this thread...

Updating to metal, please let me know if you have an inclination to eventually merge into imgui_app (I may simply use a bare .mm file if APPLE is defined.

https://github.com/jacobfriedman/imgui_test_engine/tree/imgui_app_glfw_metal

[ocornut]

Feels strange to duplicate the entirety of imgui_app.cpp, couldn't something simpler be designed?

[jacobfriedman]

I have a working cleaner version, but it needs its own makefile. Not ready just yet.