I wanted to post these great, free resources from Automatic SketchUp.
These resources will help you learn:
automatic-sketchup_example_code.zip (230.8 KB)
Also, refer to this accompanying PDF. The goal of the PDF " is to explain how this scripting language can be used to take full advantage of SketchUp’s potential." Thanks to Matthew Scarpino from Automatic SketchUp!
Like @DanRathbun said:
That is a helpfull resource but is also necessary know a few particularities like described on following post:
@alex,
It is a great book, I was one of the testers [for mac compatibility]…
a few of the examples never worked on mac’s [i.e. they crash SU]…
some contain what is now considered ‘bad coding practice’ by SU and others…
unmodified, even more will fail in v14 and v15 on both platforms…
I have heard on the grapevine that Mat is considering an update as SU now uses Ruby 2 and we now have Extension Warehouse rules about coding practices…
maybe ‘Trimble SketchUp’ should extend an encouraging hand to Mat…
john
Thanks for your thoughts. This is definitely something we see value in and will keep you all updated with new resources.
Thanks,
AlexB
I hope so. That is my main beef with the book.
For the record, I never said ppl should not read it, just that it should be the last that they reference.
Just one word: invaluable!
Thank you very much for sharing, it will be of great help to anyone starting to learn Ruby in SketchUp.
I am a newbie to Ruby and can I say that this is the only reference that I have found that explains the data structures of SU in a way that is undestandable. Reading through the API documents is really no help at all.
I would be interested in which bits are not best practice as I am too green to know at the moment. Was it ever updated?
Do you have the accompanying PDF from the first post? If so, maybe you’d be willing to post it here?
This is probably the best it has to offer.
Not that I know of.
The API docs were mostly a programmer’s dictionary, not a tutorial. Ie, it was aimed at informing the experienced programmer of the API’s features (constants, modules, classes and methods.) So basically, you need to have a target object for what you wish to know so you can look it up.
But in recent years, more and more explanatory articles have been added to the API doc’s Files section. You can get there from the link at the top of the leftside navigation pane (that by default displays a list of the API classes.)
For some years the best practices for SketchUp extensions was only attached to the Extension Warehouse website. This separation caused these articles to be often overlooked by newbs wanting to write SketchUp extensions.
The most important part is the Technical Requirements section of:
https://help.sketchup.com/en/extension-warehouse/extension-development-best-practices
But in the last few releases this information was cloned over to informative article files within the API documentation proper (in what I think is a better understandable format) …
There are also some very helpful links at the bottom of this article page.
Okay, back to the subject of Automatic SketchUp.
What it mainly lacked was informing the reader that SketchUp’s Ruby environment is a shared process. This means that the number one no-no is modifying the Ruby core classes and modules. The second big no-no is modifying the SketchUp API classes and modules. Such modifications affect the extension code of all other authors and can (and have) created havoc.
The author of Automatic SketchUp, coming from another coding language, at the time likely did not understand that the interpretive context of Ruby is a “particular instance of Object called ‘main’”. [The “main” coming from the interpreter’s main() C function.]
Everything in Ruby is an object, and therefore is a subclass of BasicObject and Object. So this means anything defined in this interpretive context is defined within Object. So, for example, if you define a method in this context, it gets inherited by everyone else’s code objects, because everything is an object and therefore as subclass of Object. Same for constants. They become global.
Now the book was written and published in the Ruby 1.8 days. In more recent Ruby releases (late 2.x and now 3.x) there have been some changes to help prevent such global “muddying of the waters”.
But still, it is the author’s responsibility to “invent” for themselves a unique top-level namespace module name within which they should wrap all their code. Since it is likely you will be coding more than one extension, each extension should be in it’s own submodule to separate it from your other extension submodules.
The namespace could be your proper name, module GraemeRobinson, or a company name (provided you have a legal registered fictitious trademark, etc. Most jurisdictions do not make you register your own name for business purposes.) If it’s for hobby only, then sure you can use a fictitious nickname, ie: GreyCoder, etc.
In a nutshell, “best practices” is staying within your own namespace and not polluting the global Objectspace or SketchUp’s API objects with extension specific modifications.
Thanks for the update Dan.
I was aware of the need for a module(s) as I have read through the documents on Technical requirements and best practices before reading the Automatic Sketchup. I was also aware of the issue of the shared environment.
I suspect it may be a while before I ever get there!
I posted all kinds of Ruby help links in …
Thanks Dan,
I did find that post and I am working my way through them.
