I’ve just published a small Ruby Extension that counts the area of each material in the model. This is already a feature in SketchUp natively so it might not be the most useful extension.
However, it serves as an example for how the SketchUp DOM can be iterated (sometimes referred to as “drilled in to”), how to keep a reference to the local transformation and some other things. Hopefully it can be a useful resource for extension developers out there!
Very good example, and an introduction to recursion and tree traversal!
Same principle was also applied in my texture resizer to compute the average resolution of each texture.
I’d have to say “hands down” that this example is better than the “Team” example named “attributes.rb” in the Ruby Examples extension. Although the old example attempts to show the use of attributes for a good cause, it fails IMO. (It also only works at the model top level.)
Perhaps the calculation of material costs could be “borrowed” (in a better way) from that old example, and added into Julia’s example ?
I didn’t even know Trimble had made such an example extension.
I think it’s in general quite hard to navigate among the examples as they are so spread out (some in the API docs, some on GitHub, some in EW), and they sometimes have similar names so you think it’s the same example when it’s not. Another problem as I see it is that there are example extensions that consists of vastly different features all squeezed into one extension, instead of letting the examples better resemble actual extensions.
Once I found the attributes example I think you are referring to (Extension | SketchUp Extension Warehouse) I was quite chocked to see the global variables in it. The code style is also rather unusual (4 space indentation, missing parenthesis around arguments, ‘not’ instead of !, wrapping spaces inside ( ), no wrapping spaces i side and before { } among other things). I’m afraid new developers could pick up some rather nasty habits from this example so maybe it’s a good thing finding it wasn’t that easy. Maybe it would be even better to hide it away from public consumption completely.
Regarding incorporating attributes to this example I think it goes against the principle of having each extension doing one thing only. Especially for examples I think it’s good to take small steps and show as few new things in each example as possible. Of course another extension could be forked from it and re-use the DOM traversing code to read attributes and generate a report.
Totally agree. I gave up screamin’ about this several years ago, when it became clear they will not spend the time or money to clean these up.
You misunderstand. It’s not teaching attributes I proposed. (I said “in a better way”.) My point was that costing goes hand in hand with tallying area. Tiles have an installed cost per square unit. Same for flooring, shingles, paint, siding, whatever.
If you wish to find another way to store material costs then attaching attributes to materials, then fine with me. (Besides it seems there was a bug in older versions that the attributes did not get stored in SKM files. This was fixed but not very long ago ?)
But if you think it too much work, or if it will confuse this example, then how about a new example that leverages the other by using it as a library ? (You did define the methods as singletons so they should be callable from outside.)
My point is that it would confuse the example. There are lots of extra things this extension could have done, e.g. display the output as a table in a web dialog or exported it to a CSV file. However keeping it to a bare minimum makes it easier for new users to grasp.
Including this as a library or dependency could also be a bit messy and hard to understand. However forking the project and make a separate extension could work. That could be though of as the follow-up lesson to this one.