Plugin recommended practices
-
# encoding; UTF-8 #{ ========================================================= # Documentation block ... #} ========================================================= require 'sketchup.rb' module Author module ThisPlugin # CONSTANTS defined here # Module @@variables defined here # Classes unique to ThisPlugin defined here class << self def init() # define instance @variables here end # def plugin methods here end # proxy class # Run Once at startup block here; this_file = Module;;nesting[0].name <<';'<< File.basename(__FILE__) unless file_loaded?( this_file ) init() # call the init method if needed # define commands, menus and menu items here file_loaded( this_file ) end end # plugin module end # toplevel module
Are sketchup.rb and extensions.rb still required for SU plugins? What does init() help with? And what does a singleton class give us since everything is inside a module?
-
That is the sample file I posted over at the sketchup.com forums, I think.
"sketchup.rb"
Therequire "sketchup.rb"
is only needed if you call any of the methods defined in that file. Since SketchUp 2014 the "Tools/sketchup.rb" file is loaded automatically before any plugins ever get processed. So the actual require call is frivolous, but some documentation generators use it to list dependant files. (So it is still good practice.)
In this case, the global methods usedfile_loaded?()
andfile_loaded()
are defined in "sketchup.rb", so I added therequire "sketchup.rb"
call.
But you can create your own editions of similar methods within your own author module, or plugin module, or a custom mixin module (within your author module,) that you caninclude
in any of your plugin sub-modules.
In other words, I encourage becoming independent of "sketchup.rb", as it's fixes are long overdue from being added to the API, in the correct modules or classes.
"extensions.rb"
Yes "extensions.rb" is still needed. But the file above is a simple template of a "core" plugin file, that resides in a plugin sub-folder (or the "Plugins" folder,) which gets loaded by an extension registration script (which resides in the "Plugins" folder.)
For an example of the registration script, see the API'sSketchupExtension
class:
http://www.sketchup.com/intl/en/developer/docs/ourdoc/sketchupextension
Anonymous Singleton Proxy Class Instance
The proxy object, in this case, is the module itself. The methods defined within are accessible outside the block without qualification, as if you qualified the calls withself.methodname()
. Any constants or module variables from outside are accessible inside the block.
init method
But because of the unique syntax, they are not instantiated like normal class instance objects, and so have nonew()
constructor method, which calls the newly created instance'sinitialize()
method, where instance variables are usually initiated. Also because they are a class block, raw statements do not get evaluated like they do outside at the module definition level. (Why, I do not know.)
So somewhere outside the block, a call must be explicitly made to some setup-like method within the block, to initialize any instance variables that need to start with some value other thannil
. (Uninitialized instance variables that are referenced will returnnil
.)
This setup method can be any name you choose,... I chose to use the nameinit()
in the example template.
If you have no instance variables, you do not need such a method to init them.If you do not like using a proxy class, you can explicitly define all your methods as module methods, ie:
def self.methodname( arguments )
but then you will have to qualify all calls usingself.methodname
...Since most newb's try to define all their methods like instance methods, and call them without qualification, I figured it was best to just have them put the methods in a proxy class instance block.
I prefer it myself. But to each their own.
-
very much appreciated, thanks for the detailed response
Advertisement