Safe place to store user-defined parameters

TIG

Fredo

I have the greatest respect for you.
You coding skills eclipse mine.
We have had this discussion elsewhere...
You seem obsessed with this issue, when it is resolved quite straightforwardly...

Why can you not find the user's 'TEMP' folder - this is easily found from ENV etc... for ANY OS ?
This folder should ALWAYS be writable ?
If it is NOT we have NO hope
In that you can make your own folder[s] to store your own tools' 'temporary' data.
Sharing a folder with others would eventually lead to cross-over confusion...
There is already a shared 'TEMP' folder !
Contents in your own 'temp' subfolder are by their very nature transient [TEMPorary].
A system-cleanup may delete them.
So... if you need to store a user's tool-data more permanently then step up one in that folder-tree and make your tool's folder in the same folder as the TEMP folder... this tree level should also be writable... and so you can also make your own tool's folder there, in this case containing permanent data too: a system cleanup will ignore it...
I already do it, will no reported issues...
So why reinvent the wheel ?

driven

to start the ball rolling

SketchUp is a registered trademark of Trimble.
they spell it both ways and I don't think 'we' as a group can advocate it's usage.
as an aside DEFPARAM_Dir is one of the only Folders on my mac the is so UPCASED, though most are Capitalised.
I think we have it on the mac now, it's called "Plugins" but there should also be "Tools", "Materials", etc. in the same folder and there is nothing to stop your plugin adding "LogFiles" or similar.

I'm of the opinion that the User//Library//Sketchup Folder should contain symlinks from a User/Documents/SU_Library Folder [or SketchUp_Library is Trimble does it]. and that it should only contain user files.

I don't know if it's possible on a PC but all versions of SU on all macs can work from User Space, for too long people were advising mac users to use the System/Library which should be reserved for dev work...

I think encouraging full adoption of the 'New' User/*/Library/ structure is important.
If you don't want to use the "Plugins" folder, write your own preference list that Apple will not block at /Users/*/Library/Preferences/com.sk_fredo.defparem.plist adding sk will put it near sketchup.

john

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]