search

Daandelange / ofxImGui

Please refer to the develop branch in https://github.com/jvcleave/ofxImGui. I'll keep this fork in sync until it's merged in master.
12 stars 1 forks source link

Updating to imgui 1.80 #7

Closed Daandelange closed 1 year ago

Daandelange commented 3 years ago

1.80 depreciates the original jvcleave/ofximgui interface. In this fork, I made the OFXIMGUI_ENABLE_OF_BINDINGS compile flag to let people use Jason's "legacy" code. In fact, updating ImGui will depreciate the associated code; it won't work. And as this fork probably won't get merged into the original addon, I'm thinking about removing that flag completely, obliging everybody to use the native DearImGui backends. (I'll park current progress in a legacy branch.)

What do you think ? Sounds legit ? @moebiussurfing

thomasgeissl commented 3 years ago

great. i would love to see imgui updated to >1.80. I am using 1.82 in one of my projects, I needed the new tables api. not sure how much has changed between 1.80 and 1.82, but you could consider updating 1.82. I would assume that there were some bugs introduced with the new api.

Daandelange commented 3 years ago

Yes, when updated, i'll take 1.82+ directly. 1.80 is the problematic one. The "legacy backend" bound to oF events will disappear. The new one directly "talks" to the same GLFW instance as oF, but is not bound to oF.

thomasgeissl commented 3 years ago

ah great, thanks for explaining. in my opinion, as long as it is documented and properly versioned then it is okay to get remove the flag and introduce a breaking change.

moebiussurfing commented 3 years ago

@Daandelange ,

IMHO there's no problem at all updating our "old apps" to make compile them again. No problem to split legacy. Just to change the gui.setup(.. , the flags when you pass group params, etc... does not sound too much work. ImGui it's awesome and very powerful to have all the features, community widgets, snippets...etc up to date.

(When you mention the ofEvents I thought could be something about the keyboard, mouse, etc that we can do in other ways.)

( I just remember the pain to update ofxAddons / ofVec3f to glm::vec stuff compared to this ;) )

Awesome work @Daandelange. Cool that jvcleave replyed.

PS: https://forums.cockos.com/showthread.php?s=5f0d6466cd8f12b93cccd0642ced6289&t=250419 It looks that Reapear supports developing plugins GUI with ImGui. It's curious. https://github.com/cfillion/reaimgui There's a screenshot from your Mosaic posted below...

Daandelange commented 3 years ago

Ok, so probably stripping legacy stuff out, right before the imgui 1.80+ update, documenting the change in behaviour. Older versions will always remain available for special needs.

(When you mention the ofEvents I thought could be something about the keyboard, mouse, etc that we can do in other ways.)

Well, not really. To be double-clear, it still changes how imgui is iterfaced. "Legacy" refers to the old "oF custom backend"; "not legacy" referring to the new "native glfw backend". In legacy, oF is bound to GLFW and emits ofEvents when GLFW triggers oF. Now ImGui directly gets (a copy of) the GLFW event. I'd expect at least a change in the order of call (imgui getting mouse events after/before oF-bound mouse events), but nothing really noticeable, specially for regular use cases. It could be worth doing some tests on these grounds for future updates. I don't even know if oF or GLFW events can be intercepted, bubbled, etc..

Daandelange commented 3 years ago

To give an update about this, ImGui is now 1.82 and OFXIMGUI_ENABLE_OF_BINDINGS related code has been stripped recently. I'm on some final cleanups and testings before pushing this to jvcleave/develop for more testing. Non-GLFW-window-projects can use older ofxImGui releases, and GLFW seems to be(come) oF's preferred Windowing system on all platforms.

Daandelange commented 1 year ago

An update on this: