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.
@lasal
I am getting back to you to tell you that your request made me do some research - in avoidance of the term rabbit hole… Research, that might not address your specific request, but instead could just be seen as something that allows us to explore the design space together in a broader way.
In my view the topic ObjectEditor has a huge design space, but up to now, it’s all hidden away in a black box.
I can imagine that some people prefer different spread editors than others or prefer simpler or more sophisticated options for instantiating objects (and subtype selection).
But also, from a pure design perspective, some might want to put everything into a table layout as known from the global channels browser, where the structural info and the values live in different columns. Others prefer the current presentation. Or come up with a completely different way of presenting the structure.
And then there are those that want to use it in their app and others that want to extend vvvv and let the Editor run our UI thread, which surfaces synchronization topics.
I always understood that people want to have a say in their systems and that’s why I opened this black box a bit for those that don’t think in C#. Let me be clear: I don’t advise you to use it as is, but rather allow you to play with it allowing us to explore the design space together.
For me, part of the motivation was to make my hands dirty and test our language features, our compiler, or the robustness of the runtime and test my puzzle-solving capabilities - sort of an advent of ObjectEditor. On the way I tested our different APIs touching topics like
“adaptive process nodes”,
turning those into dynamic process nodes,
types of channels, properties, and spreads versus types of the actual objects living inside those channels, properties, or spreads
vl defaults versus .Net defaults.
But of course, I hope that this can also help improve the understanding of what’s needed regarding ObjectEditor.
The patches are not completely tidy and still have some artifacts and comment regions of previous approaches. I will not try to explain everything in advance, as it’s too much. But please feel free to ask questions regarding those patches.
Join us for a chat
Open sources of vvvv on GitHub
Follow our news on Mastodon
Follow a shared screenshot gallery on Pixelfed
Do big business on LinkedIn
Watch tutorials on YouTube
Join and organize meetups on Mobilizon