We want it where all can login to the computer and have the exact same Sketchup settings and exact same extensions/plugins. To do this for other programs, we use Sysprep and the CopyProfile setting in our unattend.xml file. The CopyProfile setting is the only official Microsoftmethod of copying a customized user profile to the default profile, which all new users will get the first time they login to the computer.
SketchUp has never used the Default profile purposely. (I’ve brought up the subject in the past, but noone on the “team” cared to even discuss it.)
Regardless, since it’s an OS feature, any new profile should copy whatever you save to the Default profile, at the time the user profile(s) are created.
From that point on, SketchUp will be loading and saving to each individual user’s profile and their “user.dat” registry hive.
Re: Shared Plugins on specific workstations:
Shared plugins go in the %ProgramData% path, ie:
%ProgramData%/SketchUp/SketchUp 2015/SketchUp/Plugins
and will be automatically loaded upon startup.
Shared Plugins on a network:
You’d put a rubyscript (like below) in an autoload folder, like the %ProgramData% plugins, as above:
# encoding: UTF-8
module YourSchool
@@loaderrors = {}
@@dir = "//path/to/some/shared/plugins"
#{# DEBUG METHODS
#
module_function()
def dir()
@@dir
end
def errors()
num = @@loaderrors.size
if num == 0
puts("\nNo LoadErrors for Shared plugins folder:\n '#{@@dir}'\n")
else
puts("\nLoadErrors for Shared plugins folder:\n '#{@@dir}'\n")
puts("#{num.to_s} Errors occured.\n")
@@loaderrors.each {|f,e|
puts("File: '#{f}'")
puts(" #<#{e.class.name}: #{e.message}>")
puts(e.backtrace) rescue puts()
}
puts()
end
end
def loaderrors()
@@loaderrors
end
#
#}#
#{# CHECK DIR
#
unless Kernel.test(?d,@@dir)
puts("Warning! '#{File.basename(__FILE__)}': could not find:\n '#{@@dir}'")
raise(LoadError,"Unable to find directory: #{@@dir}",caller(0))
else
$: << @@dir # push the shared directory into the $LOAD_PATH array.
end
#
#}#
#{# LOAD LOOP
#
### If @@dir cannot be found the load loop does not get evaluated!
#
Dir.chdir(@@dir) do
rbfiles = Dir["*.{rb,rbs}"]
#
rbfiles.each {|f|
ext = File.extname(f)
begin
ext == '.rbs' ? Sketchup::require(f) : require(f)
rescue => e
@@loaderrors[f]= e
else
path = File.join(@@dir,f)
if Sketchup.version.to_i < 14 # no rbs paths
$" << path unless $".last == path || $"[-2] == path
$" << f unless $".last == f || $"[-2] == f
else
# rbs paths will be downcased on v14+
$" << path unless $".last == path || $"[-2] == path
end
end
}
end # chdir do
#
unless @@loaderrors.empty?
puts "Warning! '#{File.basename(__FILE__)}': could not load these files:"
@@loaderrors.keys.sort.each {|f| puts " '#{f}'"}
puts "from dir: '#{@@dir}'\n"
end
#
#}#
end # module YourSchool
network_plugins.rb (2.0 KB)
First of all, applications are supposed to use expandable strings for paths in registry attributes, and then embed variables into the path strings.
So Sysprep should have taken this path:
C:/Users/Administrator/AppData/Roaming/AutoCAD/Folder1
and copied it to the Default user profile as:
%AppData%/AutoCAD/Folder1
Anything to be saved in the local (non-roaming workstation’s) user path would use the %LocalAppData% variable. This is true of the user’s %TEMP% directory.
[quote=“loosus456, post:4, topic:4196”]
Just as a quick glance, I found the following that I could see as issues (I haven’t tested yet):
HKEY_CURRENT_USER\Software\SketchUp\SketchUp 2015\File Locations:
This contains a bunch of C:\Users\[USERNAME] path keys, like these:
-
Classifications:
C:\Users\\[*USERNAME*]\AppData\Roaming\SketchUp\SketchUp 2015\SketchUp\Classifications\[/quote]
You need to think in terms of
%AppData%
instead of
C:\Users\[*USERNAME*]\AppData\Roaming
[quote=“loosus456, post:4, topic:4196”]
C:\Users\[USERNAME]\Documents[/quote]
It’s %USERNAME%, so:
C:\Users\%USERNAME%\Documents\
or even better:
%USERPROFILE%\Documents\
because the profile path may actually be on a remote / network drive (ie a server,), and not necessarily on the %SystemDrive%.
If you type set at the NT command prompt you’ll see a list of all the environment variables.
It does not matter whether you use them as all caps or mixed case.
%APPDATA% returns the same subpath as %AppData%
.
[quote=“DanRathbun, post:7, topic:4196”]
FYI, the “Documents” paths are just there because this is the first install.
The user can change these via the Preferences dialog’s Files panel.
Then the SketchUp installer tries to “migrate” these paths from the previous installed version.
The reasoning is that the user has likely created some meaningful sub-directory structure under the “Documents” folder, as most of SketchUp’s associated files are considered documents.
I set (personally) up something like:
Documents
|
+- SketchUp
|
+- Classifications
+- Components
+- Images
| + Textures
| + Watermarks
+- Materials
+- Models
| + Export
+- Styles
Of course they will.
Yes SketchUp was always set up as a single user-machine GUI application.
It’s only been a year (since the release of SU2014.) that some of the files were moved into the user path where they always belonged.
But because the older versions of SketchUp (2013 and earlier,) used Ruby 1.8.x, which did not have unicode string support, they had to leave user files in the binary (%ProgramFiles%) path.
The classifications and 4 standard Trimble extensions are distributed in the binary program folder, and copied over to the current user’s %AppData% path when SketchUp runs. Each time SketchUp starts it looks to see if these distro files have been copied, and if not will copy (or re-copy them, if you deleted them)
Thereafter… any updates via the ExtensionWarehouse for those extensions, will be deployed to the user’s %AppData% path,… not the “shipped” folders in the binary path.
I’ll need to do a quick test.
SketchUp has a nasty habit of overwirting registry values in a stupid way.
So it mat take the variable path and use it the first time say I open the import classification dialog,… but then may write the verbatim path back to the registry.
Ok the first test goes ok.
I replaced the “Classifications” path attribute value.
Was:
C:\Users\Dan\AppData\Roaming\SketchUp\Classifications
Now:
%AppData%\SketchUp\Classifications\
Started SketchUp, Then imported a classification system via the ModelInfo > Classifications panel, and the Import button.
The File open dialog opened in the correct folder.
The schema imported.
I closed SketchUp, and refreshed the view in the Registry Editor.
The path stayed as it was with the %AppData% variable.
The important thing is that the path was used without issue when opening the standard file picker dialog.
Once the user is running SketchUp, it should not matter if SketchUp writes user specific paths into their registry hive.
Ok the second test goes ok.
I replaced the “Components” path attribute value.
Was:
C:\Users\Dan\Documents\SketchUp\Components\
Now:
%USERPROFILE%\Documents\SketchUp\Components\
Started SketchUp.
Then right-clicked on the “Steve” component.
Chose “Save As”…
The File open dialog opened in the correct folder.
And I saved a copy of the “Steve.skp” component to my personal components folder.
I closed SketchUp, and refreshed the view in the Registry Editor.
The path stayed as it was with the %USERPROFILE% variable.
I re-opened SketchUp and the paths show with the variables, in the Preferences dialog:
Uh… that is a no-no. The whole reason for profiles is to allow users privacy from snoopy other users.
A “Standard User” can only access their own profile hierarchy. They will be denied access if they try to say, enter some other user’s “Documents” directory.
They can however access the “Public” profile.
I’m not sure about the “Default” profile, that may be only Administrators.
Administrators can access any profile.
I think that the HKEY_LOCAL_MACHINE has some installation paths, but into the %ProgramFiles% paths.
The SketchUP binary / program folders:
We Do still have a few issues (on MS Windows,) that I am still politicking to get changed.
I start adding them here, but it might take a few days for me to remember them and add them here.
(1) Templates
Custom user templates are saved into the binary path, without any choice to save them elsewhere, when the “Save As Template” (“File” menu) option is used.
If the “Standard User” does not have write permissions for the “SketchUp 2015/Resources/en-US/Templates” directory, an error occurs, or the file is instead SILENTLY saved into the user “%LocalAppData%/VirtualStore/Program Files/SketchUp/SketchUp 2015/Resources/en-US/Templates” directory (… Windows actually creates the virtual directories.)
This is no help as SketchUp does not go looking there for user templates.
(1)(a) SketchUp will not look in the user %AppData% path, unless the Templates directory is physically moved into the user %AppData% path.
This is probably a bad idea as any update / maintenance release is likely to recreate the Templates directory in the binary path, thereby shutting off users from their custom templates.
(2) Styles
The only way to set up a user’s appdata “Styles” folder ahead of time is to use a symbolic link:
At the NT console, an Administrator must navigate to the SketchUp program “Styles” sub-directory, and enter:
C:\Program Files\SketchUp\SketchUp 2015\Styles>mklink /D "User Styles" "%USERPROFILE%/Documents/SketchUp/Styles"
If it works you see:
symbolic link created for User Styles <<===>> C:\Users\Dan/Documents/SketchUp/Styles
When you start SketchUp you’ll see the link “User Styles” added to all the rest of the listed Styles directories, in the Styles inspector:
It’s not so much by design as because old versions of SketchUp could not deal with (or actually the old Ruby 1.8,) could not handle unicode usernames in path strings.
So they waited and waited until after Trimble bought the product and was willing to fund the Ruby updated to 2.0 with unicode support.
That allowed moving the plugins into the user path, which was the real “biggie”. They also set up the classifications in the user path because they were first developing that feature, and could go ahead with that, without worry something else would break.
Templates, Styles, Components and Materials all need better user path support.
Okay, going back to the plugins: they are – in newer versions – located in the user’s folder, right?
Will doing a straight copy – without manually changing anything – be enough to get these plugins to all users? Again, I want to make sure that the Default profile contains all relevant user data, including plugins if they are per-user.
Regarding Styles:
If I did not do the symbolic link for “User Styles,” would that simply mean that all students would be required to share styles rather than have their own?
[quote=“loosus456, post:21, topic:4196, full:true”]
Okay, going back to the plugins: they are – in newer versions – located in the user’s folder, right?[/quote]
Correct, by default, since SketchUp release 2014, which distros with Ruby 2.0.0.
You would have to manually create the “Plugins” folder in the %ProgramData% path, in order for SketchUp to even use that folder. It is not created by SketchUp by design. SketchUp will check if it exists, and if it does, will push it’s path into Ruby’s $LOAD_PATH array. Otherwise SketchUp will not use that path for “shared” plugins, and will only use the user’s “Plugins” folder.
You do not need to worry about the 4 “shipped extensions”, since SketchUp itself will deploy them for each user, whenever SketchUp runs, and they do not exist in that specific user’s “Plugins” folder.
As for other plugins, you could copy them (from a temporary Admin user profile,) into the Default user profile. And they should be copied OK.
But there is no guarantee, that all plugins will work in a network setting.
Some plugin authors have chosen to not use the read & write default API methods (which read & save to the User registry hive,) and instead write their own data files to save plugin settings.
If the user has read & write permissions for the folder that the plugin author used, then the plugin should work OK.
If the plugin was copied into the %ProgramData% “Plugins” folder, then the plugin’s save settings file might not work as the author intended. (UAC restrictions, etc.)
Some plugin authors decided to save settings into a unique sub-directory (that their plugin creates,) of the User’s %TEMP% folder.
This works in a non-roaming desktop situation, where the user always uses the same workstation.
But because the %TEMP% folder in down in the %LocalAppData% path, a student in a roaming situation, who sits at a different workstation from their previous class, they will not be able to access the plugin’s settings file from the last time they used that plugin.
A few plugin authors, have gotten smart, and created their own “company” folder in the roaming %AppData% path, just as SketchUp itself does, and Microsoft does, … and other software companies do.
If you do not SysPrep just before cloning the drives, … then mini-setup will not run, when each cloned computer is first booted.
If mini-setup does not run, then a unique SID is not generated for each workstation.
See: http://en.wikipedia.org/wiki/Security_Identifier
I’m not sure you can get around this since Vista and Windows Activation, but we DID do it for some critical computers running Win 2000 (against my advice. But I was only the contract tech. Could not make the engineer understand it was a bad thing to install them like that.)
(1) Most user settings on PC are written into the User registry hive.
(1a) You might create a custom shortcut (keyboard accelerator) in the Default profile, and make sure that propagates to the cloned installs. There are in key:
HKCU\\Software\\SketchUp\\SketchUp 2015\\Settings
Be aware there are some base accelerators preset in the exe file’s internal resources (manifest section.)
(1b) Of course the big ones are the user resource directory paths, as set via the Preferences dialog (Files panel.)
(2) Not to mention I’m not getting paid for it either.
I don’t know what the chances are. I suppose it would have to do with what percent of their business is network installs like this, in both commercial and educational settings. (You know the beancounters really rule the world.)
You could write up a good “use case scenario”, and post to the Feature Requests forum.
Then (virtually) “keep your fingers crossed.”