Safe place to store user-defined parameters
-
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]
-
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).
-
@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
-
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
-
@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
-
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
-
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.
-
@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.
-
@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.plistresult = 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
-
@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.plistresult = 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
-
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. -
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
-
I'm recently beginning to learn Mac - would:
~/Library/Application Support/
be the folder that is comparable to Application Data on Win?
-
hi
have a look at this, it explains Apples viewpoint.Apples basic philosophy is
@unknownuser said:Every app is an island
this includes any plugins written for any app.
Apple are moving away from any need for "uninstaller software", as far as they're concerned if a User or the "App Store", trashes or updates an app, then 'all' the files associated with the outgoing 'app version' will be gone on next restart of the mac. To achieve this, it's limiting 'where' you can easily write to, and for 'app approval' you have to prove this can be achieved.
If I remove anyones 'Plugin' for SU, I expect 'all' it's support files to disappear from my system. So does Apple.
I have one 'Plugin' that moves items all over the place, but if I remove it or even just disable it from the 'Extension Manager' it puts everything back in place and deletes it's 'watch-file'. If I then restart it it writes everything back again. The only thing that ever resides external to SU folder structure are temporary or the outcome of User input i.e. document files I want to keep.
john
-
So John, what is the simple answer to Fredo's question? How does he safely write files to the HD on a Mac?
if Chrome downloads a plugin, it has to put it somewhere. Does it put it in the app bundle? -
for SU the is most comparable to
@unknownuser said:Application Data on Win
is ~/Library/Application Support/SketchUp 2013/SketchUpif I add a folder in there...
Sketchup.find_support_file("SketchUp", "john")
SHOULD work, but it doesn't.john
PS:
we cross posted so I'll add 2 answers
1.
@unknownuser said:Google Chrome installs the extension into a randomly generated directory in ~/Library/Application Support/Google/Chrome/Default/Extensions and registers it in its Preferences file.
- The User "Plugins" folder unless it needs to work when plugins are disabled. [really only for debugging or maybe a timekeeping tool]
-
@Fredo
I feel your pain, love your plugins, maybe someone at Trimble or Steve can tidy this up better then me.
it writes a binary .plist in Users Plugins Folder, in your plugins subdirectory, you can then access it as you would the SU one, but it's your own.
Once written, it can be read/write i.e. doesn't need a restart [unlike SU's which does]
you can store all types of thing in it include binary images etc...#!/usr/bin/env ruby # DON'T RUN DIRECTLY FROM SKETCHUP SEE USAGE BELOW # put this in your folder and call it to create a binary .plist on the Users mac # write what you will require "osx/cocoa" require "pp" # Create the plist and assign values my_path = File.expand_path("~/Library/Application Support/SketchUp 2013/SketchUp/Plugins/FredoHome/__me_first/com.fredo.example.plist") myfile = my_path my_dict = OSX;;NSMutableDictionary.dictionary my_dict['The_Color'] = 'blue' my_dict['count'] = 15 # # Output to File and print my_dict.writeToFile_atomically(myfile, true) pp my_dict =begin ### Usage make_plist = %x(exec ~"/Library/Application\ Support/SketchUp\ 2013/SketchUp/Plugins/FredoHome/__me_first/mac_plist.rb" 2>&1) my_plist = File.expand_path("~/Library/Application Support/SketchUp 2013/SketchUp/Plugins/FredoHome/__me_first/com.fredo.example") add2my_plist = %x(defaults write "#{my_plist}" animation-duration -float 0.12) inQuire = %x(defaults read "#{my_plist}") { "The_Color" = blue; "animation-duration" = "0.12"; count = 15; } inQuire = %x(defaults read "#{my_plist}" The_Color) blue =end
the format of this bit is important com.fredo.example.plist for defaults to read and write.
Lifted from the man page... https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/defaults.1.htmlSpecifying value types for preference keys; If no type flag is provided, defaults will assume the value is a string. For best results, use one of the type flags, listed below. -string Allows the user to specify a string as the value for the given preference key. -data Allows the user to specify a bunch of raw data bytes as the value for the given preference key. The data must be provided in hexidecimal. -int[eger] Allows the user to specify an integer as the value for the given preference key. -float Allows the user to specify a floating point number as the value for the given preference key. -bool[ean] Allows the user to specify a boolean as the value for the given preference key. Value must be TRUE, FALSE, YES, or NO. -date Allows the user to specify a date as the value for the given preference key. -array Allows the user to specify an array as the value for the given preference key; defaults write somedomain preferenceKey -array element1 element2 element3 The specified array overwrites the value of the key if the key was present at the time of the write. If the key was not present, it is created with the new value. -array-add Allows the user to add new elements to the end of an array for a key which has an array as its value. Usage is the same as -array above. If the key was not present, it is created with the specified array as its value. -dict Allows the user to add a dictionary to the defaults database for a domain. Keys and values are specified in order; defaults write somedomain preferenceKey -dict key1 value1 key2 value2 The specified dictionary overwrites the value of the key if the key was present at the time of the write. If the key was not present, it is created with the new value. -dict-add Allows the user to add new key/value pairs to a dictionary for a key which has a dictionary as its value. Usage is the same as -dict above. If the key was not present, it is created with the specified dictionary as its value. Specifying a host for preferences; Operations on the defaults database normally apply to any host the user may log in on, but may be restricted to apply only to a specific host. If no host is provided, preferences operations will apply to any host the user may log in on. -currentHost Restricts preferences operations to the host the user is currently logged in on. -host hostname Restricts preferences operations to hostname.
-
Talking it over a little bit here with a Mac person, I still think that the ~/Library/Application Support/ folder is the right starting point. It exists on all Macs, and is specifically designed to be the location that support files get saved to. To me, that is the definition of what Fredo is looking for, and it is sanctioned by Mac. So it CAN'T be against their own "Every app is an island" viewpoint, or else they wouldn't have created it, right?
-
Ok, I'm reading through that great Link John (very helpful to me as I try to wrap my head around Macs). 2/3 of the way down, in Table 1.3 it does explain the purpose of the Application Support folder:
@unknownuser said:
Use this directory to store all app data files except those associated with the userās documents. For example, you might use this directory to store app-created data files, configuration files, templates, or other fixed or modifiable resources that are managed by the app. An app might use this directory to store a modifiable copy of resources contained initially in the appās bundle. A game might use this directory to store new levels purchased by the user and downloaded from a server.
All content in this directory should be placed in a custom subdirectory whose name is that of your appās bundle identifier or your company. -
I'll wait till your finished before I bite your head off...
Advertisement