"Latest Download" proxy objects seem broken in B70

[clarkewd]

Maybe there is something wrong with my setup but it seems that none of the Proxy Objects are working in B70. They show up, my same keys are assigned to them, but they don't work (it's like they don't point to anything) and the icon for them is a questionmark:

They are enabled in the catalog, but they also show up as question marks there too:

Update: After clearing the cache most of the proxy objects are back but the "Latest Download" proxy still seems broken.

[skurfer]

First thing I'd try is clearing caches.

http://qsapp.com/wiki/FAQ#Clearing_the_cache

[clarkewd]

thanks but still no luck. actually even after deleting stopping quicksilver, removing the entire ~/Library/Application Support/Quicksilver folder, and relaunching proxies, like Latest Download still seem broken.

[clarkewd]

Not sure why, but the code in QSDownloads.m is not resolving the downloads folder correctly for me. I was seeing an error in Console.app

I think this may have to do with trying to get the downloads location preference from the Safari browser.

When I override the location by adding these lines the downloads proxy works.

downloads = [[@"~/Downloads" stringByExpandingTildeInPath] stringByResolvingSymlinksInPath];
downloadsURL = [NSURL URLWithString:downloads];

right above

NSFileManager *manager = [NSFileManager defaultManager];

then the downloads proxy works again. i'm going to try and debug further but this proxy is definitely getting hung up on something.

[pjrobertson]

It appears that Safari 6 has been put into the same boat as Mail and we're having the same problem @skurfer came across with reading prefs.

Despite this, if Quicksilver can't read the prefs properly, then it just takes the default path as you have given there. Look at line 28 of QSDownloads.m

[clarkewd]

I realize that's what it is supposed to be doing but it's not working for me. It appears to be returning a cached path to /tmp/test which is i file i may have used long ago. i'm going to try and debug further later today.

[pjrobertson]

OK, interesting, thanks.

I guess we could do a check to see if that file exists, but that of course
isn't the ideal solution.

Could you let us know what OS you're on, and whether a folder called
'com.apple.safari' (or similar) exists in ~/Library/Containers

Cheers again

On 10 September 2012 17:59, clarkewd notifications@github.com wrote:

I realize that's what it is supposed to be doing but it's not working for
me. It appears to be returning a cached path to /tmp/test which is i file i
may have used long ago.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1102#issuecomment-8429868.

[skurfer]

FYI, on my 10.8.1 system, it appears to be using ~/Library/Preferences/com.apple.Safari.plist. There's nothing for Safari in ~/Library/Containers. Though I see that Quicksilver's checking com.apple.internetconfigpriv. I think it's in com.apple.Safari now (if it wasn't before). I changed the location in Safari's prefs and I can see the result with defaults read com.apple.Safari DownloadsPath. The other domain just shows an alias, but I can see that the file hasn't been modified since July 25th.

[clarkewd]

I'm also running 10.8.1 and it's the same - nothing for safari in there:

[pjrobertson]

OK, looks like Rob's put his finger on it.
Safari isn't sandboxed, but the location of the setting has moved.

On 11 September 2012 02:11, clarkewd notifications@github.com wrote:

I'm also running 10.8.1 and it's the same - nothing for safari in there:

[image: Picture.png]https://a248.e.akamai.net/camo.github.com/0d3c4b4b2f8d1683ca04619374f27877f683d9f2/687474703a2f2f696d673430372e696d616765736861636b2e75732f696d673430372f393439372f706963747572656f2e706e67

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1102#issuecomment-8443972.

[tiennou]

Hmm, shouldn't this be changed to use [[NSFileManager sharedManager] URLsForDirectory:NSDownloadsDirectory inDomains:NSUserDomainMask] ? That's available 10.6+, but there's NSSearchPathForDirectoriesInDomains() from 10.0 that still exists ? (Note there's also a -URLForDirectory:inDomain:appropriateForURL:create:error: which can handles the creation transparently).

Now maybe this setting is unrelated to the Safari setting, but I think they're linked...

[skurfer]

Hmm, shouldn't this be changed to use [[NSFileManager sharedManager] URLsForDirectory:NSDownloadsDirectory inDomains:NSUserDomainMask]?

Well, obviously… if you know that exists. :-)

I see no reason to create the folder if it doesn't exist, as the purpose of the proxy is to get the most recent file from an existing location. I've tried it and it works. I can commit it and do a pull request, but on master or release? (I vote master.)

[pjrobertson]

Never knew that existed. Good find @tiennou ;-)

We'd still need to make sure we're correctly traversing symlinks and all
that, we've had users report problems with this in the past.

I'd say master as well, go for it Rob :)

On 11 September 2012 15:42, Rob McBroom notifications@github.com wrote:

Hmm, shouldn't this be changed to use [[NSFileManager sharedManager]
URLsForDirectory:NSDownloadsDirectory inDomains:NSUserDomainMask]?

Well, obviously… if you know that exists. :-) I see no reason to create it
if it doesn't exist, as the purpose of the proxy is to get the most recent
file from an existing location. I've tried it and it works. I can commit it
and do a pull request, but on master or release? (I vote master.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1102#issuecomment-8462299.

[tiennou]

Heh, no problem, I guess I take too much time lurking around the Developer documentation anyway ;-).

@pjrobertson: There's -[NSURL URLByResolvingSymlinksInPath] and -[NSURL URLByStandardizingPath] which should do the trick.

@skurfer: (I saw your message in Mail, but it doesn't appear here, weird ?) I'd say Safari does the "resolve symlinks / standardize path" dance before storing it. Anyway I don't know if that's shared system-wide (I would expect a notification or something like that if that's the case) or just a convenient default. If that's the case, then reading a value out of a property list file approach is definitely better ;-), but you could still add the NSDownloadFolder as a default then...

[skurfer]

@skurfer: (I saw your message in Mail, but it doesn't appear here, weird ?)

Yeah, I don't know where it went. A summary of it still shows on the main GitHub page, but it's not here.

Anyway, I'm afraid it might just return the default and not the current value. I left it for a couple hours and it the change was never reflected. I should try logging out before giving up, but I don't want to do that right now. :-)