Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some services fail on files #1805

Closed
skurfer opened this issue Mar 25, 2014 · 2 comments
Closed

Some services fail on files #1805

skurfer opened this issue Mar 25, 2014 · 2 comments
Labels
Milestone

Comments

@skurfer
Copy link
Member

@skurfer skurfer commented Mar 25, 2014

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. 😃

@skurfer skurfer added this to the 1.2.0 milestone Mar 25, 2014
@skurfer skurfer added the Bug label Mar 25, 2014
@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Apr 1, 2014

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
Copy link
Member Author

@skurfer skurfer commented Apr 15, 2014

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

Anyway, taking another look at this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants