Adding spec_03 #2
Conversation
| Every child should know what figure it belongs to. | ||
|
|
||
| ### Proposal | ||
| Every object in the figure hierarchy should have a `.root` property that returns the top-level parent figure. A deeply nested child object would not return its immediate parent, but the highest-level parent it is aware of (which may be its parent, grandparent, great-grandparent, etc., depending on how deeply it is nested). If the object doesn't belong to a figure then it should return `None`. |
There was a problem hiding this comment.
I thought I posted this in the old PR, but can't find it now. Is it possible that a child has multiple parents? A data element that is shown in two or more "views"? Should this be allowed? If so, should .root be a list?
There was a problem hiding this comment.
Is a "view" equivalent to a figure? Semantically it seems that you should be able to view the same figure over and over again.
There was a problem hiding this comment.
Hm good question. Forgive me if I'm confusing too many out of scope topics, but a Figure could have multiple axes (sub-axes), and these could potentially be looking at the same "thing". You could also have two figures (ex. two separate GUI windows) that are displaying the same "thing". If the library supports sharing drawn elements in this way then a child could have multiple parents and therefore multiple root Figures.
There was a problem hiding this comment.
I have been thinking about this in terms of a figure component (something like a colorbar). I don't imagine data belonging to a figure in the same way. Do you have the concept of a figure component that is in two different figure objects (as opposed to two different views of the same figure)?
It doesn't seem unreasonable to me that such a thing might exist. I just want to be positive that it does, before changing the root to return a list. Lists that almost always have a length of one drive me crazy :)
There was a problem hiding this comment.
So if I think in terms of vispy, my answer is a little weird. Vispy can structure something as two "views" of a single "graph" of visual elements/components. These "views" can have cameras attached to them so you can have one view that you can pan/zoom in 2D space and another view that you can rotate around in 3D space or maybe another that is static. At least this is the idea. I have never actually done this in my own work, but the logic is there.
When vispy was first being developed it also allowed for these visual elements/components to have multiple parents. So you could have two "graphs" of visual/elements with any number of the elements being shared between the graphs or not shared. This functionality was dropped at some point because it made other features harder to implement, but there are still example scripts sitting in vispy's repository that try to take advantage of this.
So the usual case (99%) is that you have one graph with one root. That doesn't mean you couldn't have more. I could also see someone arguing that maybe the data is shared between a multi-figure setup, but the visual component representing that data is not shared. This is an implementation detail though.
I'm not sure it is worth it to worry about the complexities of this right now. That said, if handling a list of a single element (I hear you, it is annoying) doesn't make things too hard then maybe it is good to future proof?
There was a problem hiding this comment.
Given the discussion above and the earlier one about these topics in PR #1, I think spec_03 does not represent universally agreed upon, broadly useful functionality in the same way 02 and 01 do. So I vote against including 03 in the spec; it seems like it opens up more problems than it solves.
I am separating this out into a different PR so that it can be discussed separately as per @jbednar's suggestion