Where is Material folder for 2014 Mac
-
@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