Safe place to store user-defined parameters

thomthom

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

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