Fooling the EW?
-
How does:
# Statement for EWH compatibility begin ; SketchupExtension.new "toto", "toto.rb" ; rescue ; end.. fool the EW ?
The extension object is never registered, so never gets a registry entry, and never gets loaded.
It is unreferenced so gets cleaned up by GC.
And what does "toto" mean ?
-
-
I think this just fools the EW server script checker. It rummages through a script looking to make sure the script calls SketchupExtension.new or something like that.
Its not ideal to fool it like this, as the checking mechanism might change in the future and it might search for something more advanced. BUT, the EW doesn't really handle plugin bundles that should not be extensions, like libraries. So that is why we are seeing a few of the libraries trying to fool the EW server script checker like this.
-
My plugins do register as SU Extension, but these détails are all handled centrally by LibFredo6, based on the information provided in the .plugin file of each script.
I discovered that the EWH compliance was actually that the top .rb file contains such registration statement, but did not care about what was loaded (so 'toto' was perfect for that).
Fredo
-
Then on the other hand... thomthom does some slightly different workarounds
His loader RB registers an Extension for TT Lib based on one of his helpers ['core.rb'].
BUT this is never 'used' - so it's actually pointless.
Any of his tools requiring the contents of his TT Lib folder will load them as needed anyway.
So it his TT Lib extension is disabled by the user it makes no difference, because the contents of the TT Lib get found/loaded anyway.
It does cause some confusion with a few users, because whether or not the TT Lib Extension is enabled has no affect on its efficacy...
Disabling [or removing] the RB that makes the TT Lib Extension WILL stop that Extension getting made, but the TT Lib is always still available, provided the TT Lib folder is left intact !One cleaner workaround would be for the first run of the installed RB extension-maker to delete itself!... so in future it does not load at all, and so there is no spurious sham TT Lib extension to confuse users...
If a newer version is installed then the self-deleting loader would not survive past its first run...
-
In my case, LibFredo6 is registered as a true extension. If you disable it from the Extension Dialog box, then all my scripts relying on LibFredo6 will be disabled.
I do agree that SU should provide some built-in support for scripts relying on a common library as this becomes more frequent:
- managed the requirement of the Lib
- possibly check its version for compatibility
Fredo
PS: I wonder why there is a field requirement when you upload a plugin, but it is not displayed in the PS tool browser window.
Advertisement