As things are, if you have a single-file extension and would like to get it officially signed then you need to create a folder of the same name as the file for the signature file.
My thought was if you need to create a folder anyway, why not just make it so all extension files can reside in an “extension” folder; including the loader script?
So basically the Plugins folder would contain only a sub-folder for each installed extension rather than a mix of .rb scripts and their extension folders.
You would need to make SketchUp smarter about loading extensions - it would need to understand the concept that a folder contains all an extension’s files, and look for some specially named “loader.rb” script in the folder.
Conceptually, I just like the idea of one-folder-per-extension in the Plugins folder. I also think it would create simpler workflows for installing, uninstalling, and developing extensions.
This will not work, as it is not the extension itself (nor the RBZ archive) that does the installing. It is either SketchUp itself (via the “Install Extension…” button,) or the EW website, or a 3rd party website like SketchUcation’s PluginStore extension.
“it” here is the SketchUp internal startup code, which is hard-coded in all versions. Old versions will not be getting patched to change behavior.
But, in fact, the startup load behavior has changed over the versions. All old versions with Ruby 1.8 loaded the “Tools” folder last, began loading the program child “Plugins” folder first, and branched off to load other folders elsewhere depending upon require and require_all calls in loading code, or via the presence of some 3rd party utility (like the one example I have posted at SCF, or the Additional Folders extension. There may be others.)
Sometime after SketchUp switched to Ruby 2.0 (SU2014) the “Tools” folder is now loaded first, along with rubygems and a bunch of encoding libraries.
Then the user “Plugins” and the public “Plugins” folders are processed (not sure in which order.)
I suppose an extension could be written to add a sub-folder loader loop to old SketchUp versions. But this will bring up a common occurrence we have now.
Users do not read install instructions. Even now when a library is required for an extension, they don’t read the requirements, and install the extensions without the library and then post “HELP!” threads in the forum with out searching for answers first. The extension authors (and other gurus) waste a bunch of time answering these posts.
So we would have users installing the new format extensions in old SketchUp versions, without also installing the “load loop” extension.
Lastly, there would need to be a easy way to know the difference between the package formats. A new archive file extension like .skez (SketchUp Extension Ziparchive)
Normal users (that don’t read instructions) probably don’t even know where the plugins folder is. And ‘smart people’ (if they’re worried about clutter) can move their loader files into subfolders and then write a single loader file to load all their extensions.
Incase my previous post didn’t make it clear: Any SketchUp user that is concerned about clutter can move files around and create a single custom loader to load all their extensions. No need to bother SketchUp with such a trivial thing.
Move all current loader.rb files into their sub folders, then create a single loader.rb like this:
I suppose you could write a def to do the maintaining.
#check for files in plugin dir not == main_loader.rb
#move files to sub dir if it exists, if not move to misc folder (create folder if necessary)
#append list_of_loaders to main_loader.rb
What if an old extension had a file called loader.rb in its folder that isn’t a the loader but loads, idk, component definitions or something. This change with not only make new plugins impossible to load in older SU versions but potentially the other way around too.