SketchUp API Blog - Extensions

Jim

Do you think this blog post was a random topic, or possibly a subtle hint of something in the works?

http://sketchupapi.blogspot.com/2011/07/turn-your-plugin-into-extension.html

Plugin management can get really difficult, though. If two scripts conflict with each other somehow, SketchUp can go haywire, and figuring out which scripts are the culprits can require a lot of detective work. If only all of the ruby programmers out there used SketchupExtensions... ahh, the world would be so much nicer.

@unknownuser said:

We highly recommend that you do this with all of your plugins that extend SketchUp's UI with buttons or menu items.

TIG

I notice that one too...
Why suddenly decide to promote 'extensions' now after they've spent many years 'in the wilderness'.....
Perhaps something is in the pipeline for v9 [or v8.1 ?]

Rich O Brien

Can you inform those who are unaware (me) what this extension addresses and what they are hinting at?

Aerilius

Since I'm relatively new to ruby/plugins, I haven't yet dared to propose SketchupExtension in the Plugin-Installer-Tool discussion, but also because I had the impression that in its current state, it is neither useful to users nor was I sure whether it's well designed (I can not really judge about that).

I think it's important for this discussion that we know if it's necessary to invent our own "standard" how to manage/disable plugins, or if SketchupExtension could once become a serious possibility (with some overhaul). Since the Plugin-Installer has made considerable progress, it could be very beneficial if the SketchUp Team clears the air .
(instead of a secret&surprise development strategy)

Dan Rathbun

@unknownuser said:

Can you inform those who are unaware (me) what this extension addresses and what they are hinting at?

It's not AN extension, it's a Ruby class named SketchupExtension that is basically a custom hash. It registers plugins with the Sketchup application, so it can display them in a list. The list is on the "Extensions" panel, of the "Preferences" dialog (accessed from the "Window" menu.). The list has check boxes so the user can decide whether the extension / plugin will (or will not be,) loaded when Sketchup starts.

What Scott is saying is that all "packages" that are plugins (rather than just utility scripts that are loaded on-demand,) should use the SketchupExtension class, with a registration script (he gives an example in the blog,) located in the Plugins folder.

What newbies may not realize, is that it requires that the actual plugin files, be kept in a sub-folder. Which is really one of the "best practices". It's called managing your "filespace". Why mix your files up with everyone else's ??

I further encourage rubyists, to use an "author" folder (which would be their top level "filespace", and put ALL their plugins, in sub-folders of their "author" folder. (The actual name of the "author" folder can be a company name, or your SCF screen name, or whatever you like.)

Jim

Speaking of best practices Dan, I think your post on using nested modules and Extensions (forget which thread it's in) belongs in its own thread.

Dan Rathbun

@aerilius said:

Since I'm relatively new to ruby/plugins, I haven't yet dared to propose SketchupExtension in the Plugin-Installer-Tool discussion,

I did. I asked Dana to have a look at my example, in another topic.

@aerilius said:

...but also because I had the impression that in its current state, it is neither useful to users nor was I sure whether it's well designed (I can not really judge about that).

Well, there is a difference between the Ruby functionality, and the Application UI functionality.

Most users hate the Preferences dialog panel interface, for several reasons:

Too small, only shows limited number in the list.* Panel cannot be sized.* The amount of attribute data displayed is fixed.* The list cannot be sorted (it's shown in load order.)
Now... the Ruby functionality issues (or short-comings,) have prevented others from creating a better manager. The most glaring is the one Dana is working on, that is "one-click" installation and updating. This is also the number one complaint.

@aerilius said:

I think it's important for this discussion that we know if it's necessary to invent our own "standard" how to manage/disable plugins,

It's more important that rubyists use a common class, that can be extended. For instance, we already have the issue where some plugins are Smustard Organizer compatible, but not SketchupExtension compatible, and visa versa.

There are quite a few plugins (a most all of the Google authored plugins,) that already use SketchupExtension class instances. It does make sense not to orphan them.

@aerilius said:

or if SketchupExtension could once become a serious possibility (with some overhaul ).

YES, and I've already done an overhaul, for my own use, and proved to myself that the class can be improved greatly (and the few current bugs fixed.)

BUT.. I don't "own" the class, it's a standard API class, so I can't release the code. I have about $2500 labor into it, and was wondering, if anyone would be interested in donating toward it. If a "donation piggybank" reached that amount I'd release it. (I wonder if I can convince 100 people to donate $25, or 2500 to donate a buck?)