My Sketchup Pro 2014 Plugins folder is missing

Dan Rathbun

It is best to NOT copy old plugin versions over. Install the latest from the SketchUcation Plugin Store, or the Trimble Extension Warehouse.

SketchUp 2014 was updated to Ruby 2.0 which requires all scripts to be UTF-8 encoded, and many other script fixes. Older versions of plugins will not load in Ruby 2.0 !

jeff hammond

your screenshots aren't showing which path you're on..

there are 3 major library's in osx.. Macintosh HD, user, and system and i can't tell which one you're in..
maybe the simplest way to show us what path you're on is in Finder's View menu, click 'show path bar'.. then the path will be shown at the bottom of the finder window.. like so:

Screen Shot 2014-04-16 at 10.14.13 AM.png

845Adi

Dan-

Since Shaderlight has been updated for SU14, how do I get it to show up without giving me a ruby script error message?

Clem

Dan Rathbun

You need to contact ShaderLight author. I do not have that so cannot help with it specifically.

driven

hi Clem,

I can see by the other folders that that is the right place, but you don't need to have all the SU materials in there...
SU will be seeing two folders with the same name and maybe that's blocking some...
only keep yours in their own folders, if there are missing old SU ones you like, rename their folder, e.g. wood_su_v6, etc...
or make a 'favorite_su_mats' and weed out the ones you never use... just your own folders of materials...

If you drag that Sketchup folder into your Favourites sidebar you can get to things and sort it out easier.

As for Plugins, rename that folder... [ Plugin! ] restart SU and it will make a new one, move only Shaderlight into it and see if it works...

If it works, then add new versions of your other Plugins, until it breaks...

If it doesn't work, put it back in the parked folder [ Plugins! ]

john

845Adi

John-

Apparently the Sketchup 2014 folder is hidden in Lion, which is what I'm using. The only way I can get to it is to type in
open "#{File.dirname(Sketchup::find_support_file("Plugins"))}" (from someone above) and it takes me directly to that folder so I cannot drop it into the favorites on the side. I want to make sure I understand you correctly when you say remove the materials....keep all of my 01 folders and delete everything from asphalt through wood?

And as for renaming the Plugins folder, do you mean the folder directly under "OldColors"?

Just want to make sure I don't screw this up even more.

Clem

jeff hammond

there is something a bit unfortunate with the way the materials are set up now.

the 'standard' materials are now located in the .app/contents -- basically meaning when you update sketchup2014 to a newer version, those materials will be overwritten and any materials besides those shipping with sketchup will be lost..

i have a material package from google(?) which has a lot more materials being offered in the same categories-- for instance, the brick&cladding which ships with sketchup contains 11 .skms while the expanded version offers 78 in the same folder name - bricks&cladding.

the problem is-- when i place the expanded version in my user materials folder, sketchup will not recognize those materials.. or- if a folder is in the user material library which shares the same name as the one in .app/contents, the user materials will not appear in sketchup's material browser.

i'm going to bring this up to the suTeam to see if they can do something about it and/or allow folders sharing the same name to merge their contents in the material browser..

a temporary workaround is to use the terminal command- ditto

ditto -V sourcefolder destinationfolder

in my case, i have the expanded materials collection in a folder named Materials in my ~/Documents folder..
so i enter this in Terminal.app:

ditto -V ~/Documents/Materials /Applications/SketchUp\ 2014/SketchUp.app/Contents/Resources/Content/Materials

..and my material folder merges with the one in .app/contents.. so, if you want, you can put your Materials folder in your Documents folder then copy/paste the above code into terminal and press return..

all of your materials inside subfolders which share the same name as the standard sketchup palettes will be added to sketchup.app/contents.. when you update sketchup2014 in the future, run the terminal command again..
(this could be made into a little automator app or applescript etc to make it easier but i'll hold off on publishing anything like that for now until i get some more info from the trimble peeps)

845Adi

Jeff-

You must be on a PC (I'm on a Mac) because nothing you said above makes any sense to me at all. This is so frustrating!

Can you dumb it down for a 5th grade mac user? Thanks!

Clem

driven

Yes, that 'Plugins' Folder, renaming will force SU to make a nice clean fresh one with only the su_ plugins...
so, you eliminate any clashes...

'Materials' if you rename any you think are SU's you should be able to check from in SU for identical content...
this is the v2014 list for SU...

Asphalt and Concrete
Blinds
Brick and Cladding
Carpet and Textiles
Colors
Colors-Named
Fencing
Geometric Tiles
Groundcover
Markers
Material Symbols
Metal
Roofing
Sketchy
Stone
Tile
Tonal Patterns
Translucent
Vegetation
Water
Wood

driven

@jeff hammond said:

all of your materials inside subfolders which share the same name as the standard sketchup palettes will be added to sketchup.app/contents.. when you update sketchup2014 in the future, run the terminal command again..
(this could be made into a little automator app or applescript etc to make it easier but i'll hold off on publishing anything like that for now until i get some more info from the trimble peeps)

I think we should actively discourage adding anything to app/contents...

with 2014, you can do a lot of File moving renaming from Ruby, so a migration Plugin that copies the 'Material', 'Templates', 'Components', 'Shortcuts', etc... can be created quite easily.

With Materials, it could simply append the SU folder name after adding to the User path Materials folder. So you end up with 'Blinds' in SU and 'Blinds+' in the User path...

thoughts

jeff hammond

@driven said:

I think we should actively discourage adding anything to app/contents...

agree.. what i posted was probably confusing to many/most and i don't think i'm going to simplify the explantation or make a script to do it.. (i.e.- i'll do it for now but i don't think i should encourage other to follow )

@unknownuser said:

With Materials, it could simply append the SU folder name after adding to the User path Materials folder. So you end up with 'Blinds' in SU and 'Blinds+' in the User path...

thoughts

that would work of course.. it's just that you end up with a material list which is twice as long and have different blinds being listed in two separate locations..

i really think suTeam needs to fix this.. that said, i haven't downloaded their 'bonus pack' since maybe su7 so it's possible things have changed now and/or if the pack is still being offered, the naming convention is different.. i'll have to search around for how they're dealing with it now..

driven

@jeff hammond said:

it's just that you end up with a material list which is twice as long and have different blinds being listed in two separate locations..

The 'Blinds+' could remove duplicates, and only contain the different ones... and not even exist if identical to 'Blinds'

driven

@Jeff

OT...

re Automator, have you seen my 'Materials' folder?
I don't know why Automators such a hard sell...

jeff hammond

@driven said:

The 'Blinds+' could remove duplicates, and only contain the different ones... and not even exist if identical to 'Blinds'

out of curiosity, i added a material to one of the categories which installs with sketchup (meaning- i did it all inside of sketchup and not through the folder structures).. in hopes of finding out what naming convention sketchup would use in the ~/materials folder in order to keep a custom user material inside of a default list..

..but it doesn't store the material in the expected location.. instead, it puts the material in .app/contents ..and that will be overwritten upon an update/reinstall.

i don't think they thought through this very well..

re: Automator.. i too imagine automator should get more attention than it does.. realistically, it's easy to use and quite powerful for many things.. oh well -- i just hope apple doesn't do away with it.. they are updating it (for instance- notifications in mavericks) so i guess that's a decent sign that they're not abandoning it just yet.

jeff hammond

@driven said:

I think we should actively discourage adding anything to app/contents...

with 2014, you can do a lot of File moving renaming from Ruby, so a migration Plugin that copies the 'Material', 'Templates', 'Components', 'Shortcuts', etc... can be created quite easily.

With Materials, it could simply append the SU folder name after adding to the User path Materials folder. So you end up with 'Blinds' in SU and 'Blinds+' in the User path...

thoughts

well, dan pointed out the obvious (on another forum)..

instead of encouraging moving stuff into .app/contents, do it the other way..
merge the content into the user directory then delete the stuff in .app/contents..

this is all pretty easily scriptable or done via terminal.. can you do something like that in ruby?

AndrewS

@jeff hammond said:

instead of encouraging moving stuff into .app/contents, do it the other way..
merge the content into the user directory then delete the stuff in .app/contents..

this is all pretty easily scriptable or done via terminal.. can you do something like that in ruby?

I'm going to throw in my two cents and say this isn't a great idea.

I haven't fully figured out the entire current story regarding code signing on the Mac, let alone its future, but this idea worries me. AFAIK, when we run our digital signing on the Mac .app bundles, those signatures only affect the executable parts of the bundle. However, I can certainly see a time coming when it's possible Apple may include all contents of the bundle in the digital signature calculation.

If Apple suddenly starts making their digital signatures include all files in the bundle and you write a script to change the bundle after we've signed for its contents, then you would invalidate the digital signature. Depending on the system settings, this could cause the bundle to be denied executable access by the OS. Again, this isn't an issue right now, but it very well could become one. The current state of signing on Mac leaves open gaping security holes.

I'd suggest never modifying anything within the bundle to be safe.

Andrew

driven

@jeff hammond said:

instead of encouraging moving stuff into .app/contents, do it the other way..
merge the content into the user directory then delete the stuff in .app/contents..

this is all pretty easily scriptable or done via terminal.. can you do something like that in ruby?

That makes sense and this is a safe way to do it...
I decided it was best to use some mac only commands so it will fail on PC's...
it find the 'User' folder
it checks if you have both...
it rename the SU one and merges it's contents into new or existing 'User' one...

Edit: I removed the script from my post, in 'part' due the Andrew comments below, but also because I wouldn't use it myself...
I did test it and it clutters up my 'User' Materials Folder so much that it becomes a pain to quickly scan...
I'll modify it so it leaves the current SU materials alone but looks in 'All' the other SU version Materials Folders and copies only the 'Strays' into new 'User/../Materials/Sub_folder'...
from there they can be easily be sorted out or removed manually...

john

driven

@AndrewS

I removed that script and made a note why, but as your watching I'd like to re-ask

why not have empty User path folders included in the instal?

I know they are 'made' on demand, but people do go looking for them to add things manually, and resort to all sorts of things when they are not there...

'Materials', 'Components' and 'Templates' are the ones that 'go missing' in peoples minds, and having them inplace makes migration advice easy to give...

john

jeff hammond

@andrews said:

I'm going to throw in my two cents and say this isn't a great idea.

I haven't fully figured out the entire current story regarding code signing on the Mac, let alone its future, but this idea worries me. AFAIK, when we run our digital signing on the Mac .app bundles, those signatures only affect the executable parts of the bundle. However, I can certainly see a time coming when it's possible Apple may include all contents of the bundle in the digital signature calculation.

If Apple suddenly starts making their digital signatures include all files in the bundle and you write a script to change the bundle after we've signed for its contents, then you would invalidate the digital signature. Depending on the system settings, this could cause the bundle to be denied executable access by the OS. Again, this isn't an issue right now, but it very well could become one. The current state of signing on Mac leaves open gaping security holes.

I'd suggest never modifying anything within the bundle to be safe.

Andrew

hey Andrew..
thing is, sketchup itself is moving files in/out of the bundle.. if i create a texture, in sketchup, and place it in the material list "Wood", that .skm will go to .app/contents instead of ~/Library... Likewise, if i delete a material from any of the bundled lists, it will delete from the bundle.

regardless of that though, there's a problem.. here's a shot of my Materials folder which i used in SU8..

meant to show that i have hundreds of .skm files.. most are in folders with the same names that ship with su2014.

if i put that Materials folder at ~/Library/Application Support/SketchUp 2014/SketchUp ,most of these materials will not be available in sketchup.. (only those in the folders: Indigo,Surface_Layer, & HiRes will be recognized)

so what should i do to have my .skm collection in sketchup 2014?

AndrewS

@driven said:

why not have empty User path folders included in the instal? I know they are 'made' on demand, but people do go looking for them to add things manually, and resort to all sorts of things when they are not there...

John,

I understand and agree with your complaint, but there are some complications preventing us from providing the empty directories at install.

On Mac, there is no "installer"; there's just a drag-and-drop bundle. Therefore, we can't create anything in other directories at "install" time, but only afterward--upon first run or later.
On Windows, although we do have an installer, we still can't necessarily handle this at install time due to issues of the execution context of the installer. If user "A" runs the installer on a shared machine and we create the empty content directories in the folder for user "A", that doesn't solve the problem for any of the other multiple users like "B", "C" and "D". This same problem would exist on the Mac if we had a "real installer" for that platform as well, which again means we're stuck creating each user's directories sometime after the install is done.

As I've shown, the very earliest we can create the empty user directories is upon first launch. I see no way around the fact that anyone going to look for those folders before first launch will be out of luck.

Now, having said that, it's my understanding that we don't actually create these folders at first launch, but rather, on-demand--when they're needed to store newly created templates, downloaded extensions, etc.

I agree it would be a straightforward matter for us to create those folders all on first launch of the product even though we don't do so today. I'll open a feature request for it.

Andrew