Closed lemantisee closed 2 years ago
The Server App is already piping everything OS/GFX specific through a few (10) implementation specific functions, that are clearly identified by a prefix (HAL_xxx inside the 'NetImguiServer::App' namespace) and kept in separate source code also prefixed the same. This means that everything is already separated between Server sources and 'User Rendering implementation'. I am not sure I am seeing the benefit of relying on Class Inheritance for this, other than a coding style preference and a hypothetical support of multiple rendering back-end that could be switched at run time.
To be clear, I was not strongly opposed to the PR. I thought the code looked clean and I am happy to see people interested in improving this library. I this particular case, I was not quite sure I was seeing a benefit of relying on inheritance/polymorphism when only 1 behavior exist per compiled Server application. I used something closer to what I'm used in seeing in game engine (Unreal, my own engine code, ...) where an API define a set of function in a header, and each platform implement them according to its needs, with only one implementation per function in a generated executable.
I totally agree with you that it's important to stay with NetImgui architecture ideas. Actualy I think my PR is too subjective and has a "touch" of my project. So it's not very good for contributing:)
In this PR I introduce the possible refactor of render specific platform callbacks on server side. The main idea is separate library "core" code from user code. I made it with more OOP style and move render callback to delegate system. If user wants to change default render callbacks he just add own delegate and doesn't modifies library core code. This also provides more smooth update process for new version of library on user side.
30