Extension Architecture


#1

Hello, I have been using SketchUp for quite some time but only recently got involved in plugin development. I am wondering how you guys structure your plugins, I have noticed that many plugins are built with a “controller” ruby class and an accompanying folder with the rest of the classes and assets, even though for more basic plugins it is possible to load all of these assets directly with one .rb class and place that in the SU plugin directory.

If you go by the class and folder method what do you have your controller run and what do you put in the folders. I have found a lot of different methods for architecting plugins and I would love to hear what your guys favorite methods of plugin execution are.


#2

We have been discouraging the single rb directly in the SU plugin directory since around v7 and more strongly since the Extension Warehouse came online for v2013.

So, the only file of your plugin set that goes in the SU plugin directory, is the SketchupExtension instance registration script. This allows the user to switch the plugin off or on in the Extensions panel of the Preferences dialog.

All other files, button images etc. should go in the plugin’s subdirectory.

The extension registration script and the plugin’s subdirectory must share the same name, and should be your toplevel author (or company) module name + “_” + the plugin name (often an exact match for the plugin’s submodule name.)

Let’s say your plugin was called DeckWizard, and all your various plugin modules are inside a toplevel module named “Chickering”. The name of the extension regisration script would be “Chickering_DeckWizard.rb” and it’s sub-dir would be “Chickering_DeckWizard”.

See the API’s SketchupExtension class:
http://www.sketchup.com/intl/en/developer/docs/ourdoc/sketchupextension

Updated with newer more detailed requirements from:
http://extensions.sketchup.com/en/developer#developer-guidelines
… especially under “Packaging”

The #1 rule of extensions, regardless of any examples your may come across, is, that there is never any good reason for a plugin to have any code evaluating outside it’s plugin sub-module (which should be inside your personal unique toplevel module.)

I say this because the examples in the API documentation are only the “meat” and are shown unwrapped in any module or class namespace.


#3

For the Extension Warehouse we have some formal requirements - you probably want to check them out:
http://extensions.sketchup.com/developer

We need to improve our guides and examples to make best practices more clear.

Until then - have a look at some articles I wrote some years ago:


The gist is:

  • Implement the SketchupExtension interface (Defined in the “root RB file” - loading another RB(S) file in a support folder with the same name as the root RB file)
  • Wrap everything into a unique module namespace. Recommend a root author module in which you then add a module per extension.
  • Never define global code (constants, methods etc)
  • Never modify code outside your own namespace (like Ruby core classes and SketchUp API classes.)

#4

Thanks guys, these are exactly what I was looking for!