search

ocornut / imgui_test_engine

Dear ImGui Automation Engine & Test Suite
386 stars 40 forks source link

TestSuite: imgui_app.h for Metal #1

Open jacobfriedman opened 1 year ago

jacobfriedman commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

, 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

jacobfriedman commented 1 year ago

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