[Template] for Basic SketchUp Extension

Basic SketchUp Extension Template

Basic.zip (2.6 KB)

Change module name “Author” in the template files to your own unique top-level company name, brand name, initials, or online nickname. (Do not use some other entity’s trademarks, salesmarks, brandnames, patented names, etc. Ie, do not use “Sketchup” or “Layout” in any form, in any case combination, with or without appended or prepended words.)

Change the “ThisPlugin” sub-module name (in all files,) to the name of your particular plugin.

Save your template as encoding UTF-8 without BOM (Bit Order Mark.)
It is also recommend that Unix type end of lines be used. (Although some prefer Windows EOLs on PC because snippets can be pasted into the Ruby Console and line breaks work. Snippets with Unix EOLs will not line break in the PC console. I personally have only the little snippet files in my “Snippets” folder set to Windows EOLs.)


1 Like

Do you have recommendations for wrapping functions in a “base module” that can be used by different plugins from the same company?

The only “base module” the company should ever create, is it’s toplevel company namespace module. All library modules and extension / plugin modules should be in some nested hierarchy inside the toplevel company module.

The organization of the library namespace hierarchy(ies) is up to you. For a good example, see Thomas Thomassen’s TT_Lib2 library he uses with many of his other extensions:
TT_Lib2 library at BitBucket

The other template example shows the sharing of a constants sub-module using include().

Because include() and extend() mix different kinds of “fundamental” objects (ie, method, constant, module_variable, etc.) into target modules and classes differently, I always recommend (when possible) to use separate mixin modules for adding / sharing these different objects to other scopes (ie, modules and classes.)

For example, put constants to be shared in there own library mixin module, module/class (@@) variables in their own mixin module, and methods in there own mixin module. Actually, you are likely to have several mixin modules of methods separated by category. (Like thomthom does in his TT_Lib2.)

This way you only need contemplate how that one object type, say instance method (for example,) will be mixed into the target object (ie, as an instance method or singleton method,) and what the resultant accessibility will be (private, protected or public.)

Otherwise, if you have more than one kind of thing in the mixin module, you’ll need to refer to a complex before & after table with object types, before accessibility, after types, after acessibility, taking into account whether the target is a class or module, and then that is just one half of the table for include(). The other half does all the same again for extend(). (This table is not anywhere to be found. I had to make up my own, but it is on an old computer I have not started for over a year.)