Where is Material folder for 2014 Mac
-
Not today. I've got that orange paint stripper instead. Ugh!
-
Ahhh so Dave, Lirary eh, so you have chinese puter too.
-
-
ollocks to that.
-
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.
-
Walt, this is how it is for SU8 on my Mac.
-
Thanks Dave but I'm trying to find the same but for 2014
-
Sorry. You profile says 8 so that's what I looked up.
Put your .skm files in the Materials folder under your user.
Don't make me come down there...
Well, actually I'd like to come down there and get away from the cold.
-
Ya I bet was 74 the other day only 50 today.
Thanks I got it now
-
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
Advertisement