Orx impl

[thegwydd]

This is an implementation that brings ImGui to Orx game engine http://orx-project.org/.

[ocornut]

Hello,

Thanks for posting those PR.

I see a few issues here:
A) Lots of the code doesn't closely follow the coding convention of existing imgui examples (naming conventions, comments, tabs, alignment, extraneous levels of abstraction)
B) Not sure why the clipboard code maps the contents to userdata and uses a std::map. The userdata pointer is only provided to ease the implementation of the back-end. If you don't need to use it, don't use it. Dependencies on both std::map and std::string would better be removed.
C) I'm generally not favorable with adding new back-ends for game engines in the repository, unless I have reasonable guarantee that the back-end will have an active user base and will be maintained by someone (I am not a user of Orx myself). Otherwise the burden is on me and bindings are seldomly actively maintained. Marmalade is an exception which was submitted a long ago and I think it should be moved elsewhere now (see D).

My suggestion would be to do A and B and then host the project on a separate repository (which I will link to in the README + Wiki).

D) I am also considering the possibility of creating an official repository to host third party bindings, provide write access to their writer, and where we could gather the many existing bindings.

Let me know what you think.

[thegwydd]

Hello Omar, - regarding point A, well, nothing to say, you're totally right! :) - regarding point B I'll fix it as it seems I misunderstood the feature. - I perfectly understand your point and I agree. I'll move the back-end to ORX repo so it will not be your burden. Well, the repo for third party back-ends sounds nice as, apart from the obvious, it had an added value about keeping historical stuff. Links to other site may be broken, sites may close...if you keep stuff in a repo it will survive in time as long as imgui project survives. Ok then, I'll send you a link to the ORX site/github when I'll fix A and B. Thanks for all Omar, Denis Brachet

…

On Sun, May 27, 2018 at 9:43 PM, omar ***@***.***> wrote: Hello, Thanks for posting those PR. I see a few issues here: A) Lots of the code doesn't closely follow the coding convention of existing imgui examples (naming conventions, comments, tabs, alignment, extraneous levels of abstraction) B) Not sure why the clipboard code maps the contents to userdata and uses a std::map. The userdata pointer is only provided to ease the implementation of the back-end. If you don't need to use it, don't use it. Dependencies on both std::map and std::string would better be removed. C) I'm generally not favorable with adding new back-ends for game engines in the repository, unless I have reasonable guarantee that the back-end will have an active user base and will be maintained by someone (I am not a user of Orx myself). Otherwise the burden is on me and bindings are seldomly actively maintained. Marmalade is an exception which was submitted a long ago and I think it should be moved elsewhere now (see D). My suggestion would be to do A and B and then host the project on a separate repository (which I will link to in the README + Wiki). D) I am also considering the possibility of creating an official repository to host third party bindings, provide write access to their writer, and where we could gather the many existing bindings. Let me know what you think. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1843 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APCq9QvTL-HFj4fsVhL9p84twRmjHTkFks5t2wHrgaJpZM4UPRjI> .

[ocornut]

Thank you Denis!

I'm currently working on a refactor of the examples/ folder (I think it may hit master in 1.62 or 1.63) which should simplify maintenance a little. I won't affect your work much as in the case of a high-level engine your file will cover both rendering and windowing/input aspect, but for other platforms I am splitting them.

It will be useful to find a way to keep binding centralized and vaguely up to date as the upcoming viewport branch (#1542) will requires more work from the binding (it will be 100% optional, and I don't think every engine will be able to full-fill the requirements for the viewport branch, but it'll be nice if we can get it to work on more engines).

I also would like to work on a demo app that helps "testing" the integration of a binding, to quickly check which feature may be missing or incomplete.

All of this hopefully will lead us to have bindings be more in the spotlight in the upcoming months, and then we can decide how we want this to evolve. I think the main advantage of a centralized bindings repository is that we can raise the incentive for people to maintain and fix them over time (easily grant write access or merge PR, so even if the original author is away users could have a centralized and welcoming location to push and pull etc.).

[ocornut]

Hello @thegwydd,

I have noticed there's now a https://github.com/thegwydd/ImGuiOrx repository for this purpose so I am going to link to this and close the PR.
Since your thegwydd/imgui tree appears unmodified, I think it would be preferable if ImGuiOrx pointed to ocornut/imgui directly (can the same commit) and not thegwydd/imgui.

Well, the repo for third party back-ends sounds nice as, apart from the obvious, it had an added value about keeping historical stuff. Links to other site may be broken, sites may close...if you keep stuff in a repo it will survive in time as long as imgui project survives.

I agree with this but it would mean I am the one taking the responsibility and maintenance burden for everyone, and I can't be doing that. Later I don't rule out opening another repo, e.g. imgui_bindings which would have more open write access so we could gather bindings.

[thegwydd]

Hello Omar, sorry for the delay in the answer. We're completing documentation on how to use imgui in our orx engine and the next week we should havea wiki page ready for this. Meanwhile I'll follow your suggestion about linking the original imgui repo instead of my fork. As soon as our page is ready I'll inform you in the case you want to link it as one of the many supported engines. Thank you, Denis

…

On Wed, Feb 27, 2019 at 2:58 PM omar ***@***.***> wrote: Hello @thegwydd <https://github.com/thegwydd>, I have noticed there's now a https://github.com/thegwydd/ImGuiOrx repository for this purpose so I am going to link to this and close the PR. Since your thegwydd/imgui tree appears unmodified, I think it would be preferable if ImGuiOrx pointed to ocornut/imgui directly (can the same commit) and not thegwydd/imgui. Well, the repo for third party back-ends sounds nice as, apart from the obvious, it had an added value about keeping historical stuff. Links to other site may be broken, sites may close...if you keep stuff in a repo it will survive in time as long as imgui project survives. I agree with this but it would mean I am the one taking the responsibility and maintenance burden for everyone, and I can't be doing that. Later I don't rule out opening another repo, e.g. imgui_bindings which would have more open write access so we could gather bindings. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1843 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APCq9TlETeMUtojxkmYdDumBMsS6SkF2ks5vRo8MgaJpZM4UPRjI> .