Not able to set relative path to User Template

[ahousseini]

It is not possible to place an item with an relative path in the user template.

e.g.:

/usr/local/bin/dockutil --add '~/' --view grid --display folder '/System/Library/User Template/Non_localized'

[VitosX]

It is not an issue of dockutil.
Items in dock prefs must have absolute paths.

[kcrawford]

This seems to work okay for me in the current version. What problem are you seeing?

[VitosX]

I tried adding '/Downloads' folder (which was present in User Template/Non_localized folder) or '/Music' (which was not present in template folder).
I am seeing question marks in dock on accounts created after adding items this way to templates.

[kcrawford]

Thanks. I understand now.

Are any in Apple's default dock?

Does Apple use the dock fix up to set these?

Do they resolve after clicking them? or after restarting the Dock?

Kyle

On Jul 18, 2016, at 8:05 AM, VitosX [email protected] wrote:

I tried adding '/Downloads' folder (which was present in User Template/Non_localized folder) or '/Music' (which was not present in template folder).
I am seeing question marks in dock on accounts created after adding items this way to templates.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[VitosX]

There is no com.apple.dock.plist in any default User Template folder, so I guess Apple uses dock fix up.
They don't resolve after clicking, neither after restarting the dock.
The behavior is actually logical for me, as I mentioned paths to dock items are encoded as absolute paths in .plist and /System/Library/User Template is not accessible to regular users.

[jedetaste]

I tried to place a com.apple.dock.plist in the user template from http://techion.com.au/blog/2015/4/28/dock-master. This plist does have a relative path and it works:

<string>~/Downloads</string>

But with dockutil it looks like this:

<string>/System/Library/User Template/German.lproj/Downloads</string>

[MGatner]

I can confirm this is still an issue. I can work around it by pre-seeding the DUT with a dock plist that has a working relative path (like jedetaste's comment above) and then build onto it, but I would love to see this working so I can script complete removal of DUT dock and then rebuild using dockutil.

EDIT: Issue seems to be that relative paths are resolved by dockutil when placed into the plist, rather than using Apple's post-copy resolution:

if add_path.startswith('~'): # we've got a relative path and relative paths need to be processed by using a path relative to this home directory real_add_path = re.sub('^~', plist_path.replace('/Library/Preferences/com.apple.dock.plist',''), add_path) # swap out the full home path for the ~

This part needs to check if the target is in /System/Library/User Template and then it needs to seed the file with Apple's self-resolving relative path (which "dock-master" above seems to have figured out, even though I have not).

EDIT2: It appears (if dock-master referenced above is correct) that you can seed a relative path by the following:

<dict> <key>tile-data</key> <dict> <key>arrangement</key> <integer>2</integer> <key>displayas</key> <integer>2</integer> **<key>home directory relative</key> <string>~/Downloads</string>** <key>label</key> <string>Downloads</string> <key>showas</key> <integer>1</integer> </dict> <key>tile-type</key> <string>directory-tile</string> </dict>