Thanks Daniel, yep it’s just when I’m swapping out the two components during teaching. I suppose in theory I should be using entwine always, so it’s just one of those things. Some of the students approach K2 before really understanding trees to be honest, which is why this situation occurred.
With regards the geometry, sounds like a good idea (at least to me!) and a little more intuitive than using the show component - I guess that’s why it’s been in your thoughts. Of course so long as it doesn’t introduce any more spaghetti upstream, but I can’t see that it would as you could just entwine/merge geometry as is currently the case to keep the definition clean.
Personally, (and disclaimer: I don’t know the full repercussions here!) it feels like it should probably be ‘all in’, in the sense that if you still had components that previewed geometry independently of the geometry inputs it could get confusing. I’m thinking here in terms of Karamba, where there is a clear workflow from geometry → physical properties → solution/analysis. The adding of physical properties (or goals) doesn’t preview geometry up or downstream, this enables latter components to handle the display, such as previewing deflections, forces, etc. which may be something you’d like to do with K3 in the future, at least with the GoalOutput data? Default would of course just to preview only the geometry that finds its way to GeometryOut. The question as to whether points are displayed by default, probably 50/50 on that one.
Zoomable inputs also sounds nice. The danger is of course the component grows really large for some users, so perhaps there would be a cap in terms of numbers of additional inputs? (if that’s even possible). Overall though, definitely a good move away from the show component at least in my humble opinion!! Thanks for reaching out. Hope you stay well, hopefully there should be a chance to meet again soon.