SketchUp 2014

[tomot]

I don't have a MAC. One of my Customers wants to know where the plugins directory is located on a MAC, for SU 2014 ?

---

[bmike]

Did they move it on the Mac? Otherwise its in Application Support...

---

[AndrewS]

@bmike said:

Did they move it on the Mac? Otherwise its in Application Support...

Your intended clarification may be confusing, as there are multiple application support directories.

The location of the plugin folder for SU8 and before was buried inside the root-level app support folder:
[pre:3fpbb2ln]/Library/Application Support/Google SketchUp 8/SketchUp/plugins[/pre:3fpbb2ln]This is a system controlled (i.e. machine-wide) location that requires root privileges to modify, and is therefore a very unfriendly way of doing things.

For the 2013 release, we moved the preferred plugins location inside the user's personal app support folder. It remains the same for 2014. In that sense, as of the 2014 release, Windows and Mac are now both the same in preferring to have plugins within each user's personal Plugins folder instead of in a shared location.

The full pathname for Mac plugins in 2013 and 2014 is:
[pre:3fpbb2ln]/Users/<username>/Library/Application Support/SketchUp xxxx/SketchUp/Plugins/
aka
~/Library/Application Support/SketchUp xxxx/SketchUp/Plugins/[/pre:3fpbb2ln] Where of course, "xxxx" is 2013 or 2014.

I believe the code still looks for plugins in /Library as a secondary location, but as is the case with Windows, you really should use the user-specific location instead of the system-wide location unless you have a really good reason to do otherwise.

Andrew

[Dan Rathbun]

@andrews said:

I believe the code still looks for plugins in /Library as a secondary location, but as is the case with Windows, you really should use the user-specific location instead of the system-wide location unless you have a really good reason to do otherwise.

And the same on Windows for the common "AllUsersProfile" / "ProgramData" plugins folder.

Usually, only IT administrtors in company or educational settings would install plugins into these paths.
But even plugins installed sytem-wide like this, still need to save settings using Sketchup::write_default or in files saved to the user path. So there could be a sub-folder in the user "Plugins" folder created by such a plugin, used for each specific user's settings.

[tomot]

@andrews said:

@bmike said:

Did they move it on the Mac? Otherwise its in Application Support...

Your intended clarification may be confusing, as there are multiple application support directories.

The location of the plugin folder for SU8 and before was buried inside the root-level app support folder:
[pre:2w7fink1]/Library/Application Support/Google SketchUp 8/SketchUp/plugins[/pre:2w7fink1]This is a system controlled (i.e. machine-wide) location that requires root privileges to modify, and is therefore a very unfriendly way of doing things.

For the 2013 release, we moved the preferred plugins location inside the user's personal app support folder. It remains the same for 2014. In that sense, as of the 2014 release, Windows and Mac are now both the same in preferring to have plugins within each user's personal Plugins folder instead of in a shared location.

The full pathname for Mac plugins in 2013 and 2014 is:
[pre:2w7fink1]/Users/<username>/Library/Application Support/SketchUp xxxx/SketchUp/Plugins/
aka
~/Library/Application Support/SketchUp xxxx/SketchUp/Plugins/[/pre:2w7fink1] Where of course, "xxxx" is 2013 or 2014.

I believe the code still looks for plugins in /Library as a secondary location, but as is the case with Windows, you really should use the user-specific location instead of the system-wide location unless you have a really good reason to do otherwise.

Andrew

Andrew:
I think the common courtesy would have been to respond to my inquiry directly. Do you not think it would be appropriate to include a statement in the API that I can direct customers to where SU 2014 users, on Apple iMac's should expect to find the plugins folder?

It would be really helpful to have an official reference from Trimble I can point to. I'm starting to lose credibility! Already one irate SU2014 Customer is upset by scripts are not SU 2014 compliant. Even after explaining I no prior knowledge about SU 2014. He's telling me my scripts should all be in .RBZ format and should be installable in the Extension menu.

You guys are creating a nightmare, not a solution. Solutions require critical thinking
Unfortunately you can't buy critical thinking, it only develops after one has been on the planet for a very long time.

[AndrewS]

@tomot said:

I think the common courtesy would have been to respond to my inquiry directly.

Had there been no other responses to your inquiry, then yes, I would have responded to you directly. However, given the potential for hundreds of other users to see this thread at a later date, I chose to respond in a way I thought would benefit the greater good, by asserting my statements alongside a potentially confusing answer to your question that came from another user. No disrespect was intended.

@unknownuser said:

Do you not think it would be appropriate to include a statement in the API that I can direct customers to where SU 2014 users, on Apple iMac's should expect to find the plugins folder?

That's a fantastic idea. Luckily several other people have invested significant time and resources in such documentation. Here's just one such example from the loading instructions on our developer site.

@unknownuser said:

Customer is upset by scripts are not SU 2014 compliant.

Customer needs to be patient and understand that software development takes some time and effort, especially when it comes to adapting existing software to work with a new product. While significant effort was expended to inform the most prolific plugin developers of the impending changes and involve them in an early "alpha" test of the Ruby 2.0 interface well before we launched 2014, given the vast number of plugins that exist in the world, it was not possible for us to involve every single plugin author. Therefore, a great many people such as you are in the position of needing to update their plugins now in response to our most recent release.

The only comfort I can offer is that this action-reaction, or release-update cycle is not at all unique to SketchUp. It is a reality that exists throughout the entire software development ecosystem, for plugin developers, web designers, hardware manufacturers, etc.

I would tell your customers that if using your plugin is an absolutely essential part of their process (one which they can't work around in any other way, such as exporting the file to 2013 format and using your plugin there), then they need to carefully evaluate that as part of their migration strategy. They must then make sure they have either a replacement solution or a reasonable workaround in place before upgrading. Otherwise it's best to just hold off upgrading SketchUp until their dependencies are completely sorted.

@unknownuser said:

He's telling me my scripts should all be in .RBZ format and should be installable in the Extension menu.

There are various ways to handle making your scripts as easy as possible for your users to find and install, but I would recommend that you adapt your plugins to the standards revealed to the developer community when we launched the SketchUp Extension Warehouse almost a year ago, and do what's necessary to get them published there. It's free and pretty straightforward to do, in addition to being a great way to make your plugins easier to discover and more readily available to the SketchUp-using public. Is that the only way to do it? No, but it is the officially supported method.

@unknownuser said:

You guys are creating a nightmare, not a solution. Solutions require critical thinking

You'll forgive me if I don't share your opinion on this. From as early as 2008 (against difficult opposition by our Google overlords), I was an advocate for the creation of the extension warehouse, so I can't begin to tell you how excited I was when it became a reality last year. In fact, I think we've done a phenomenal job with the extension warehouse and its associated developer documentation.

@unknownuser said:

Unfortunately you can't buy critical thinking, it only develops after one has been on the planet for a very long time.

I fail to see how levying such character judgments is expected to motivate me or my colleagues toward further action. I'd prefer we steer clear of such unproductive endeavors.

[Dan Rathbun]

The Mac example at the bottom of that loading info page has an error.
The directory variable is different in the last statement.

[ken28875]

So now that SketchUp 2014 is working after I deleted the Plugins folder and reinstalled the program, I encountered another issue:

Thanks for your help in solving this mystery disappearance.

_KN

[jiminy-billy-bob]

If no plugin initialize, the plugins menu is not created.

[TIG]

You need a Plugins folder to install the plugin.
If there is a plugin in the Plugins folder the menu is made.
Where did you install it if there was no Plugins folder

[AndrewS]

@dan rathbun said:

The Mac example at the bottom of that loading info page has an error.
The directory variable is different in the last statement.

Thanks for pointing that out. The extensibility team is fixing it.

Andrew

[Dan Rathbun]

@andrews said:

@dan rathbun said:

The Mac example at the bottom of that loading info page has an error.
The directory variable is different in the last statement.

Thanks for pointing that out. The extensibility team is fixing it.

No problem. Another thing.

Generally the Plugins path is for SU2014, (since SU2013 for the Mac.)

The Windows Plugins path shown is for Windows 6+. It differs on XP (v5.1).
(Perhaps use: " %AppData%\SketchUp\SketchUp [n]\SketchUp\Plugins" to be more generic.)

Or maybe some expandable sections to show the paths for older versions ?

[Dan Rathbun]

@pixero said:

I just installed SU 2014 Pro in demo mode on my brand new laptop with windows 8.1.
Now i´m getting a popup saying:

@unknownuser said:

Unable to update the evaluation time. Make sure that C:\ProgramData\SketchUpSketchUp 2014\SketchUp2014.lf is writable.

I just installed everything into its default location. I have checked that file and it is writable as far as I can see in the info.

What to do?

The path string posted is not correct:
" C:\ProgramData\SketchUp\SketchUp 2014\"

The filename is usually: SketchUp14.lf

[tomot]

@andrews said:

@unknownuser said:

Unfortunately you can't buy critical thinking, it only develops after one has been on the planet for a very long time.

I fail to see how levying such character judgments is expected to motivate me or my colleagues toward further action. I'd prefer we steer clear of such unproductive endeavors.

Thanks for your detail response, I apologize! my last quote was not directed at you, it was simply an observation, and in hindsite should have been part of a larger discussion but which is totally out of place at this forum.

[Pixero]

@dan rathbun said:

@pixero said:

I just installed SU 2014 Pro in demo mode on my brand new laptop with windows 8.1.
Now i´m getting a popup saying:

@unknownuser said:

Unable to update the evaluation time. Make sure that C:\ProgramData\SketchUpSketchUp 2014\SketchUp2014.lf is writable.

I just installed everything into its default location. I have checked that file and it is writable as far as I can see in the info.

What to do?

The path string posted is not correct:
" C:\ProgramData\SketchUp\SketchUp 2014\"

The filename is usually: SketchUp14.lf

Sorry, my typo, I just typed it in by hand.

[Pixero]

Hi!

I just installed SU 2014 Pro in demo mode on my brand new laptop with windows 8.1.
Now i´m getting a popup saying:

@unknownuser said:

Unable to update the evaluation time. Make sure that C:\ProgramData\SketchUp\SketchUp 2014\SketchUp14.lf is writable.

I just installed everything into its default location. I have checked that file and it is writable as far as I can see in the info.

What to do?

Edited a typo.

[Dan Rathbun]

@Pixero: In the Ruby Console (even in SU2013 if you cannot start SU2014,) try:

Kernel::test(?d,"C:/ProgramData/SketchUp/SketchUp 2014")

If that returns true,

File::exist?("C:/ProgramData/SketchUp/SketchUp 2014/SketchUp14.lf")

If that returns true, try:

File::writable?("C:/ProgramData/SketchUp/SketchUp 2014/SketchUp14.lf")

and

File::writable_real?("C:/ProgramData/SketchUp/SketchUp 2014/SketchUp14.lf")

Lately, are you running SketchUp2014 in Administrative mode ?
Right-click your SketchUp2014 icon, choose "Properties" > "Advanced" button.
Is "Run as Administrator" checked ?

[Pixero]

First, thanks for the hands on help.

I get true for all of them.
I haven' changed anything. It's a brand new machine.
So SketchUp should be run in admin mode? I thought the new locations of files were a fix for that?

[AndrewS]

@pixero said:

So SketchUp should be run in admin mode? I thought the new locations of files were a fix for that?

The answer is that it's complicated, but yes, running in admin mode may be advisable. You're right that we've invested a lot of effort trying to straighten out plugin paths and whatnot to work without admin privileges. Licensing is a separate issue we haven't fully addressed yet. Our ancient licensing code can be a real source of frustration, which we hope to alleviate someday by completely reworking it, but it's difficult to find time for everything at once.

We tested licensing on Windows 8.1 without having to do anything special regarding admin privileges and never saw this issue. Nevertheless, we have some ideas...

Try uninstalling SketchUp 2014. Then re-run the installer, making sure to choose "Run as Administrator" when you do. The installer is supposed to automatically elevate to admin privileges (I should know; I wrote it), but perhaps it's not doing so on your machine.

After installing as admin, try running SketchUp, at least the first time, with admin privileges. Maybe that'll make a difference.

The other note I got from our licensing expert is that although you're seeing a very specific message about the license file not being writable, there are unfortunately a few other esoteric reasons why that message may arise which aren't exactly a result of the named file not being writable. That's certainly confusing, and obviously something we need to try to work out in the future.

Please try the reinstall and let us know how it goes.

Andrew

[Frederik]

Jan, FWIW, I had the exact same issue with both SU8 and SU2013...
Asked the SU support, but didn't really help...
As soon as I entered the serial number, that message disapeared...