Safe place to store user-defined parameters

Aerilius

Normally the "visible" user's home directory is reserved for files that the user intentionally created, and programs should not create there any content without that the user agrees.

As has been mentioned, the temporary folder is not ideal. Although on Windows temporary files can survive for many years, we should not generally assume that they survive a reboot. I'm not sure if the parent folder of the temporary folder is a good idea (John, on OS X and other unices the parent of /tmp would be root / ?)

The ideal place would be to use the standard folder that is supposed to be used for application data. This can be depending on the operating system in ~/.local/share etc. or on Windows %AppData% which is under XP X:\Documents and Settings\[username]\Application (localized!) and under Vista,7,8 X:\Users\[username]\Data AppData\Roaming. There seems to be a ruby environment variable ENV['APPDATA'] but it's not cross-platform and it's known not to be reliable on different Windows versions (this needs to be tested). The prefered way is over the C# API: http://stackoverflow.com/questions/2588636/windows-application-data-directory

Dan suggested that the SketchUp API should provide a method to get that folder path.

fredo6

Thanks for your feedback

On Windows, most commercial applications precisely create a folder in the directory pointed to by ENV["HOME"]. This is the case of Office Microsoft applications, Camtasia and many others. Usually they store parameters files and some other user-related resources. The folder is usually created at installation time. The applications are not explicit either on what they put there.
--> So Trimble could follow this practice as well.
The temp directory has the small drawback that it can be erased. I use it already for transient files (like .html) and all log files. But here I am talking more of script parameters that are set up by the users to remain persistent (like which icon are visible in toolbars).

I will however, as suggested by TIG, use the tmp folder until Trimble does something about it

Fredo

TIG

To reiterate...

If you use ENV to get the user's TEMP/TMP folder... on PC its 'Temp' path is:
C:/Users/Username/Appdata/Local/Temp
On a PC there will be lots of app-specific folders made in
C:/users/username/appdata/local
So adding another one for your own tools 'XXX' should not be an issue.
C:/users/username/appdata/local/XXX

On a MAC the equivalent TMPDIR path to the 'T' folder is something like:
/var/folders/rp/b9k42l5x7xngx_8tckgs0zdr0000gn/T
So again making tool-specific folder 'XXX' in its parent folder should be possible...
/var/folders/rp/b9k42l5x7xngx_8tckgs0zdr0000gn/XXX

On MAcs
/tmp
is NOT the usual returned ENV path, although it is a fall-back if all else fails...

thomthom

@fredo6 said:

On Windows, most commercial applications precisely create a folder in the directory pointed to by ENV["HOME"]. This is the case of Office Microsoft applications, Camtasia and many others. Usually they store parameters files and some other user-related resources. The folder is usually created at installation time. The applications are not explicit either on what they put there.
--> So Trimble could follow this practice as well.

I hate it when applications create folders like that. And certainly if they contain temp data of any type of data the user is no suppose to handle.

thomthom

@fredo6 said:

The temp directory has the small drawback that it can be erased. I use it already for transient files (like .html) and all log files. But here I am talking more of script parameters that are set up by the users to remain persistent (like which icon are visible in toolbars).

If it's persistent files then the temp folder would not be fit. As TIG mention, under Windows the appdata folder would be appropriate. Out of sight from users. Not quite sure about OSX...

danielbowring

Maybe something like:

def appdata_dir()
    dir = ENV['LOCALAPPDATA'] || ENV['APPDATA'] || '~/Library'
    return dir if File.directory?(dir)
    return Sketchup.find_support_file('plugins')
end

Just remember make a (unique) directory for yourself.


def author_appdata_dir(author_name, make=true)
    dir = File.join(appdata_dir(), author_name)
    Dir.mkdir(dir) if make && !File.directory?(dir)
    return dir
end

Dan Rathbun

@fredo6 said:

1) On Windows, most commercial applications precisely create a folder in the directory pointed to by ENV["HOME"].

**NOT TRUE

Why? Because %(#BF00FF)[%HOME%] is NOT defined under Windows.**

I have installed so many versions of MS Office, on so many machines I've lost count.
Never have I seen MSO create directories in the user's root dir.
Always down in the AppData path, or in the Common Files path.

Just because some software does it incorrectly (such as SketchUp,) does not mean WE should.

Dan Rathbun

I like DanielBowring's ideas EXCEPT I'd rather the paths be set as constants in some suitable namespace, so they can be mixed into author namespaces.

Something like:

SuPath::APPDATA SuPath::TEMP

If the Trimble TEam were to add them into the API code, then likely the constants would be defined within :
Sketchup::Path submodule nesting.

SO like:
Sketchup::Path::APPDATA Sketchup::Path::TEMP..., etc.

Then we could mixin the constan ts into our local submodules if we wished to...

module Author
  module SomePlugin

    include(Sketchup;;Path)
    # all Sketchup;;Path module's constants are now accessible

    @@dir = File.join( APPDATA, "Author_SomePlugin")
    unless File.directory?( @@dir )
      File.mkdir( @@dir )
    end

  end # module SomePlugin
end # module Author

fredo6

@dan rathbun said:

@fredo6 said:

1) On Windows, most commercial applications precisely create a folder in the directory pointed to by ENV["HOME"].

**NOT TRUE

Why? Because %(#BF00FF)[%HOME%] is NOT defined under Windows.**

Correct. I have one PC where it is not defined, and one where it is defined. So it is not reliable.
Likewise, I have one PC where Microsoft folders are both in Document and Local, and one where it is only in Local. Camtasia seems to use both locations (AppData is used for autosave)

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

However, I don't know what it corresponds to on OSX.

More generally, Sketchup should make provision of a data folder where it is advised that scripts put their persistent data, so that

it can be safely stored without roblem of access rights
it is user related.

I observe that Trimble is now paying more attention to scripts and that may be a suggestion for a next maintenance release or version.

This thread is just about discussing how script writers should be collectively organized.

Fredo

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