A proper location to save Plugin Data & Settings?

Developers Ruby API
1

Continuing the discussion from Can UI.openpanel show the Plugins directory on OS X?:

Not quite correct. It is a path for user specific application data.

Except that since 2014 the plugins ARE in the User path. They are considered user files.

We needed them moved into the user path because we were accessing them directly, moving them around, etc.

But I understand, for the non-developer, and non-power users who know only clicking an “Install Plugin” button, that they wouldn’t be getting into this folder. Which is what the the application OEM usually wants.

The ones to not touch are the ones in the %ProgramData% path.

So where to write extension settings if not in the extension’s folder and not in the registry ?

We could go up several folder levels and create our own version independant “company” folder. Let us call the user “Dan”, the plugin “Widget” and the developer / company “SuperGeek”.
On Windows the application data path is: %AppData%
Which is: C:/Users/Dan/AppData/Roaming/
On Windows the Plugin is here:
%AppData%/SketchUp/SketchUp 2015/SketchUp/Plugins/SuperGeek_Widget
The first folder is a company folder (the DevTeam chose to go with the Trimble division name, just in case SketchUp gets sold again, I suppose.)
The second folder is the versioned folder, the third is the application folder (there is also a “LayOut” and a “StyleBuilder” folder.)
The fourth folder is the “Plugins” folder, and the last is the specific extension folder.

Some developers might attempt to stay within the “SketchUp” folder hierarchy, by using a path like:
%AppData%/SketchUp/SuperGeek_Widget
or
%AppData%/SketchUp/SuperGeek/Widget

To be totally correct “SuperGeek” should consider himself a ‘company’ and be outside of the entire “SketchUp” company folder hierarchy.
So his data settings path would be like:
%AppData%/SuperGeek/Widget
His settings would be version independent of the SketchUp version, and not need any migration when the user updates SketchUp. (Provided that the format for his extension settings do not change.)

This is why I always tell new developers not to use trademarked names for their developer namespace module name. It could clash with folder name by the actual trademark owner, in the %AppData% folder.

I suppose, if we could all agree upon an appropriate folder name, we could create a specific sub-folder of the %AppData% folder, to serve for only SketchUp Extension or Plugin settings.

What about %AppData%/SketchUpPluginData ?
or
how about sub-folder of %AppData%/SketchUp like:
%AppData%/SketchUp/ExtData ?

2

@tt_su: Please,
(1) open Layout
(2) Edit (menu) > Preferences…
(3) Folders (tab)

Explain how your philosphy holds regarding the use of the second (user) paths in the “Templates” and “Scrapbooks” settings ?

AND… is there an official “position paper” on this subject in the KnowledgeBase or elsewhere ?

3

+1

hm… I’m not that familiar with LayOut to be honest. Maybe @Marc got some input?

@jody - do we have any articles on the user paths SketchUp and LayOut use?

4

We don’t have any explicit articles detailing install paths, though we have paths detailed in various installation and migration articles.

I’ve long expressed my belief that anything that is a user-level data save should be in Documents (Mac) and My Document (Windows) so we can avoid the permissions “junk” that comes with trying to tweak the ProgramData folder, or under the Profile data on Windows. Just skimming this thread I’m not sure that’s applicable in this case, but I still favor it. (c;

Technically though, Dan has the right of it… AppData is where all the user specific data would go. I like %AppData%/SketchUpPluginData

5

Why’s that?

For my upcoming Skatter extension, I have a content library. It’s mainly content that people will render. There are proxies linking to external files and textures.
In case of network rendering, I need to have the library content located in the same path on all machines. That’s why I’m using the %ProgramData% path.

Shouldn’t I? What could be a better solution in my case?

6

No that is a use for which that path is meant.

We are talking about the User specific settings and / or use data.

What you are talking about is common plugin resources, which are part of the plugin package.

And it takes Admin privileges to write resources to that “system” path.

7

Thanks for your answer, Dan.

So I’m heading to issues with users not being able to install my plugin? I’m using an exe installer for the library part.

(PS : Sorry you had to poke through my messy code of Layers Panel, recently. I hope you didn’t tear your hair out too much :stuck_out_tongue: )

8

Yes you might be. But you could always throw together a test package, so non-Admin users could test it and see.

It is normal however that Administrators do the software installations, OR that the users run the install with elevated privileges.

The only reason to write plugin resources there in the %ProgramData% path, is to provide common resources to multiple users on the same machine. The users would not have a choice whether or not a plugin was installed or not. But since the “switch” is saved in each user’s registry hive, each can decide whether it loads for them.

If you are not installing in a business or educational environment where more than one user shares the workstation, then it can complicate matters. (But the flip side is, that it can also simplify matters for IT Departments in those multi-user environments.)

9

The plugin itself will still be located in the usual path (userdata/blabla), it’s just the library.

Thanks again.

10

Yes, well you have to decide whether it is worth having non-Admin users go through a multi-step install process.

IT geeks will already know how to manually set up a shared install in %ProgramData%.