Thought on Plugins Folder Organization


#1

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.


#2

Yes, agreed.

I also had promoted one master author/company folder in the “Plugins” folder, but at the time it’s challenges could not be overcome, and we got instead the author-underscore prefix.

Changing now would make 3rd generation extensions non-backward compatible.


#3

Seems the extension should know what version of SketchUp it is in. If it detects version 17+, it could move the loader.rb into the sub folder (when installing).

Perhaps (similar to .rb/.rbs) it could look first for a loader in the plugin dir then search the subfolders for loaders.


#4

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)


#5

I don’t think it’s really a big deal.

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.


#6

Well, the Extension Warehouse, and the SketchUcation PluginStore extensions would need to be modified also (and any other plugin installer.)

You know how it is,… they have it working the way it is now, and it would be low priority to change it.


#7

I can agree this would make more sense. However I think changing that now could lead to many compatibility issues and just isn’t worth it.

If it aint broken, don’t fix it.


#8

Exactly.

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.

For example:
Move all current loader.rb files into their sub folders, then create a single loader.rb like this:

Sketchup::require 'extension1/loader.rb'
Sketchup::require 'extension2/loader.rb'
Sketchup::require 'extension3/loader.rb'
Sketchup::require 'extension4/loader.rb'

#9

Having to maintain files like this for loading source code repos was one thing that lead to the thought to begin with.


#10

I suppose you could write a def to do the maintaining.

def maintain_loaders
  #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

end

PS. It might not be that simple. ???


#11

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.


#12

Right. It might not be ‘one size fits all’.
An alternative might be to create a loaders folder then dump files there.