Request: calm down TreeItem

Replies to This Discussion

Permalink Reply by Luis Fraguada on January 25, 2013 at 7:56am

While you are on the topic of TreeItem, could we also have it Maintain Paths as does the TreeBranch component?

Permalink Reply by David Rutten on January 27, 2013 at 12:58am

Orange is the best I can do I think. There should be at least a warning if you're trying to access unset elements of lists and trees. But even that I find somewhat odd, this is clearly an error in that you're trying to do something which is not possible. Some solutions spring to mind other than changing the messaging behaviour of the Tree Item component:

• Have an option for all objects (not just Tree Item) that allows you to disregard warning and error feedback. Sometimes a component has warnings (or indeed errors) and yet it still functions as planned. This often also happens with auto-casting, for example if you're trying to find all the curves in some data. Pros: solves the same problem in the same way everywhere, Cons: yet another menu item and yet another thing to watch for.
• A global switch that disables the warning and error colouration. Pros: easy fix, easy unfix. Cons: if you also disable message balloons then you can't see where errors are happening.
• Add a component which filters valid paths and item indices which you could insert in front of the Tree Item component. Pros: a very Grasshopper standard solution, Cons: yet another esoteric component.

I've been thinking about changing the way branches and items are accessed. Basically wondering whether it makes more sense to combine the tree path and the item index into a single data-type "{0;0;2} (0 to 9)" which defines both the path and a range of items in that path. It could be made to work almost identical to current Tree Branch and Tree Item components but it could also do some other cool stuff in addition to that. For example you could have:

• {0;0;1}                which defines all the items in that branch
• {0;0;1} (2)           which defines the third item in that branch
• {0;0;1} (0,1,2,4)   which defines the first, second, third and fifth items in that branch
• {0;0;1} (0 to 4)     which defines the first 5 items in that branch
• {0;0;1} (!3)          which defines all items except the fourth in that branch

And I'm sure people can think of even more combinations of symbols and numbers that can be added. Most of this logic is already in place in the [Replace Branches] and [Split Tree] components.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by phillip on January 28, 2013 at 8:07am

The solutions to suppress the error are a little scary. I can imagine getting quite confused going through definitions and tracking down errors with supressed warnings. And in general I think they are a great help and I would not want to miss this for aesthetical purpose. 

For the solution with the esoteric component, I think we already have it

(actually the first time I ever used BranchCompare):

So Intention of this request was rather to include the above shown strategy into the component already, rather then an error message suppression.

I have to say, since often forget about TreeItem when dealing with branches only, I really like your Idea of combining the two. It could work just like TreeItem right now, with the difference, ,if  there is no item defined it would take the whole branch. With the strategy you described above, I think it can become a powerful component and make others redundant.

For what you say, Orange is the best I can do I think , I don´t really understand.

Because the same thing does work with other components without a runtime error:

With Luis´request - I fully agree. I even think it makes sense on some of the Tree Components (esp. TreeItem, SplitTree, TreeBranch)  to have the ability to switch from maintain Paths to maintain Tree of Path List, like Chissi did this for Tree8.

On (maybe even all) other components, I think, they should be set with default of maintain paths. I can´t  think of any case happened to me, where I would have needed the other way around and it was not possible to achieve matching by just flattening.

Thanks,

Phillip