My Sketchup Pro 2014 Plugins folder is missing

[Dan Rathbun]

On Mac, in SU2013 and SU2014 (or later,) the plugins should be in the user path (not the HD path.)

In each version, you can get the default plugins path, by opening the Ruby Console and typing:
Sketchup::find_support_file("Plugins")

also try:
Sketchup::find_support_file("Materials")

... and any other of the support directories.

On PC, only the "Plugins" and "Classifications" have been moved into the user path, so far. (But expect that all may be moved into the user paths in future versions.)

[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.

[driven]

at the 'User' path SU only make folders as needed. i.e. if you create a Material it makes the folder in the 'User' path...

however, if you search for 'Materials' before that, it actually takes you to the wrong folder inside SU.app...

the best thing to do is open up the 'User/../Plugins' folder and paste your 'Materials', 'Styles', 'Templates', and even 'Shortcuts.plist' from v13 [/v7/v8 etc..] in the same folder it's in.

from 'Ruby Console' you can get to it with

`open "#{File.dirname(Sketchup;;find_support_file("Plugins"))}"`

or just find it

/Users/[ your name here ]/Library/Application Support/SketchUp 2014/SketchUp

all 'User' content in here will be found by 'SU'...

john

[845Adi]

Dan-

When I type in the code you gave me, it says that I should find that folder where you said....but it's not there. See attached screenshot.

Driven-

It DID take me to a folder from the code you gave me, but when I added the materials from my 2013 folder, they still didn't show up....I'm attaching a screen shot and you can see where I've uploaded many of my own materials already, but from the asphalt (highlighted) folder down, I cannot see any of those in SU14.

Also, when I moved my plugins over from SU13 folder, I now get a bunch of loading errors for the Shaderlight (which I have purchased an upgrade to SU14 for)highlighted in my SU2013 folder.

Help?

Clem

---

---

---

[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:

[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...

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?

[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