Plugin w/o script in Plugins folder???

draftomatic · 14 Sept 2010, 04:43

I've seen commercial SketchUp plugins that work (they even get registered as extensions in SU), but there are no scripts for that plugin within the "Google SketchUp 8/Plugins/" folder...

How do they do this?

thomthom · 14 Sept 2010, 06:28

What plugins?
Possibly, they've misplaced themselves in the Tools folder. (which is meant to be only Google's tools)

Dan Rathbun · 14 Sept 2010, 17:01

@thomthom said:

(which is meant to be only Google's tools)

I'd like to see an official statement, to this effect. If it exists ...

thomthom · 14 Sept 2010, 17:33

@dan rathbun said:

@thomthom said:

(which is meant to be only Google's tools)

I'd like to see an official statement, to this effect. If it exists ...

It doesn't say explicitly that Tools should not be used, but it does say explicitly that the Plugins folder is there plugins should reside: http://code.google.com/apis/sketchup/docs/loading.html

Chris Fullmer · 14 Sept 2010, 18:13

Bryce (or John maybe?) also commented in the forums here, or the groups, or the old forums that the tools folder is supposed to be for their use, and we should only stick to the plugins folder.

One reason that was given was that some of their files get upgraded between versions (sketchup.rb for example). And if it lived in the plugins folder, users commonly copy the contents of their plugin folder from the old version of SU to the new version of SU. This would overwrite the new sketchup.rb file with the old one. So splitting out their files into a "tools" folder solved this problem.

I'm not sure if they had other reasons than that. And I'm not sure where this is written unfortunately (and it might even be completely lost as there were a few closed @last forums that are not publicly archived anywhere). But if I find a link, I'll post it. But then again, if its only a comment on a forum, does that really make it official? Seems like it should be documented somewhere a bit more formal...

thomthom · 14 Sept 2010, 18:36

I find it formal enough that the FAQ says explicitly to use the Plugins folder.

Chris Fullmer · 14 Sept 2010, 20:43

@thomthom said:

I find it formal enough that the FAQ says explicitly to use the Plugins folder.

Fair enough, that does seem pretty straightforward.

draftomatic · 14 Sept 2010, 23:21

@thomthom said:

What plugins?
Possibly, they've misplaced themselves in the Tools folder. (which is meant to be only Google's tools)

The plugin was LightUp DEMO. And yea, I just checked... they put their stuff in Tools.

AdamB · 15 Sept 2010, 18:52

Yes, LightUp lives in the Tools folder because right from the start I've always felt there is semantic distinction between a Plugin and a Tool.

So for me, a Tool is an additional icon in the Toolbar that can be selected by the user, and through a GUI, does "Stuff". A Plugin is something that extends the underlying data - typically with attributes. It 'decorates' the SketchUp model with metadata.

So in a perfect world, you have a bunch of Plugins that extend the underlying objects, and a Tool that operates on that data.

The idea that Google plugins are called Tools and our plugins are called Plugins strikes me as kinda silly.

Just my 2 of your Earth cents worth...

honoluludesktop · 15 Sept 2010, 19:03

AdamB, What happens to your files when SU is uninsulated? Typically my plugins and certain folders survive. Does LightUp too remain?

thomthom · 15 Sept 2010, 19:10

@adamb said:

So for me, a Tool is an additional icon in the Toolbar that can be selected by the user, and through a GUI, does "Stuff". A Plugin is something that extends the underlying data - typically with attributes. It 'decorates' the SketchUp model with metadata.

Then most Ruby plugins for SU should have been in the Tools folder.
And it just complicates things by having multiple places to put stuff.

Dan Rathbun · 16 Sept 2010, 20:57

@chris fullmer said:

Bryce (or John maybe?) also commented in the forums here, or the groups, or the old forums that the tools folder is supposed to be for their use, and we should only stick to the plugins folder.

All this "seems" at first glance to make sense... however Google themselves broke this "informal" rule.
They have installed the Ocean, Utilities and Examples extensions in the Plugins folder. Ocean at least was updated for v8, but many people out there have likely overwritten it, by copying the v7 files over to v8 Plugins folder. (You won't see big problems as these are not used that much.)

I kindof agree with Adam ... a Tool is a subtype of Plugin, that is used by the user in an interactive way to create or edit model geometry. A Report generator, or an Import or Export Utility is not a Tool, although you might say they are a subtype of Extension or Plugin.

So other catagories:

Utilites into which I'd put things like: Smustard Organizer and TBD's SUbridge.

Libraries which are used by many Plugins, Extensions, Utilities or Tools.

One of the reasons to put things in the Tools folder, is some plugins (like Organizer,) can change files. So putting important Library like rubies in the Tools folder is a way to keep them separate from the run of the mill plugins. This is really a temporary fix, until we have control over the number and order of "autoload" folders. I'd really like a dedicated "Lib" folder.

Dan Rathbun · 14 Aug 2011, 07:13

This is from a developer point of view.


Extension
   |
   +-- Plugin (things the users SEE, KNOW about, and USE.)
   |     |
   |     +--- Tool (User interacts with *manually*, to create/edit model objects.)
   |     |       |
   |     |       +--- GUI Tools (like on the DRAW and TOOLS menu.)
   |     |       |
   |     |       +--- Wizard Tools (DC Attribute Editor, RoofGenerator, etc.)
   |     |
   |     +--- Implement (User uses on occasion for *specific* tasks.)
   |     |       |
   |     |       +--- BuildingMaker
   |     |       |
   |     |       +--- Exporter
   |     |       |
   |     |       +--- Importer
   |     |       |
   |     |       +--- Renderers
   |     |       
   |     +--- Utility (User uses on occasion; for *more general/useful* tasks.)
   |             |
   |             +--- Backup Manager
   |             |
   |             +--- Console (... including custom Console Extensions.)
   |             |
   |             +--- IO Bridge (.. like SU Bridge by TBD.)
   |             |
   |             +--- Plugin Installer/Updater/Manager
   |
   +-- Library
   |     |
   |     +--- API (The Sketchup API *itself* is a Ruby Extension!)
   |     |     |
   |     |     +--- DynamicComponents class (also creates both GUI and Wizard Tools)
   |     |     |
   |     |     +--- Mixin module community Library 
   |     |     |
   |     |     +--- SKX extensions (if we ever get it released!)
   |     |     |
   |     |     +--- TT_Lib & TT_Lib2 (ThomThom; Library extensions.)
   |     |
   |     +--- Ruby
   |           |
   |           +--- Standard Library extensions (ie; socket.so, matrix.rb, etc.)
   |           |
   |           +--- win32-api Library extensions (Dan Berger; replacement for Win32API.so)
   |
   +-- Service (... things the user never sees, that operate transparently.)
         |
         +--- Socket Communications
         |
         +--- Smustard Organizer

Dan Rathbun · 16 Aug 2011, 19:53

The diagram (previous post,) was prompted by yet another argument over what was a Tool, and what was a Utility, whether they were Plugins or Extensions, or both.

My argument is that everything loaded into Ruby (except the Core,) is an Extension.

Then 3 main types: Plugin, Library and Service.

Although I show 3 "kinds" of Plugins, in reality there is often overlap. A given plugin may have several, (if not all,) subtypes as features.