Browsing the new features because of SU2020, I just noticed that there is a “new” instance_method in the Ruby documentation.
Is this intentional? Was that there in the past? Does anyone know what this is? Or something will come…?
Looks like an error. There is no description of what it does, example or anything.
Yes
I thought it was still being updated.
I can imagine some potential …
6 Likes
We’ve requested them for like … forever. So don’t be surprised if, at the least, some testing is going on.
In the UI they’d be now called “tag groups”. (But the class names are not renamed in the APIs. Renaming would break code.)
Mainly they’d be an organizational aid, allowing sets of tags to be expanded and collapsed in the inspector list.
But also some users want each group to have a toggle that affects all objects that use it’s subordinate tags. That could be useful or cause confusion. But I’d leave it up to the users to find the best way to use them.
The main question I’d have is, would it be possible to have nested groups, should there be, and if so how many levels?
1 Like
If you allow nesting in the first place, I think it should be recursive to any level (well, it must fit into your computer memory). I think any choice of maximum nesting would be an arbitrary choice. There is nothing inherent about 3 nesting levels that makes it more logical than 4 or in 4 that makes it more logical than 5 and so on.
What is the max nesting level of groups or components ? It could be same for Layers/Tags…
But I believe, not need more than ~5-10, otherwise will be confusing even on the UI.
I can agree that it would look weird in the panel with too many nesting level and too much indentation, but in such edge case I think we can just allow it to look weird. I think most models wont use nesting at all, some will have one or two levels, a handful 3, som rare ones 4 and so on.
I think this is a good analogy. In some cases it doesn’t make much sense to have more than 2-3 levels, in others you can have 10 and that makes total sense.
The most extreme case I can think of right now would be someone building a set to photograph several products, including carpenter drawings.
Sections
A
B
Plan
Photography
Overview 1
Overview 2
Products
<some product ID>
Front
Side
Detail
Context
<some product ID>
Front
Side
Detail
Context
<some product ID>
Front
Side
Detail
Context
I’m sure someone could come up with an example where additional levels are appropriate.
1 Like
for historic reasons I think tag name length may cap nesting depth …
nested_tag_name = %w[Photography Products <some product ID> Context]
may_be_an_issue = nested_tag_name.to_json.length >= 60
I recall some sort of ‘MAX_LENGTH’ being hardcoded for javascript bridge ‘Generate Report’, ‘DC’ and others…
but, this could be poor memory on my part or something fixed with HtmlDialogs…
john
Except that tags are used for controlling visibility, and so each object in the rendering view must have it’s tag object checked for it’s visible? property. Any nesting adds a visibility tree which the rendering pipeline must walk inspecting “superior” tag visible? properties.
Keeping levels to some safe maximum may be desirable for rendering speed sake.
1 Like
While that is true such rule doesn’t have to be enforced by the software itself. Performance also suffers from a high polygon count but SketchUp doesn’t have a hard limit where it tells you you already have X polygons and thus cannot add more.
True, and I am always in favor of the user using software they way the wish and need.
1 Like
And as an update to this old topic, since this was discussed, version 2021 released with the concept implemented as Sketchup::LayerFolder class which holds the “groups” of layer/tags.
So it appears that the aforementioned “secret” #layer_groups instance method was part of a test of this feature that “leaked” out early in error.
The released feature uses a getter method named Sketchup::Layer#folder instead.
1 Like