Installing and Signing developed RBZ

@marcosyu, please read …

Correction. This is the registrar file. (The file that registers the extension with SketchUp’s ExtensionManager.)

The loader is the file specified by the 2nd argument to the SketchupExtension class constructor.
(Ie, it is the file that gets loaded by the SketchupExtension#load private method, and in turn has the job of loading the rest of the extension’s files.)

Marco stressing that you need set Loading Policy as TIG describes to test unsigned extensions.

Marco, I know this is a test, but you should start off using good habits.

Each extension developer needs to “invent” a toplevel namespace module that is unique, Ie the company or author name.

Then within this namespace the developer will define numerous submodules, one for each extension that they create and perhaps some common library submodules and classes.

Absolutely no custom classes defined in Ruby’s toplevel ObjectSpace.
The one and only toplevel module you create should be a unique namespace module.

Both your registrar file and your extension subfolder must be uniquely prefixed

# encoding: UTF-8
# File: "MarcoSyu_MyApi.rb"

module MarcoSyu
  module MyApi

    ex ='MarcoSyu: My API', 'MarcoSyu_MyApi/main')
    ex.description = 'My API is a nifty extension that does nifty things.'
    ex.version   = '0.0.0'
    ex.copyright = '©2020, Marco Syu'
    ex.creator   = 'Marco Syu'

    Sketchup.register_extension(ex, true)


So you see (above) that the registrar file has the same name as it’s extension subfolder, … which is "MarcoSyu_MyApi" in the example.

You can choose some other unique namespace name, … a company, a tradename, etc., … whatever you desire as long as it does not infringe some other entity’s trademarks.

Then all your other extension files will look similar to the above. They each must be totally wrapped within the namespace module and extension submodule …

# encoding: UTF-8
# File: "MarcoSyu_MyApi/main"

module MarcoSyu
  module MyApi

    # Load other extension files ...
    Sketchup.require( File.join(__dir__,'actions/process_square') )
      # ... etc, etc ...
    Sketchup.require( File.join(__dir__,'ui') )


… and the (usually last to load) "ui.rb" file …

# encoding: UTF-8
# File: "MarcoSyu_MyApi/ui"

module MarcoSyu
  module MyApi

    # Load only once ...
    if !@loaded
      @loaded = true

      @options = { # hash of options }
      @dialog =
      @toolbar ="SomeName")
      # Define UI::Commands here ...
      # Define a submenu here ...
      # Add commands to menu items here ...
      # Add commands to toolbars here ...

    end # load once


There is no good reason for an extension to ever have any code evaluating outside it’s namespace module or extension submodule.

You have …

    attr_accessor :toolbar, :dialog

… which likely is unneeded. Your extension doesn’t need accessor methods to access these references. Accessors are for accessing from outside the module or class. Since your extension can directly access the @toolbar and @dialog references, there really is no cause for creating accessor methods.

1 Like