Where to Store User Settings?

[TIG]

Of course you could simply use the Sketchup.read_default() & Sketchup.write_default() methods which use the PC registry OR the MAC plist ?
To make a user specific section entry you can use...
user=ENV['USERNAME'] if not user=ENV['USER']

which traps the difference in MAC/PC 'user' ID...

Then read/write a 'section' called perhaps
user_section=user+"_JF::DrawHelix"

each named after a specific tool - here I've used Jim's rehash of 'DrawHelix'...

To read a user's 'variable' for that tool using...
Sketchup.read_default(user_section, "values", defaults)

'defaults' could also be nil

To write/rewrite a user's 'variable' to a new 'value' for that tool...
current=Sketchup.write_default(user_section, "values", values)
You do have to be careful about the type of data you try store...
BUT Jim's rehash of 'DrawHelix' already uses reg_key = "JF::DrawHelix" - so we'd simply set user==ENV['USERNAME'] if not user=ENV['USER'] [as above] and then use reg_key = user+"_JF::DrawHelix"... then use v = Sketchup.read_default(reg_key, "values") and then values = eval(v) etc to extract the individual 'array' of values needed for that tools settings, AND then later save them on close with ...
Sketchup.write_default(reg_key, "values", results.inspect)

I think that the Sketchup PC 'registry keys' are saved on an individual 'current-user' basis anyway [HKEY_CURRENT_USER\Software\Google\SketchUp8\JF::DrawHelix] and therefore you wouldn't really need to use the 'user' prefix [although it does no harm to add it]... BUT I'm not sure about the MAC's equivalent 'plist' entries - if that's a global file then the 'user' prefix will serve to separate out each user's entry appropriately...

I really can't see why you need to set up your own user's 'AppData' file/folders for this ?

[Jim]

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. Why wouldn't the settings for my plugin go right in (something like) "APPDATA/Jim Foltz/JF Plugins/My Plugin Name/"

[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.