Details

This page only contains summary notes; see the SketchApps code for the implementation details.

Constraints

SketchUp's Extension Manager (EM) is designed to manage individual extensions. It can install or remove extensions, enable or disable them, etc. However, it does not have any notion of integrated sets of extensions.

So, any extension sets that SketchApps creates (eg, Product Connect) must appear to EM as if they were single extensions. At the same time, they need to manage collective resources (eg, Menu Bar items), communicate with each other, and so forth. Also, the Extension Framework (EF) needs to be able to interact with both extension sets and individual extensions.

There are also some tricky issues regarding namespaces, etc. For example, to minimize the chance of collisions with other extensions, EF keeps its "footprint" as small as possible. Specifically, it uses only a single global variable ($sketchapps_state) and no global constants. For more information, see Naming Issues.

At the same time, EF needs to allow developers to run multiple versions of extensions, without fear that they will collide with each other. So, for example, it shouldn't be a problem for a developer. Reconciling these constraints is possible, but not always pretty. However, EF shelters users and developers from most of the mess.

Approach

EF approaches these constraints by defining "Extension Sets" (ES). Each ES is implemented as an anonymous module with its own resources. Communication between ESes is enabled by a shared global hash ($sketchapps_state).

Extension Sets

Each Extension Set (ES) manages a corresponding set of resources. Some of these are visible to the user, but most are not:

  • Anonymous SketchUp module, class variables, etc.

  • Directory tree (eg, "SketchApps_dev/CFCL/Public/...")

  • SketchApps loader and (placeholder) plugin scripts

  • SketchUp resources:

    • Menu items (eg, "Plugins > SketchApp (dev) > ...")
    • Session configuration and state ($sketchapps_state)
    • Toolbars, Tools, etc.

Anonymous Modules

Each ES is started up and runs in an anonymous Ruby Module. This largely protects it from collisions with other Ruby code. The relative file path for the ES's directory tree is used as the top-level key in EF's shared global hash ($sketchapps_state), eg:

  rel_path = :"SketchApps_dev/CFCL/Public"
  @ss = $sketchapps_state[rel_path] = {}
  @ss[:admin] = {}
  @ss[:admin][:module] = self (?)


This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r3 - 23 Apr 2013, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email