ofxImGui widgets ?

[Daandelange]

Hello again,
I'm currently thinking about a way for ofxAddons to optionally support implementing custom ofxImGui widgets.
The current implementation is opt-in by compiling a project with a global ofxAddons_ENABLE_IMGUI defined.
On your side, there would be 2 new isolated files, src/ofxNDIImGuiEx.h and src/ofxNDIImGuiEx.cpp plus eventually a new example.

Here's an example of how the GUI might look like. See my imgui-widgets branch for implementation details.

What do you think about such an approach ? Would you be interested in integrating it into ofxNDI ?

[leadedge]

I think if there was only one definition that would be fine. But adding two source files that require an additional addon creates a dependency that has to be managed for update and support and I don't want to go that far.

You have put a lot of work into the additional files for ofxNDI, so is it possible to document the steps required for a user to implement the idea? Perhaps document "example-imgui". A link to that could be added to the readme file.

I tried to build from your fork and immediately ran into a problem that there are multiple ofxImgGui's to choose from. I chose the most recent but it must have been the wrong one because "#define ofxAddons_ENABLE_IMGUI" was not in ofxImgGui.h. Even if I put it in this file or into other files it was still not recognised. Removing the #ifdef from ofxNDIImGuiEx got it compiling.

It is certainly impressive and comprehensive. I would have liked the option to show or hide the gui somehow. Perhaps I missed something.

Right now I am finishing ofxWinDialog which is strangely another GUI concept but with a "non-GUI" approach and different aims.

[Daandelange]

Thanks for looking into this and sharing your thoughts. :)

Yes I understand your "maintenance fears" and that's why it's completely disabled by default, adding no dependencies and causing no compilation issues. The GUI part (and its ofxImGui requirement) can be enabled on demand by 1. enabling a compilation flag and by 2. including ofxImGui in the ofApp project. By default it adds 2 empty files (and a dedicated example) = nothing.
As to its maintenance : as users use it, they could submit fixes and improvements, but that's wishful thinking. If one day it breaks and users complain, you could simply remove it (or it would just bother nobody until it gets fixed). What about a Warning! Unsupported by the plugin author. Bla bla etc. message somewhere to clarify the widgets state ?

I have ImGui widgets for lots of the ofxAddons that I use, and indeed it's taking some time to write so I'd like to share them somehow. Adding them to ofxImGui would create a big dependency overhead for most users, it's good to keep a GUI lib minimal. So I really think they belong within the relative addons. An alternative would be to make a big "ofxImGuiAddonWidgets" but that would be a big dependency mess to install = not so useful. Or 1 extra addon per ofxAddon (ex: ofxNDIImGuiWidgets) but that would possibly double the user's ofxAddons folder.

Imgui: Yes you need the develop branch, sorry for the confusion. And ofxAddons_ENABLE_IMGUI needs to be defined in the ofApp project settings (IDE compiler defines), not in a header file. If you regenerated the example project with the PG the defines have probably been removed. Btw, automatically enabling defines from ofxImGui is not possible across all IDEs.

I'll improve the docs of the example, I'm curious about your thoughts on how to integrate this (or not).

ofxWinDialog: Looks quite similar to the viewports mode of ofxImGui, except the API is OOP rather then "pipelined".

[leadedge]

A new develop branch still adds new files and subsequent update/support requirement as well as inviting questions about the ofxImgGui addon itself.

Your fork is fine with the the additional files and example already there. I can just refer to that in the ofxNDI readme.

I found a few "gotchas" and you have clarified the problems. Your improved documentation would solve that.

ofxWinDialog is pure Windows. It avoids the complication of message handlers for a typical resource dialog. I created it for my own use but it's now open to share.

[leadedge]

I created a ofxImGui readme section with links to the required files. I believe they are correct but can edit as necessary.

[Daandelange]

Ok, thanks for integrating some links, that makes a good minimal non-instrusive solution.

But this way, people will have to switch between multiple ofxNDI addons, which often ends up in a mess and requires me to pull-in any update you commit to stay in sync. So I'll simply rename it to ofxNDIWidgets and make it standalone to solve these parts.

Thanks for sharing your insights again, it helps in setting up an ofxImGui community widgets workflow.

[leadedge]

That should work. There are only two files involved and the example can load the required addons. And you can create a specific readme. I will update the ofxNDI readme when it's done.