Safe place to store user-defined parameters

Dan Rathbun

@tig said:

On a PC there will be lots of app-specific folders made in
C:/users/username/appdata/local

FYI

SketchUp saves the user's " %(#8040BF)[session.dat]" file to the %APPDATA% path (not the %LOCALAPPDATA% path.)

ie:

XP(Win 5.1 C:\Documents and Settings\*<username>*\Application Data\SketchUp\SketchUp 2013\SketchUp

Win 6+: C:\Users\*<username>*\AppData\Roaming\SketchUp\SketchUp 2013\SketchUp

BUT... The main reason that these paths have not yet been exposed in the SketchUp Ruby API.. is that on Windows if the username contains unicode characters... Ruby 1.8.x cannot handle them with the standard String class.

This is why we had hoped (in vain, it seems,) that this next SU version would have Ruby 1.9.x or 2.0.x

Dan Rathbun

@fredo6 said:

It seems that ENV["LOCALAPPDATA"] is always defined and this directory would be OK.

Again, sorry.. not exactly correct.

%(#BF00BF)[%LOCALAPPDATA%] is defined only on Windows version 6 and higher
(which means not on XP which is version 5.1)

So in Ruby (on Windows)

unless LOCALAPPDATA = ENV["LOCALAPPDATA"]
  # evals false because it's nil, we must be on XP, so;
  LOCALAPPDATA = File.join( ENV["USERPROFILE"], "/Local Settings/Application Data" )
end
# Otherwise on Windows ver 6+, and %LOCALAPPDATA% is defined, as;
# "C;\Users\<username>\AppData\Local"

ADD: It is smart to convert the backslashes to Ruby forward slashes with gsub("\\","/")

TIG

@aerilius said:

What speaks against using an iterative search?


> # Find an existing and writable directory where to store user data.
> dir = [
>   ENV["LOCALAPPDATA"],                    # Windows ver. 6+
>   ENV["APPDATA"],                         # Windows
>   File.join(ENV["HOME"].to_s, ".local", "share"), # Free desktop standard
>   File.join(ENV["USER"].to_s, "Library", "Application Support"), # OS X
>   "."                                     # Fallback; exists always, where as ENVs may not.
> ].compact.map{ |path| File.expand_path(path) } # expands links and path separators
>  .find{ |path| File.exists?(path) && File.writable?(path) }
> DATA_DIR = File.join(dir, "MyPlugin")
>

I already posted something similar [but with a bigger choice of fall backs] for deciding on your 'TEMP' folder... AND on PC or MAC you can write subfolders/files one folder 'up the tree' from the TEMP folder, so you can put any custom-subfolder there...
I've never had a failure [yet ].
Many programs have freely writable folders in these locations...
On a PC it's the 'C:/Users/Username/AppData/Local/' folder [which in turn contains your 'Temp' folder], on a MAC is a system generated 'seemingly-gobbledygook-folder-name-tree' [which in turn contains your 'T'[emp] folder]...

Here is some explanation of a PC's three 'User Folders'...

Roaming is the folder that would be 'synchronized' with a server if you had logged into a domain with a 'roaming profile' (enabling you to log into any computer in a domain and access your favorites, documents etc).
For example: Firefox stores its information here, so you could even have the same bookmarks between computers with a roaming profile.

Local is the folder that is specific to that computer.
Any information here would NOT be synchronized with a server.
This folder is equivalent in XP to C:\Documents and Settings\User\Local Settings\Application Data.

LocalLow is effectively the same as the Local folder... but it has a lower 'integrity level'.
For example: when 'protected mode' is 'on' IE8 can only write to the LocalLow folder.

fredo6

Anyone has an idea if ENV["LOCALAPPDATA"] is defined on Mac?

Fredo

driven

%(#FF0000)[**# SU returns =>

ENV["LOCALAPPDATA"]
nil**]

fredo6

@driven said:

%(#FF0000)[**# SU returns =>

ENV["LOCALAPPDATA"]
nil**]

hanks
And what about ENV["APPDATA"] ?

driven

%(#FF0000)[**# SU returns =>

ENV["APPDATA"]
nil**]

 ENV
{"PATH"=>"/usr/bin;/bin;/usr/sbin;/sbin",
 "TMPDIR"=>"/var/folders/rp/b9k42l5x7xngx_8tckgs0zdr0000gn/T/",
 "SHELL"=>"/bin/bash", "HOME"=>"/Users/johns_iMac",
 "USER"=>"johns_iMac",
 "LOGNAME"=>"johns_iMac",
 "SSH_AUTH_SOCK"=>"/tmp/launch-0•••••/Listeners",
 "Apple_Ubiquity_Message"=>"/tmp/launch-RCcmJV/Apple_Ubiquity_Message", "Apple_PubSub_Socket_Render"=>"/tmp/launch-BeHprC/Render",
 "DISPLAY"=>"/tmp/launch-HUlKie/org.macosforge.xquartz;0",
 "IG_ROOT"=>"/Applications/SketchUp 2013/SketchUp.app/Contents/Resources",
 "SHLVL"=>"14",
 "PWD"=>"/",
 "_"=>"/usr/bin/open",
 "__CF_USER_TEXT_ENCODING"=>"0x1F5;0x08000100;0\n",
 "COMMAND_MODE"=>"unix2003"}
>

fredo6

Thanks John.
I m afraid I'll store default parameters in /tmp, which seems to be only safe place defined on Mac (TMPDIR does not look very stable across OSX session.

Fredo

driven

TMPDIR is only cleared if coded to do so, /tmp is for temporary files and is purged on reboot....

SketchUp use /tmp for active tool log file , and TMPDIR for crash-logs [without a cap]

Aerilius

That is a temporary folder. We have to ask John how long temporary files stay there, but usually one cannot assume that temporary files stay until after a reboot. It is only exceptional for Windows that temporary files stay for "long" (I once found years old files).

driven

@aerilius said:

That is a temporary folder.

A lot of mac users never reboot, so for them they are semi-permanent, for the life of a software release or until SU 'bug-splatts'.

however, most the files in there, overwrite themselves regularly... etc. they are meant to be momentary.

Unfortunately for me, I learnt this the hard way by loosing my entire dev folder that I had in there at one point.

now I use it for the images/files needed only during a session, even then I write backups to my 'Plugins' folder, which I only overwrite on next use of the tool.

access, FIFO is meant to be faster, which is good for temporary logging, and image compositing.

john

slbaumgartner

Guys,

Please forgive an old fart for a brief history lesson.

The tmp, temp, and similar directories/folders came into being as a means for a program to create a working file during a run without concern for the physical location of the file. The intent was that the file would no longer be needed after the program exits and could be cleaned up by the OS at any time after the program closes. The fact that an OS may have a lazy cleanup policy that lets such files hang around for a long time is not a good excuse for ignoring the basic idea that these files are meant to be temporary! These are not reliable places to store persistent parameters. The policy could change at any time!

Steve

fredo6

@slbaumgartner said:

Guys,

Please forgive an old fart for a brief history lesson.

The tmp, temp, and similar directories/folders came into being as a means for a program to create a working file during a run without concern for the physical location of the file. The intent was that the file would no longer be needed after the program exits and could be cleaned up by the OS at any time after the program closes. The fact that an OS may have a lazy cleanup policy that lets such files hang around for a long time is not a good excuse for ignoring the basic idea that these files are meant to be temporary! These are not reliable places to store persistent parameters. The policy could change at any time!

Steve

I understand.
But where can the persistent parameters be saved on Mac?
What are other applications doing?

Fred

driven

Apple applications must be self contained to meet the 'Approved' status that SU is attempting to gain.

If they don't 90% of mac users will get a warning that 'SU' is 'unapproved' and 'potentially harmful', this puts a LOT of people off.

That's why everything is moving back into SU's App Folder in the User space it's also why they added Extension Manager.

As far as Apple are concerned Users should only ever need to access an app from within the app and should not be required to ever need to add anything externally.

For it's Users. SU provides the all the paths you need to supply an SU Plugin to run on a mac, use them.

If Users have move stuff around, that's their problem and SU and Apple are happy.

If your developing on a mac, you can change permissions to get around some of the sandboxing and you can then compile and 'package' helpers so Uses can benefit from your workarounds, if your on a PC it's a nightmare to take alternate routes.

If you keep all your files in your Plugins Directory and the SU at supplied external paths, I can't see a problem.

SU and Apple are happy, you can be happy too.

john

Aerilius

That's very easy, if the OS vendor finger-points at the one who plays bad, then everyone has to try to play nice.
User's personal data (settings on one side and user data (works, templates, user-managed plugins on the other side) belong to the user level also on other operating systems (of which Windows is only one special example, I even do not use Windows). Then there would not be permission problems. It has often enough been pointed out that plugins in the Windows version SketchUp are in the wrong place.

The permission problem story on Windows has its origin that it was designed as a single user OS at a time when also security models where basic or non-existing. Microsoft decided to keep compatibility instead of "deprecating" older applications (or applications that don't follow the new rules), which lead to this inconsistency.

slbaumgartner

@fredo6 said:

@slbaumgartner said:

Guys,

Please forgive an old fart for a brief history lesson.

The tmp, temp, and similar directories/folders came into being as a means for a program to create a working file during a run without concern for the physical location of the file. The intent was that the file would no longer be needed after the program exits and could be cleaned up by the OS at any time after the program closes. The fact that an OS may have a lazy cleanup policy that lets such files hang around for a long time is not a good excuse for ignoring the basic idea that these files are meant to be temporary! These are not reliable places to store persistent parameters. The policy could change at any time!

Steve

I understand.
But where can the persistent parameters be saved on Mac?
What are other applications doing?

Fred

On a Mac under OS X, the conventional/approved place for user configuration parameters is a .plist file in ~/Library/Preferences. The file name starts with a dot-separated sequence like a reversed domain name that identifies the relevant app, and then adds more segments to specify what about that app. For example, com.trimble.sketchup.fredo.magictool.plist.

There are API calls for storing and retrieving info from plist files, but I don't think they are exposed in the SU Ruby API, so using them would probably require an external helper program or added Ruby file to get at plists in a clean way (Apple discourages reading and writing the files manually). I have no experience with them, but there are some plist generator and parser Ruby files on source forge.

driven

@slbaumgartner said:

but I don't think they are exposed in the SU Ruby API, so using them would probably require an external helper program or added Ruby file to get at plists in a clean way (Apple discourages reading and writing the files manually). I have no experience with them, but there are some plist generator and parser Ruby files on source forge.

@Steve,
that's exactly what this pair does, your entry in the com.sketchup.SketchUp.plist

 result = Sketchup.write_default "section",
   "variable", "my_value"
result = Sketchup.read_default "section",
 "variable", "default"

in the .plist that shows as

	<dict>
		<key>variable</key>
		<string>"my_value"</string>
	</dict>

john

slbaumgartner

@driven said:

@slbaumgartner said:

but I don't think they are exposed in the SU Ruby API, so using them would probably require an external helper program or added Ruby file to get at plists in a clean way (Apple discourages reading and writing the files manually). I have no experience with them, but there are some plist generator and parser Ruby files on source forge.

@Steve,
that's exactly what this pair does, your entry in the com.sketchup.SketchUp.plist

 result = Sketchup.write_default "section",
>    "variable", "my_value"
> result = Sketchup.read_default "section",
>  "variable", "default"
>

in the .plist that shows as

	<dict>
> 		<key>variable</key>
> 		<string>"my_value"</string>
> 	</dict>

john

Which leaves me somewhat confused about what fredo is seeking to accomplish. Unless you are determined to keep your info somewhere separate from SketchUp's "defaults", what's the problem with using these methods?

Steve

Aerilius

I think for simple configurations (keys, values etc.) Sketchup.write_default is the ideal solution because it uses the API, and the API makers care about that it works.
But sometimes one wants to store more data or even files, so called "user data" (vs. "config").
I don't know what Fredo has in mind.

fredo6

Aerilius is right.

There are situation where you can persist parameters in the Sketchup section of the registry and some where this is not desirable or not possible.

My scripts use the registry for some parameters, and files for some others. By principle, it is never advised to overload the registry of a system, as it may easily get corrupted.

In addition, there are cases where you simply need to store files, not data, say components, materials, etc... that are created on the fly by the plugin based on user inputs.

Windows makes provision for a 'application data' location on disk. On MAC, there must also be a 'natural' place where such user files are stored. For instance, Microsoft Office use templates and other option files and they are not stored in the registry.

I think Sketchup cannot continue to propose only the Sketchup root directory to store files underneath. All new versions of operating systems are very picky on security and won't let you access this area from a program or embedded script like Ruby.

The objective of this post was to see whether the developer community would have ideas and would agree on a convention, because I assume many scripts are in the same situation.

Fredo