Where to Store User Settings?

[Dan Rathbun]

@jim said:

Just wondering if it is wise to use the "APPDATA/Google/SketchUp X" sub-folder name because it is what is actually used by Google SketchUp.

(1) It's actually %(#8000BF)[%APPDATA%] in command scripts, and ENV['APPDATA'] in Ruby.

(2) This location is meant to be hidden from the user. But an Administrator can make the dir visible easily on XP, but not so easily on Win 6+. One advantage is that Windows Migration wizard can copy files from APPDATA folders when upgrading to newer OS versions, or to another computer. Note that the %(#8000BF)[%APPDATA%] path is the "roaming" profile (which is OK, especially for a network setup, where the user may logon to any one of many workstations. This is in contrast to the %(#8000BF)[%USERPROFILE%/Local Settings/Application Data] path, which is specific to a particular computer or workstation. XP does not have a environment var that points at this, but Win6+ does: %(#8000BF)[%LOCALAPPDATA%] )
IF you wish the user to easily see any of these settings, you'd need to make a "log viewer" webdialog, or a GUI dialog.

@jim said:

Why wouldn't the settings for my plugin go right in (something like) "APPDATA/Jim Foltz/JF Plugins/My Plugin Name/"

It could, ie, something like:

# within your plugin module namespace;
if RUBY_PLATFORM =~ /(darwin)/
  APPDATA = File.join('Users',ENV['USER'],'Library/Application Support')
  # or; APPDATA = File.join('~','Library/Application Support')
  # or; APPDATA = File.join(ENV['HOME'],'Library/Application Support')
else # Windows
  APPDATA = File.join( ENV['APPDATA'],'Google' )
end
SUFFIX = "Google SketchUp #{Sketchup.version.to_i.to_s}/SketchUp/Plugins"
APPDATA = File.join(APPDATA,SUFFIX)
Dir.mkdir(APPDATA) unless Kernel.test(?d,APPDATA)
PLUGDIR = 'SomeString'
SUBPATH = 'Jim Foltz/JF Plugins'
@@datapath = File.join(APPDATA,SUBPATH,PLUGDIR)
Dir.mkdir(@@datapath) unless Kernel.test(?d,@@datapath)

[Dan Rathbun]

OH.. sorry Jim... I missed the real question in your query.

You want to use YOUR OWN company name folder "Jim Foltz" instead of the "Google" dir...
.. and then whatever subfolders you wish to organize below that.

Well YES, IMHO... no problem there. Keep it separate and protected from inadvertant cleansing (such as when someone tries to cleanup their system for a "clean" reinstall of Sketchup.)

[Jim]

Here's an article with some more specific info for working with several recent versions of Windows.

What’s the Recommended Location for Application Files?

The article only confirms what has already been said here: %APPDATA% is the correct folder (or better to use your own sub-folder under %APPDATA%.)

[thomthom]

But roaming or local?

[Jim]

Why not always roaming? Is there a specific case for local?

I might use local if the file(s) were for a license key tied to a specific machine. But otherwise, I can't think of a reason not to use roaming.

[thomthom]

Yea - I wasn't sure if roaming could be used if the user where not on a domain. (I don't have any experience with that kind of stuff...)

[TIG]

ENV["APPDATA"] returns the PC User's 'Roaming' folder anyway...

[kirill2008]

I think it is possible to store user settings right in *.skp file. Why not? AutoCAD stores a lot of settings (a plenty of settings) in *.dwg file for example.
I'm not sure about problems with such approach, but it works well for some of user settings. I use "Sketchup.active_model.set_attribute" to store user settings.
Ok, it's not ideal solution of course: it increases file size, I guess. And it does not fit for user settings, that have to be insensitive for *.skp file. And a lot of excess data will be attached to each *.skp file instead of single *.ini file.

[thomthom]

@kirill2008 said:

I think it is possible to store user settings right in *.skp file. Why not? AutoCAD stores a lot of settings (a plenty of settings) in *.dwg file for example.
I'm not sure about problems with such approach, but it works well for some of user settings. I use "Sketchup.active_model.set_attribute" to store user settings.
Ok, it's not ideal solution of course: it increases file size, I guess. And it does not fit for user settings, that have to be insensitive for *.skp file. And a lot of excess data will be attached to each *.skp file instead of single *.ini file.

That would then not be User data - but Model data. Two very different things.

[TIG]

User data specific to Sketchup can be stored with Sketchup itself in the Registry [Plist on Mac] ?
Sketchup.write_default(section,variable{,optional_default}) Sketchup.read_default(section,variable,value)
You obviously need to 'compile' the value[s] to write and read back in specific ways.
If there are 'many things' to keep across sessions then a saving them into a Users/Name/AppData/Roaming/ Sketchup subfolder, inside a tool specific subfolder or ini file etc would also be possible - not sure about Mac alternative...

[kirill2008]

@thomthom said:

That would then not be User data - but Model data. Two very different things.

Looks like I interpreted thread subject in a context of my own thoughts
I mean, I was going to suggest to use template for storing user settings data.

It is less elegant than just click "OK" button in "Settings" dialog of the plugin, of course But the user can save his own presets in template file, add description to it, then it will be possible to revert back to any previously saved configuration.

UPD.
The point is that I was thinking about abstract "application user" not the operating system user. Application means plugin here.
So I thought that application (plugin) usually runs "system wide" (not in "per user mode") and the problem is what is the best way to persist application settings (i.e. user preferences *application user here again).
Storing plugin settings right in document allows user preferences persistence across different machines and even across operating systems in theory (when I say "user" I mean plugin user). So user can take his *.skp file anywhere and continue working with it on any device that has SU and plugin and he does not have to care about configuring plugin again on each device.