Distributing Your Plugin

The work of getting your plugin out to the world can be as simple as posting it on your website for download or as complex as generating cross-platform installers, documentation PDFs, etc. etc. In this tutorial we'll walk through a few steps to consider.

Step 1: Clean up your code

Keep in mind that users who will install your SketchUp plugin probably have installed other SketchUp plugins. Check your code for any potential problems that might occur from collisions with somebody else's code.

1. Try to know what others are doing/have done. This isn't always easy, but some research and questions go a long way in avoiding conflicting class/method names. It can also prevent you from duplicating someone else's effort - why re-create method x when it's already been written? Just tap into it and go (with permission, of course). Look for public scripts that are doing similar things to what you're acconplishing, and consider working with that author to cross-promote your tools. Sometimes, the already-written code won't do exactly what you want. In that case, you can either subclass yours and modify the methods (for classes, obviously), or write your own using a different class/method name.
   
   
2. Try to use unique names rather than common ones. For example, if you write a "ProgressBar" class, you will cause conflicts with any other "ProgressBar" class. That will make for unhappy users, as they try to get tech support for something the author says works just fine on his machine, but clearly won't work on their machine; and will make for unhappy fellow developers, who have to hunt down the conflicting script, locate the author, and try to work out a solution. Better to do something like "mskp_ProgressBar" which is unlikely to collide.
   
   
3. Encapsulate methods in a Module or a Class. Within a class, you don't have to worry about method naming conflicts, and within a module, you can be less careful about both class and method names.
   
   
4. Test your work against as many other works as possible, and test them against yours. Unfortunately, the burden of compatibility will more than likely fall to the second developer. However, if you send your script to other developers asking them to test for compatibility with their works, they'll most likely be happy to oblige (subject to their own time constraints, naturally). This will help keep the user experience (and your reputation) positive.
   
   
5. Be respectful of the Plugins directory structure. If your plugins has a lot of support files (piles of .rb files, html file, image files, etc.), group them together into a subdirectory under the Plugins folder. This will make it easy for users to identify (and potentially uninstall) your script. It will also make it less likely that your "cursor.png" will by overwritten by someone else's "cursor.png".
   
   
6. Document your code and include contact information. Write generous comments and include a header block at the top of your scripts that tells people what is included with your Plugin, what it does, and how to contact you in case of upgrades or bug reports.
   
   

Step 2: Decide if you want to scramble your code

It is your responsibility to determine the license under which you want to release your Ruby plugin. Since Ruby is an uncompiled language, releasing your raw source code to the world may not be attractive to you.

Fortunately, the SketchUp SDK contains the free Windows-based Ruby Scrambler program which can obfuscate your ruby code from legible script...

# First we pull in the standard API hooks.
require 'sketchup'

# Add a menu item to launch our plugin.
UI.menu("PlugIns").add_item("Camera: View Top") {
  Sketchup.send_action("viewTop:")
}

...into encrypted gobbledeegook...

RBS1.0Uoi�?g�TH��!X0K4�;̋zb��~E�Hq�'qL�Z�0�g���%
�lݡ\�%�a1�s���:wF�231&��o�����(�3חL�Z2�0�g�231
Uoi�?g�TH�31233�!X0K4�;̋zb��~E�Hq�'qL�Z�0�g��o��

Your code gets decrypted by SketchUp at run time and runs exactly as the original script, but it makes it somewhat harder for 3rd parties to read your code. (No encryption method is perfect, however, you should also protect your IP with the usual methods of copyright, licensing, patents, etc.)

You can download the SDK by filling out this simple form.

Running the scrambler

1. Download the SketchUp SDK. (You need a windows computer to use the scrambler.)
2. Unzip scrambler.exe onto your harddrive in the same directory as your scripts.
3. From the command line, run scrambler.exe, passing it a list of the .rb files you want to scramble.

   c:\Program Files\Google\Google SketchUp 7\Plugins> scrambler.exe myscript.rb myloader.rb
   

    

4. This will generate a series of files, each with a .rbs (scrambled ruby) file extension.
5. These .rbs files will load and run in SketchUp just like .rb files, with the exception of any commands that explicitly load .rb paths. For example, if you code uses the require command to pull in subfiles, you should call Sketchup::require, without the .rb file extension. This command is smart enough to load either .rb or .rbs files with the same base file name.

   # Bad. Assumes .rb extension:
   require 'myclass.rb'
   
   # Good! Will load myclass.rb or myclass.rbs:
   Sketchup::require 'myclass'
   

    

Step 3: Get it out there!

You can host and promote your plugin on your own website or e-commerce portal, or you can sign up to an existing repository. See the FAQ section for a list of SketchUp plugin sites.

Before you release it widely, however, it is a very good idea to invite a beta testing group of fellow plugin authors to do some testing and provide feedback. The SketchUp ruby community is very friendly and accessible to even the most novice of programmers. Make a post to one of the user groups and get to know people! Your script will be better for it. See the FAQ section for a list of the SketchUp Ruby user forums.