I've never had any problem with CutList not working. I've used it for a number of years without problem. what do you mean by a rounding error? What dimension is getting rounded? Which version of the plugin are you using? As for the difference between "paint" and "material", I don' think there is any. I think they are used interchangeably although I suppose some would refer to simple solid colors as paint while a texture image might be referred to as a material. In terms of the cutlist and materials, you could use solid colors so as not to have to deal with grain orientation and give the colors wood names or whatever you like.

(1) If you are going to develop, logon as an admmistrator, so you have full access rights to the plugins folder. (Or right-click the SketchUP icon, and choose "Run As Administrator", or "Run with elevated Privileges" etc.) (2) Forget about zip & rbz during development, that is the avenue of distribution. (3) Stop thinking of SCRIPT, and start thinking of your code as being defined WITHIN and executing FROM your namespaces. You need to choose a toplevel namespace (module name,) and then write ALL of your plugins within a sub-module of your toplevel module. (Clarify: I mean each plugin has it's OWN sub-module of your toplevel author/company module. That way NONE of your plugins clash with each other, NOR any other author's plugins.) (4) BE wary of comparing Ruby to Fortran, BASIC, etc. Ruby is MUCH different. It is a dynamic language. This means that modules and classes can be modified at any time. Methods can be redefined, removed, access changed (made private,) etc. This also means you can reload a file that defines your plugin's module, after making changes, and the changed methods are updated. This is great for development. (5) Ruby is 100% object-oriented. Ruby has 2 (TWO) things. Objects and references that point at objects. Ruby does not really have variables, but the documentation and some query methods refer to "variables", but I think it is best to have programmers from other languages know from day one, that Ruby only has references, not variables like BASIC. For example, Ruby references can point at any object, at any time, of any class, and then be changed (re-assigned,) to point at any other object, of any other class (or perhaps the same class.) So any "typing" of reference names is only in your mind. It it makes you "comfy" to say use bMyRefName to hold a reference only to true or false (or nil,) then thats OK. Add (6) Read the "Pick-Axe" Ruby book cover to cover. (see the Ruby Resources sticky topic.) Doing so will make your journey so much easier, and avoid asking all the questions here that people who do not read the book first have already asked (here and in other forums.) (7) Do not think or write your code in a linear manner. Think in and write code in an event-driven manner. (Have your code respond to things the user does, or act upon objects the user has selected, or do something with the entity the user has just modified, etc.) See the API dictionary on all the observer classes.

@userquestion said: Dave, could you point me to the URLs for those videos? Try this one to start. @userquestion said: Looking at the before & after PNGs, the change looks like a. splitting it apart b. chopping off the right legs/apron c. copying the remainder and flipping it, and d. inserting an intervening area with top Not exactly @userquestion said: I was thinking more of a situation where I have, say for example, a breakfront/cabinet with drawers, doors and interior parts. I might want to massage it wider, and re-gauge the relative sizes of the doors and drawer fronts. Making the cabinet wider (if I am thinking this right) involves: moving the right end over; stretching all the intervening stretchers etc on the carcass and their stiles/rails; then playing with the drawers the same way. It just seems....ugly....to have to touch all that stuff. Another example would be a plain kitchen cabinet. If I wanted to stretch it (without changing the vertical components), I have to make lots of interior adjustments, frame adjustments, and drawer adjustments. And then, if I don't like the size, or need others, I have to repeat the whole thing all over again. Working out the workflow, or easier ways to maneuver the workflow, is my goal. I sense I am handy enough with the software, but this trick eludes me. Maybe after I look at your examples, I might catch a trick or two, new. I'm thinking, too, that I am wanting too much from the components behavior.... I don't find it "ugly" to touch all of the components. By going through the model logically I know when I get finished the model will still be accurate. I don't find it to be a problem at all. By correctly using components and nested components, it is all pretty easy even on complex models. I mentioned Dynamic Components before. They could be used but in order to keep tenons the same size while changing the length of an apron, the apron would have to be made of three separate parts. The tenon on one end would get moved while the center section would get scaled. The downside is a cutlist would be full of garbage dimensions. And DCs aren't quick to make. I can easily modify an entire model before I could make the DCs to build the model in the first place.