Where is Material folder for 2014 Mac
-
Plus 50 is 50 degrees warmer than here right now. I'll take it.
-
Want me to send you some sunshine
-
Yes, please. If it's warm.
-
@mwm5053 said:
You guys are funny
but I still can't locate the material folder where the default materials .skm's are, not in MacHD or user /Application Support I would like to put SCF seamless .skm's and others I've created with the default material .skm's.You really don't want to put yours with the defaults. The defaults are stored here
-
Thanks wind-borne, any particular reason you say not to? I found a few years ago SU 6 material library which had a whole bunch of materials that I guess they took out of newer ver. the t I actually used in SU8.
-
@mwm5053 said:
any particular reason you say not to?
The reason not do do it that way is simply, "that's not the way it was designed to work." Any time you fight against the intent of a program's designers, there's a good chance it'll come back to bite you later, so I think you'd do well to try to fit what you want to do into the provided paradigm, even if it's not what you're used to.
In current versions of Windows and Mac OS, there is a strict partition separating program data from user-modifiable data, and partitioning users from one another. The idea of treating every computer like a multi-user system is nothing new in UNIX, where it's been the case forever, and it's also nothing new on Mac OSX, which is itself based on a variant of UNIX called BSD. It is a much newer topic on Windows, where it's taken a long time to move the OS and user community toward that understanding, but we're there now.
That distinction of user vs. system data is seen clearly in this case.
The .app bundles live inside the /Applications folder, which requires root privileges to modify. This makes perfect sense because when messing around in that folder, you're either installing or upgrading a program that affects all users. Any changes you make there affect every user account on the system, and your permissions must be elevated accordingly.
The user's home directory is the appropriate place to make changes that should not affect any other users. To me, personal customization via changes to plugins, materials, templates, etc., are all examples of items that should go inside a given user's folder and should not pollute the system for other users. On a Mac, the tilde (~) character refers to a given user's home directory. The correct location for custom materials is ~/Library/Application Support/SketchUp 2014/SketchUp/Materials/. If that folder does not already exist, it's because you haven't created any custom materials yet. You may create the folder yourself and put your custom materials in there, or you can try creating a custom material from SketchUp and it will appear there.
I fully recognize that you may be the only user of your computer and you may find it an inconvenience to treat it as if there are other users. Nevertheless, that's the way the operating system was designed to work, so this is really the best practice, even if you are the only user.
One final note about why you shouldn't modify anything inside the .app bundles is that someday, manually modifying the contents of the bundles we provide may actually break SketchUp. When we distribute SketchUp, we digitally sign the bundle to prove that it came from us. The bundle's signature is only valid if its contents remain exactly the same on your machine as they were when we signed them. Although it doesn't cause any security problems right now, the day is probably coming when seemingly benign modifications, such as to skm, skp, jpg, or png files within the bundle will cause the OS to prevent launching the program, marking it as a security risk due to the presence of unauthorized changes occurring since signing. You will avoid ever having that problem if you make a point of staying out of the app bundles altogether.
Andrew
-
Thanks for the thoughtful reply, Andrew!
Another reason you didn't mention is that an update of SketchUp might legitimately overwrite any part of the /Applications/SketchUp XXXX/SketchUp.app folder. Anything a user puts there is at risk of being lost!
Steve
-
@slbaumgartner said:
Another reason you didn't mention is that an update of SketchUp might legitimately overwrite any part of the /Applications/SketchUp XXXX/SketchUp.app folder. Anything a user puts there is at risk of being lost!
That's probably the most obvious reason and I totally omitted it. Good catch!
Andrew
-
@slbaumgartner said:
Thanks for the thoughtful reply, Andrew!
Another reason you didn't mention is that an update of SketchUp might legitimately overwrite any part of the /Applications/SketchUp XXXX/SketchUp.app folder. Anything a user puts there is at risk of being lost!
Steve
not might-- it does overwrite it.. there's a thread around here somewhere where this was being talked about and i tested it out (installed a su update with a couple of custom materials in the .app/contents).. the custom materials were wiped out.
-
Thanks Andrew and Steve I was just curios so I will take your advice, always a good idea when smarter people tell you not to mess with it I've learned.
-
@jeff hammond said:
@slbaumgartner said:
Another reason you didn't mention is that an update of SketchUp might legitimately overwrite any part of the /Applications/SketchUp XXXX/SketchUp.app folder.
not might-- it does overwrite it...
Hey guys,
Not to contradict, but to reinforce, here's a little more info. Once upon a time, we had a true "installer" program for Mac. We distributed our software as a file with the "mpkg" extension. Upon double-clicking, such a file is opened by the Mac's built-in "Installer.app" program and then instructions and program files are pulled from the mpkg file and installed. This was really useful when we installed files to other folder locations outside of the app bundles during installation. During an upgrade of an existing installation, that installer followed a certain set of rules for file and folder overwrites according to how Installer.app operated.
Starting with 2013, we abandoned the traditional installer in favor of a "drag and drop DMG". The idea now is that when you download SketchUp from us, we give you a compressed DMG, or disk image, that contains not an installer, but a folder housing the three applications' bundles. Rather than turn the installation work over to "Installer.app", in the new system, we just let the user manually drag the SketchUp 2014 folder from its location on the disk image, to a shortcut representing the "Applications" folder, which Finder simply interprets as a command to copy the folder from one place to the other. This is possible because all of the SketchUp Pro apps are fully self-contained within their bundles now, obviating the need for a more complex installer program.
Whereas the old system relied on Installer.app to do its magic to install the program (according to its idiosyncrasies) , the new system relies only on Finder to copy the data. Therefore, ultimately the specific method by which the files are copied is a function of Finder's implementation and would possibly be implementation-dependent. Meaning, Apple might change the way the copy routine from Finder works in 10.10 and then the way an existing copy of SketchUp gets "updated" might change.
As a result of this somewhat problematic update scheme, and also due to my fear that Finder might interpret your desire to copy a new SketchUp installer "2014 B" to the /Applications folder where SketchUp "2014 A" already exists as an invitation to overwrite old with new and keep anything from the old folder that isn't in the new one, any time anyone asks me how to install a maintenance release of SketchUp on the Mac, my advice is automatically and unequivocally, "drag the old /Applications/SketchUp 2104/" folder to the trash, empty the trash, and then open the new DMG and copy the SketchUp 2014 folder from that location to /Applications.
My instructions may only be followed confidently if you've never messed with the app bundles yourself and aren't at risk of losing anything by performing the delete. So yes, avoiding loss of any custom changes due to reinstall is a great reason to leave the app bundles alone.
Andrew
-
I am hoping someone on this board can help. I migrated my materials folder from google 8 to google 2014 just as the direction said. Yet when I open my new 2014 version none of the materials are there. It seems as if it does not recognize my .skm files that where in the 2008 version. Is there a reason for this? I tried to manually put an .skm file into my materials via new texture, but .skm files are not selectable and faded out. This led me to beleive that my new 2014 does not take .skm files and thus the reason for the migration to not be working. Any suggestions? I am putting this all under the Users folders...Library... Application Support by the way under the correct google skethcup folder. This is hard because all my old models are not showing correctly and my sketchup 2008 has already expired. Thanks!
-
@kjolesz said:
I am hoping someone on this board can help. I migrated my materials folder from google 8 to google 2014 just as the direction said. Yet when I open my new 2014 version none of the materials are there. It seems as if it does not recognize my .skm files that where in the 2008 version. Is there a reason for this? I tried to manually put an .skm file into my materials via new texture, but .skm files are not selectable and faded out. This led me to beleive that my new 2014 does not take .skm files and thus the reason for the migration to not be working. Any suggestions? I am putting this all under the Users folders...Library... Application Support by the way under the correct google skethcup folder. This is hard because all my old models are not showing correctly and my sketchup 2008 has already expired. Thanks!
I don't know what directions you followed, so it's hard for me to say with any certainty what's wrong. Can you point us to the set of directions you followed?
I'm guessing part of your problem may be the fact that SketchUp is no longer owned by Google. So you shouldn't have the word "Google" anywhere in the path you used to set up your 2014 materials. So when you say it's under the "correct Google SketchUp folder" (although I corrected the spelling), I don't believe it.
Andrew
-
@Andrew
with risk of repeating myself...
what are the chances of SU providing a migration assistant that scans all 'previous' locations and relocates 'orphaned skm's and skp's' into the appropriate User Folders...I also think native 'Help' menu items for 'Open My Plugins [folder]', 'Open My Materials [folder]' would save much confusion...
Then we can reply, "Go to the 'Help' menu, and click..."
much simpler, if SU does it...
john -
Hi, John,
@driven said:
I also think native 'Help' menu items for 'Open My Plugins [folder]', 'Open My Materials [folder]' would save much confusion...
I understand how your suggestion would improve things and agree some folks would really benefit. I will submit the feature request and we'll see what happens.
On the other hand, I can personally understand why the request might be denied.
First, the Trimble Extension Warehouse was designed to alleviate these concerns for the average user, and I think you can understand our wanting to really promote that system. Viewed in that light, adding that feature could be seen as a step backwards from the sort of 'ignorant bliss' we'd prefer for the overwhelming majority of our users have about the inner workings of the plugin system.
Second, it seems like those who would really need to know the location of the plugin folder are plugin writers. I think anyone who has enough programming, logic and general computing skill to create a plugin should inherently be able to seek out the information to find the plugin folder without such a menu item--particularly since it's stated right in the SketchUp Ruby docs. This hypothetical user would possibly find the info in a relevant Google search faster than they'd self-discover the associated menu item.
Third, if we're going to the trouble of adding this feature, it becomes complicated by the technical fact that there's more than one plugin location (the user and system locations). Clearly, this feature would need to open only the user's folder (my plugin folder, as you phrased it). We'd have to hope this doesn't serve to confuse folks who go look for a plugin there and don't find it (because maybe their sysadmin installed it to a system location instead). So it wouldn't really solve everything surrounding plugin location questions. That makes me think if a change is indeed needed, a better solution must exist.
All of that's just playing devil's advocate. Like I said, I'll submit the request and see what happens. I will also include my own suggestion for an alternative lesser feature of making sure SketchUp automatically creates the empty plugin folder in the proper user-specific location with every launch. This would solve the issue of a user drilling down through the file system to the expected folder location and not finding it (because they haven't installed any Extension Warehouse plguins, and thus it hasn't been created yet).
@driven said:
what are the chances of SU providing a migration assistant that scans all 'previous' locations and relocates 'orphaned skm's and skp's' into the appropriate User Folders...
Without having more time to consider the potential difficulties of doing this, I can't comment on it too much.
Off the top of my head, there are obviously some more complex issues to investigate, such as how to handle potential incompatibilities, duplicated filenames, files living in multiple users' directories, etc. Sometimes such a program could cause more harm than good, such as if we somehow migrate some "broken" templates or something.
I think that even if we don't implement the feature in the exact way you have in mind, there is clearly room for improvement of the user experience that comes with migrating to a new version of SketchUp. Just as with your other suggestion, I'll open an official request and we'll see what happens.
Thanks,
Andrew
-
@andrews said:
light, adding that feature could be seen as a step backwards from the sort of 'ignorant bliss' we'd prefer for the overwhelming majority of our users have about the inner workings of the plugin system.
heh.. fwiw, i don't mind digging around the file structure etc and from a user side of thing, i know a decent amount about osx in general.
but even then, i still think it's sweetest when everything about an application can be handled from within the program itself.. i mean, i've been manually installing sketchup plugins since forever but nowadays, it's mostly always via 'install extension' or scf store / trimble EW.
imo, the more you can do to keep the support file structure out of sight, the better (without completely locking the nosy user out, of course
)i guess my point is that if you have X amount of resources which could go towards teaching a user about the file structure VS. making a user need to worry less about file structure.. then it's probably better time spent on the latter..
as it is now though, it's on the fence.. way better with plugin install
..(though i still keep wanting to just drag/drop an rbz onto a sketchup window for install ) ..plugin uninstall- not so easy..i think the material browser could benefit from a better front end (or, basically anything that's going into ~/appsupport)..
apple prematurely hid the user library by default imo.. but at the same time, i see what they're getting at. -
Cheers for the reply Andrew,
a lot of this is due to the slow migration from v8 to v12, it's a different planet...
it's mostly 'power' users that are suffering, not plugin authors...
help with migration, only needs to last for a couple of versions...
I appreciate one reason to NOT migrate skms...
it would add at least 20 mins to my instals...
I've made a script that found all of my 885365 skm files...
Note to Self: I should possibly 'prune' the number of SU versions on this computer...targeting 'typical' locations reduces that dramatically...
then eliminating SU supplied copies [ rejecting any already in the v2014 SU.app folder ] drops it to 3480...
eliminating < v6 [old format] comes in at 2087...
renaming [with indicative folder-names ] and adding symlinks into an 'orphans' folder [with icons of the material]... still takes a while...once i get it all to run smoothly, I can visually chose which to move into my 'User/../Mat...' from 'Finder'.
possibly worth the effort...
john
-
@jeff hammond said:
i still think it's sweetest when everything about an application can be handled from within the program itself.. ... imo, the more you can do to keep the support file structure out of sight, the better
We agree. That's why pretty much all of my posts WRT people asking how to find the plugin folder say, "stop worrying about where it lives; we're handling it for you in the new EW!" I know it's not perfect yet, but that's the approach we're trying to take.
@jeff hammond said:
i still keep wanting to just drag/drop an rbz onto a sketchup window for install
I agree. There is an open feature request for this already and I've just +1'd it.
@jeff hammond said:
i think the material browser could benefit from a better front end
We agree. I just talked to Barry and Brad earlier today when we looked over the other thread where you mentioned materials problems. The general consensus was that it's a total mess, especially given how behaviors differ from Mac to Win. It's a nagging issue for sure and I've just opened some new bugs about this point.
Andrew
-
FYI,
SketchUcation Tools 2.6 allows you to open the plugins folder....
...you can also install plugins and extensions using the...
SketchUcation Tools > SketchUcation Archive Installer
Advertisement