Some services fail on files

[skurfer]

As reported on the list. To reproduce:

1. Enable Terminal’s “New Terminal at Folder” service
2. Select a folder in Quicksilver
3. Select the service in the second pane and run it

By changing things around, I accidentally got the OS to give me a useful error message. Terminal expects public.file-url, even though that isn’t specified in its property list anywhere.

% /usr/libexec/PlistBuddy /Applications/Utilities/Terminal.app/Contents/Info.plist -c Print:NSServices:0           
Dict {
    NSMenuItem = Dict {
        default = New Terminal at Folder
    }
    NSRequiredContext = Dict {
        NSTextContent = FilePath
    }
    NSSendTypes = Array {
        public.plain-text
    }
    NSPortName = Terminal
    NSSendFileTypes = Array {
        public.directory
        com.apple.resolvable
    }
    NSMessage = newTerminalAtFolder
}

This is probably similar to what #1740 was originally created to fix. I was able to get that service working by making three changes:

1. File objects need [obj setObject:fileURL forType:@"public.file-url"] sometime before the service runs, where fileURL is a string not an NSURL.
2. The Services plug-in needs to add public.file-url to sendTypes before putting the object on the pasteboard.
3. When putting it on the pasteboard, Quicksilver needs to be taught not to convert the URL string to a property list.

I haven’t attempted any changes because for all I know, this only explains the failure of one service and others are expecting yet another type. Also, I could have sworn I smelled pasta cooking. @pjrobertson is much more familiar with this stuff, both from the app side and the plug-in side. There might be a simpler fix. 😃

[pjrobertson]

In reality, we shouldn't be using public.item where we were previously using NSFilenamesPboardType (to store the file path in the QSObj data). We should really be using public.file-url, which is what you've deduced here... I kind of thought that wouldn't work, but I've just tried changing QSFilePathType to it and it does work... hmmm :/

I’m open to it. I feel like public.item refers to the file and not a string containing the file’s path. But is public.file-url safe to use without the file:// prefix? Because adding that would come with its own issues.

So I think you're on the right track, but your point 3 takes quite a bit of work.

Not really. I just added another else if in -[QSObject (Pasteboard) writeToPasteboard:data:forType:]. But maybe there are other things I didn’t catch.

why do we not want to make v1.2 into v2.0 again? :)

It’s all subjective, but I’ll make my case:

1. I feel like we’re pretty close to something releasable.
2. If we decided we were working on 2.0, all of us would see it as an opportunity to rewrite and refactor things all over the place. It would take a lot of time to do, even more time to test, and probably ages for someone to come back and fix it after testing reveals a problem (if ever).
3. Momentum on the project is very low right now.
4. Thinking about 2 and 3 together, when would we see another release? 😃
5. For wishy-washy PR reasons, it would be good to get out another release to show all the work that’s been done so far and let people know things are happening.

[skurfer]

Crap. Did I edit your comment instead of making a new one? Sorry. 😕

Anyway, taking another look at this.