For some additional context, what I’m building is essentially a linear
AudioProcessorGraph fronted by a
TabbedComponent. Each tab represents a processor in the chain from left to right, with the tab’s component being the editor.
I’ve implemented tab reordering via dragging as the method by which the user can rearrange the graph by reordering the tabs (all the connection breaking/re-forming is handled internally). The tab re-ordering should trigger the graph to update in a “the user made something happen” fashion so it can update the stored properties in the graph (currently just the linear index used for the node’s “order” in the linear graph).
Since the rearrangeable tabs employ things like animation, snapping, and other visual aesthetics I was trying to shortcut controlling the entire visual behavior of the tabs in a manner similar to the plugin host where a full User -> View -> Update Model -> Update View happens, instead doing User -> View -> Update View + Model since any tab arrangement will never be invalid. I feel like the
Tab* classes are very resistant to adding direct interactive editing capabilities, so neither approach is easy to do.
I totally see what you mean by the
Tab* component family being oriented around reacting to a model change rather than triggering a model change through user interaction just from looking at the API, but in my case it’s the opposite from the way the
Tab* classes were designed I guess. If you have any suggestions on how to restructure things I’d love to hear them.