[Plugin] SketchUcation Tools 2.6

cotty

@kb said:

Could you give a clue of what to do?

You can find a detailed solution here.

KB

As I see I am not the first one to went trough the game of Security and Permissions.

Thanks a lot to all of you.

Katerine

TIG

With v2014 the newly located Plugins folder automatically has FULL permissions so at last this issue should be behind us
Except the same still potentially applies to the shipped folders for Materials/Components/Styles - although of course you can have extra folders linked to anywhere you choose...

pomelo3d

Hello. Two suggestions for the next version.
It is possible add an option to delete a plugin?
It is possible add a link to open the folder where all the plugin?

thanks

Box

@pomelo3d said:

It is possible add an option to delete a plugin?

The tool has an uninstaller, it's not a toolbar item but you will find it in the Sketchucation plugin submenu.

Pixero

A way of not having to click on three confirmation boxes for each installed plugin would be great.

Rich O Brien

What version of the the plugin and SketchUp are u using Jan?

Pixero

v2.5 with SU 8 on Windows 7 at the moment.

Rich O Brien

You should see an improvement on less clicks on more modern versions of SketchUp.

It is especially sweet on v2014 because of the plugin folder relocation.

If you use Fredo's Additional Folders though you still get prompts. But the default installs are single click conformations.

TIG

In more detail...
The number of dialogs/clicks needed is a direct result of the SketchUp version.

In v8:

If it's the first time you've used the PluginStore's AutoInstall that session...
There's a 'click to confirm installation' dialog [SCF initiated but it's built-in to SketchUp], as the destination folder's 'installable'/'writable' properties are checked.
Then a 'click to confirm installation' dialog [unavoidable - it's built-into SketchUp].

On subsequent usage during that session, there should just be the one 'click to confirm installation' dialog for each AutoInstall [unavoidable - it's built-into SketchUp]
...
Final closing SCF dialog to tell you it was successful.
This on PC [and probably MAC - but untested...].

In v2013:

If it's the first time you've used the PluginStore's AutoInstall that session - there's a 'click to confirm installation' dialog [unavoidable - built-into SketchUp].
Otherwise, for subsequent installations there is no confirmation dialog [unavoidable - it's built-in to SketchUp].
...
Final closing SCF dialog to tell you it was successful.
This on MAC/PC.

In v2014:

There is NO 'click to confirm installation' dialog built-into this SketchUp version.
...
Final closing SCF dialog to tell you it was successful.
This on MAC/PC.

For the 'Update All' option you should get the initial 'confirmation click(s)' [if any] and a 'final closing dialog' for ALL Plugins, not for their individual AutoInstallations.

If you have more than one Plugins folder defined in SketchUp's $LOAD_PATH then you WILL also get a dialog asking you to choose the destination folder for the Plugin's AutoInstallation, either before the 'confirmation click(s)' [if any], or simply before the 'final closing dialog' if you have v2014...

tomot

@tig said:

With v2014 the newly located Plugins folder automatically has FULL permissions so at last this issue should be behind us

Where do I find out more about the location of the new v2014 plugins folder?
It seems to me there were more important items on various SU wish lists, over the years. I don't ever recall seeing move the Plugins folder, on such a list.

Bob James

I have SU13 installed.

When I loaded SU14 it put plugins into two places:
C:\Users\jamesb\AppData\Roaming\SketchUp\SketchUp 2014\SketchUp\Plugins
C:\ProgramData\SketchUp\SketchUp 2014\SketchUp\Plugins
I use 'Additional Folders for Plugins'.
D:/Dropbox/Plugins

When I install a new plugin from SketchUcation Plugin Store and direct it to the 'default' directory C:\Users\jamesb\AppData\Roaming\SketchUp\SketchUp 2014\SketchUp\Plugins, I get acknowledging dialog boxes and the plugin is loaded.

When I try to install a new plugin from SketchUcation Plugin Store and direct it to my additional folder D:/Dropbox/Plugins, there are no acknowledging dialogs and the plugin is not loaded.

This happens on my desktop machine here at work, on my laptop and on my machine at home.

I do not have this problem with SU13. I can load plugins using SketchUcation Plugin Store into D:/Dropbox/Plugins

Additional Folders.JPG

SU13 Results.JPG

Rich O Brien

Investigating....

I can't reproduce it but it is the second report in 2 days

TIG

Can you repeat it with with the Ruby Console open and see if there are any error messages
This is an odd glitch that we must get to the bottom of...

Is your D:/... folder a 'real folder' or a symbolic link / shortcut ?

There have been some reports of network glitches with v2014 and is not the same drive as ?

EDIT:
I just setup J:/Plugins as a custom Plugins-Folder using Fredo's tool in v2014.
I used the PluginStore to install a Plugin.
J:/Plugins was recognized as a possible installation destination and offered in a dialog.
I chose it.
The closing dialog said it installed successfully.
On checking I find that it had installed properly in that folder.

So all seems well.

But suddenly it stops installing - no errors, says it's completed OK but no file !
I find some Plugins install OK and some do not.
IT should only report success if it has worked - which is odd...
I says it has, but nothing is there ...
No Console messages - nothing

I'll do some debugging using the rb versions and report back...

TIG

So far I found that when a Plugin fails to extract and get installed into a custom-folder the ZIP that it's using seems to fail to extract properly - it seems to be very slightly corrupted - a manual extract of it is OK, but the WIN automated one is unreliable...
Perhaps the way that v2014's Ruby extracts the ZIP data and recompiles the RBZ is subtly different to the previous version and so occasionally it fails ?

I am investigating...

Because the data transfer relies on a attributes which are packed/unpacked, perhaps their length in the latest version is less tolerant ?

Jim

In 2014, you could download the .rbz directly saving everyone bandwidth.

Bob James

@jim said:

In 2014, you could download the .rbz directly saving everyone bandwidth.

But then SketchUp Plugin Store wouldn't recognize it for updating
And, no, D:\Dropbox\Plugins is located on my internal RAID. My is an SSD.

Jim

@bob james said:

@jim said:

In 2014, you could download the .rbz directly saving everyone bandwidth.

But then SketchUp Plugin Store wouldn't recognize it for updating
And, no, D:\Dropbox\Plugins is located on my internal RAID. My is an SSD.

Oh, I meant the Plugins Store could save bandwidth by downloading the .rbz directly rather than they way it works now. For example, the MoveIt file which the Plugin Store downloads is 4x larger than the direct .rbz download. Over the thousands of plugin downloads the Store is serving up, that savings will really make a difference.

TIG

@Jim

We already went down that route of downloading the RBZ in the webdialog - just like in the browser based PluginStore.
Please don't think we haven't thought about it...
Built in security in all web browsers / js prevent a direct download of any files without some user intervention and selection of a folder - that's why the user has to choose a destination for the RBZ download.
This chosen destination is not readily accessible.
But if it were we could of course then auto-install from that RBZ directly.
The exception to this is when it's done through a webdialog within SketchUp with the "load_from_url", which once you have the URL passed by callback the load is done automatically.
From that downloaded SKP we can extract the data to recompile a RBZ in a temp folder our side, and from that we can then Auto-Install the Plugin...
I have been looking at ways of using a server-side button-click to get a fileObject [i.e. where the user chooses to save the RBZ], then pass that path to the server in a form-submit, and then download the RBZ to that destination. On IE the fileObject is the true file-path, but on Safari it is obfuscated to just the file-name for better security, which is no help when later on we are trying to find the downloaded RBZ for using that in auto-installation...

If you have any clever ideas on how we might circumvent this security trap then please share them [especially for the obfuscating MAC's Safari !]... It clearly would be better if an author simply uploaded his RBZ and then that was downloaded from the browser OR Auto-Installed from the PluginStore's webdialog... Side stepping the RBZ.SKP altogether.

Jim

I completely understand why it you did it they way you did in 2013.

In 2014, do it with Ruby. Use net/http or open-uri to download the binary - http://stackoverflow.com/questions/2263540/how-do-i-download-a-binary-file-over-http

Should be possible.... hehe.