My plugin currently stores its user-loadable settings files in Sketchup.find_support_files(“Plugins”)//Settings. I’m trying to create a UI.openpanel that defaults to this directory, permitting users to select the settings file they’d like to use.
On Windows 7, Sketchup Pro 2015, this works perfectly:
UI.openpanel(“Test Box”, Sketchup.find_support_file(“Plugins”))
However, the same command on OS 10.8, Sketchup Pro 2015, the open dialogue drops me into the directory I used the last time I successfully called UI.openpanel (~/Pictures). On further investigation, it seems the UI.openpanel implementation on OS X behaves strangely: it can’t show folders marked as hidden in Finder, but it also fails to open dialogues to folders I do have permissions for, e.g.,
Each plugin should already have it’s own sub-directory in the “Plugins” directory.
Ruby has a built-in function to get the path of the file that is being evaluated.
It is: __FILE__
(That is two underscore chars + FILE (all uppercase) + two underscore chars.)
It returns an absolute path, which is suitable for use with Ruby’s File and Dir classes.
I’d not recommend saving any user data in the Plugins folder. Extensions Warehouse might remove the extensions files before installing updates. consider the Plugins folder much like the Program Files folder under windows - it’s a location for application packages.
Refer to the OS guidelines for storing user data/settings in the correct place in the user directory.
Thanks very much the notes. Dan: your one-liner is actually what I’ve been using. I made up the find_support_files examples in this post to try to exemplify the problem, but I’m afraid I misled you in doing so. :-/ Sorry for the confusion.
It seems john_drivenupthewall was able to reproduce the problem on pathnames with spaces. Have you ever run into this? Should I always be escaping pathnames spaces across platforms when making an openpanel call?
Thanks again!
EDIT: tt_su: thanks for the pointer. I’ll take a look at this.
If the string or path is not under your control but comes from an external source (user input, user-created directories), you always have to assume it can contain any allowed characters, including spaces.
For example if you run a string as terminal/cmd/bash command, the file path must be distinguishable from the rest of the string, here escaping makes sense. If available, it is cleaner to use a library’s own escaping methods, for example for URIs in the webbrowser encodeURIComponent, when composing regular expressions then RegExp.escape, etc.
There is a difference between file paths (operating system dependent) and file URIs. File URIs are standardized and use the file protocol, forward slashes and they use URI encoding of all special characters. I wonder what find_support_file does under the hood, since the API user passes a the file path as string to it, it shouldn’t have problems with quotes, unless the API inserts it into a command string without further escaping.
So far, I think it only updates the files in the new package,… and will leave any old files not in the new package.
This has been a complaint,… that some developers want fixed.
However, this thread brings up a good point about plugin settings.
Putting a massive amount of settings into the registry can cause the “Non-Win-Pro Registry Size Limit” error.
I myself would prefer a manifest solution like Gems use.
Deleting the entire folder, or ALL files in the folder, is heavy-handed, and IMHO, a sloppy solution.
I’d rather see a manifest file (text file) with relative paths from the plugin’s folder.
any file from an old version, that should be removed could be preceded with a minus sign, like: -"command_list.rb" -"icons/info_icon_24.png" -"icons/info_icon_48.png"
… hmm , or just name the manifest file “removables.txt” and forget about the minus sign.
I tried a ‘Update’ test by adding a file to an extension, but unless it’s an actual update you only have the option of ‘Uninstall’, which would delete any ‘plugin’ settings living where I believe they belong…
Doing it via ‘Preferences’ behaves as it should, only replacing ‘same name’ files…
I tend to have a ‘default-settings.rb’ that gets overridden by a ‘user-setting.rb’ if it exists…
IMHO, they both ‘belong’ to the plugin and I want them removed if I remove the plugin and want the ‘user-setting.rb’ retained if I update the plugin…
If Extension Warehouse does a complete ‘Uninstall/Fresh-Instal’ when I expect an ‘Update’, I would not be impressed…
john