It looks the provided ObjectEditor creates a kind of Object Graph internally to apply the changes on the desired part of the Channel.
Basically what @sebescudie is asking in this post:
I have done that before creating my own model Tree with all the property paths, and then i can do certain operations On Hovering the widgets… but it’s too hacky and creates some UI problems.
I was wondering if there is an elegant way to get the value path that specific Widgets are writing on.
My idea is to bind properties with timeliner tracks using the provided ObjectEditor, without to crawlling the properties manually or reinventing the wheel.
Has anyone any idea about how to do it?
A start point?
It would be a killer feature to have a deeper integration of channel reactive in ImGui’s Object editor.
I would love to do the data binding directly in the inspector, having an extra window with a long list of names is not the most intuitive way to operate.
Sorry for not replying earlier. Had a quick look into the way the object editor is currently build and it doesn’t deal with paths at all. Yes, it builds up an internal representation of the object graph it’s pointed at, but so far this is not done via also building up a string representation which would be usable by a node like Select (ByPath). This would need to be added to the tree build-up. Question then is where to make it available? @sebescudie only asks for a “button” to copy it in the editor UI - would that still apply?
Thank you so much Elias, any advance in this direction is welcome.
For my specific needs i would say that an output pin with the path as string would be great, and let the user decide to activate it or not.
You mean output pin on ObjectEditor? But wouldn’t that be pointless because it’s always the empty string / root? It’s about the internal representation is it not? And if that’s the case, we can either pass the path down in the context used during build-up of editors, or make it part of the object editor interface (would like to avoid that if possible).
Let me explain the way we use this feature using Elementa.
We use the attributable feature provided and inject manually the property path for each specific widget, using a custom AdaptiveObjectEditor where we can access to these paths internally.
On hover a widget we get the previously injected Path as attribute, in this way we just right click and display a context menu with certain data binding operations.
In Imgui ObjectEditor context, there is no way to know wich widget is hovered, only if the ObjectEditor itself is being hovered.
Ideally, when i hover any widget shown in the ObjectEditor, we should know which widget is hovered, providing the path, an ID or Index we can use afterwards in order to filter the exact “full property path”.
Example:
Record with several properties.
We get all property paths using any method.
Connect the record to ObjectEditor.
ObjectEditor provides the Hovered Widget ID.
Using the ID we get the exact property path.
The way you expose this parameter is on you, as soon we can overcome this limitation.
Not sure, but to me it sounds like a case where you do want to have your own ObjectEditor - or in your words: you do want to reinvent the wheel.
Why? Well, just to be as flexible as possible. In your position, I’d use ObjectEditor only for the individual properties. This way you have control over your UI & functionality.
But unfortunately using this method is quite hard to create complex type editors with tables and tabs.
And even harder to invite other users to create their custom editors for Interpolator.Addons.
@Elias What do you think? is it possible to find a compromise between reinventing the wheel and something usable keeping the ObjectEditor mechanism and user customization?
Thanks for the patch @gregsn, always helpful to have something concrete to play with. I think once we add the path to the ObjectEditorContext it should be possible to build a custom IObjectEditorFactory which injects logic feeding for example a channel with the path of the active hovered item. Adding the path would be on our end, building the custom factory with the logic you need on yours / users end.
