Selection-based commands return results to QS unexpectedly

[jackbrannen]

When I perform a selection-based command in the Finder, the result is returned to Quicksilver in a way I don’t want. This didn’t happen with the last beta. Maybe I’m just an idiot, and I checked the wrong preference box somewhere?

Here’s a video of me demonstrating the issue: http://www.youtube.com/watch?v=V1rCSzrYyMY

This happens with “move to” actions and with some AppleScript actions designed to change folder color labels.

[pjrobertson]

Thanks for raising this issue with us. This has in fact been a feature of
Quicksilver for the 'move to...' and 'copy to...' actions ever since they
were implemented in Quicksilver - I have just been through the code history
and nothing has changed that would affect this.

Perhaps a recent bug fix to Quicksilver made this work properly for you,
and hence why you are seeing it for the first time.
There have been several users report that they would prefer it if
Quicksilver did not show the results on return, so perhaps it is a feature
we could implement should there be enough support for it.

On 3 April 2012 15:33, jackbrannen <
reply@reply.github.com

wrote:

When I perform a selection-based command in the Finder, the result is
returned to Quicksilver in a way I dont want. This didnt happen with the
last beta. Maybe Im just an idiot, and I checked the wrong preference box
somewhere?

Heres a video of me demonstrating the issue:
http://www.youtube.com/watch?v=V1rCSzrYyMY

This happens with move to actions and with some AppleScript actions
designed to change folder color labels.

---

Reply to this email directly or view it on GitHub:
#787

[skurfer]

Yes, the move and copy actions have always done that. The idea is that if, for example, you want to compress something, move it, and rename it, you shouldn’t have to go find it every time. It should just be there waiting. If you’re done, hit ⎋.

We recently fixed a bug that prevented it from working “correctly” when run via a trigger. (#699)

I’m not really sure what we could do about this. We could add a preference to prevent results from being displayed, but I suspect that would break a lot of things in unexpected ways and be even more annoying/confusing (for those who enable it).

[jackbrannen]

I understand. It’s not really a huge deal.

Should it also be returning text when I use AppleScript triggers designed to change the color labels of files?

On Apr 3, 2012, at 11.24a, Rob McBroom wrote:

Yes, the move and copy actions have always done that. The idea is that if, for example, you want to compress something, move it, and rename it, you shouldn’t have to go find it every time. It should just be there waiting. If you’re done, hit ⎋.

We recently fixed a bug that prevented it from working “correctly” when run via a trigger. (#699)

I’m not really sure what we could do about this. We could add a preference to prevent results from being displayed, but I suspect that would break a lot of things in unexpected ways and be even more annoying/confusing (for those who enable it).

---

Reply to this email directly or view it on GitHub:
#787 (comment)

[skurfer]

I understand. It’s not really a huge deal.

Between people who want to see the results and people that don’t, someone is going to be inconvenienced. For the people that don’t, the inconvenience is hitting ⎋. For those that do, it could be a lot more complicated, so I think this is the right trade-off. Having said that, I can’t really use that argument for these particular actions because it would mean a single keystroke inconvenience either way. (If they didn’t display results, the results would still be there waiting, so you’d just have to bring Quicksilver back up if you wanted to do something additional.)

For what it’s worth, since this behavior is controlled via an XML property list and not code, you could change it yourself. You’d have to repeat this with every update to the application, so I guess it depends on how important it is.

If you open /Applications/Quicksilver.app/Contents/PlugIns/Core Support.qsplugin/Contents/Info.plist and search for “FileCopyToAction”, you should see displaysResult under it. Change that from 1 to 0. Repeat that for “FileMoveToAction”. The next time you start Quicksilver, those actions shouldn’t pop the interface back up (but it will still set the moved/copied file as the selected item, so don’t be surprised to see it the next time you bring up QS).

Should it also be returning text when I use AppleScript triggers designed to change the color labels of files?

Doesn’t seem like it. Which action is it?

[jackbrannen]

Thanks for taking the time to send those instructions! I appreciate it.

The AppleScript I’m using is:

property file_color : 2
-- replace '2' above with the number for the color you'd like to use:
-- 0=none, 1=orange, 2=red, 3=yellow, 4=blue, 5=purple, 6=green, 7=grey
tell application "Finder"
activate
set selected to selection
repeat with n_file in every item in selected
set label index of n_file to file_color
end repeat
end tell

And the text that QS returns to me is the digit on the first line of code. Got any ideas?

On Apr 4, 2012, at 5.13p, Rob McBroom wrote:

I understand. It’s not really a huge deal.

Between people who want to see the results and people that don’t, someone is going to be inconvenienced. For the people that don’t, the inconvenience is hitting ⎋. For those that do, it could be a lot more complicated, so I think this is the right trade-off. Having said that, I can’t really use that argument for these particular actions because it would mean a single keystroke inconvenience either way. (If they didn’t display results, the results would still be there waiting, so you’d just have to bring Quicksilver back up if you wanted to do something additional.)

For what it’s worth, since this behavior is controlled via an XML property list and not code, you could change it yourself. You’d have to repeat this with every update to the application, so I guess it depends on how important it is.

If you open /Applications/Quicksilver.app/Contents/PlugIns/Core Support.qsplugin/Contents/Info.plist and search for “FileCopyToAction”, you should see displaysResult under it. Change that from 1 to 0. Repeat that for “FileMoveToAction”. The next time you start Quicksilver, those actions shouldn’t pop the interface back up (but it will still set the moved/copied file as the selected item, so don’t be surprised to see it the next time you bring up QS).

Should it also be returning text when I use AppleScript triggers designed to change the color labels of files?

Doesn’t seem like it. Which action is it?

---

Reply to this email directly or view it on GitHub:
#787 (comment)

[skurfer]

How are you running it? Are you using the “Run” action. Yeah OK, there are 50 of those. :-) I mean the one with an AppleScript icon. If I put that in an AppleScript then select it and use the (default in my case) Run action, Quicksilver disappears and the label is set.

FYI, Quicksilver has a “Set Label…” action built-in. With any selected file(s), choose Set Label… then “search” for the color in the third pane. Oh, sorry, Quicksilver is Welsh now, so… colour. ;-)

That action seems a bit buggy, but I’ll open another issue on that.

[jackbrannen]

Yeah, the label action crashes Quicksilver for me. Can’t get it to work. I’ll wait for a bug fix on that guy. Nice to know about it, though!

My “Run” action does have an AppleScript icon. I guess that’s not very helpful feedback for you. Is there a way I can identify which action it is more precisely?

[skurfer]

My “Run” action does have an AppleScript icon. I guess that’s not very helpful feedback for you. Is there a way I can identify which action it is more precisely?

Yes, but it’s convoluted. I think that’s enough to tell us you’re using the right one.

So, I don’t know. I guess you could try what I did, which is copying and pasting the AppleScript from this issue into a new file and see if that behaves any differently. I don’t know why it would, but it could be worth a try. Do you have a screen-shot of what it returns?

[jackbrannen]

Yep, its just straight text: http://cl.ly/FkHZ

On Apr 11, 2012, at 9.30a, Rob McBroom wrote:

My Run action does have an AppleScript icon. I guess thats not very helpful feedback for you. Is there a way I can identify which action it is more precisely?

Yes, but its convoluted. I think thats enough to tell us youre using the right one.

So, I dont know. I guess you could try what I did, which is copying and pasting the AppleScript from this issue into a new file and see if that behaves any differently. I dont know why it would, but it could be worth a try. Do you have a screen-shot of what it returns?

---

Reply to this email directly or view it on GitHub:
#787 (comment)

[skurfer]

I have no explanation for that. Looking through the code, I see that the Run action for AppleScripts will display results, but that only happens if the action returns something and it’s hard-coded to return nothing every time.

Does this happen if you run the scripts from the main Quicksilver interface, or only from the trigger? If it always happens, let’s do the convoluted thing and see exactly what’s being run:

1. Get the script in the first pane
2. Select the Run action (with the AppleScript icon) in the second pane
3. Hit �⌃↩ to encapsulate the command
4. Select the “Save Command to File…” action in the second pane
5. Tab to the third pane and select a folder to save it in (you only need it for a minute, so the Desktop should be fine)
6. Open the resulting .qscommand file in TextEdit, TextMate or something similar
7. Copy the text and paste it here

You can get rid of the file after that.

[jackbrannen]

Step 5 produces no result for me in any folder. Tried restarting QS. Want me to screen cap my process in case I’m doing it wrong?

Thanks

On Apr 11, 2012, at 3.04p, Rob McBroom wrote:

I have no explanation for that. Looking through the code, I see that the Run action for AppleScripts will display results, but that only happens if the action returns something and it’s hard-coded to return nothing every time.

Does this happen if you run the scripts from the main Quicksilver interface, or only from the trigger? If it always happens, let’s do the convoluted thing and see exactly what’s being run:

1. Get the script in the first pane
2. Select the Run action (with the AppleScript icon) in the second pane
3. Hit �⌃↩ to encapsulate the command
4. Select the “Save Command to File…” action
5. Tab to the third pane and select a folder to save it in (you only need it for a minute, so the Desktop should be fine)
6. Open the resulting .qscommand file in TextEdit, TextMate or something similar
7. Copy the text and paste it here

You can get rid of the file after that.

---

Reply to this email directly or view it on GitHub:
#787 (comment)

[skurfer]

Couldn’t hurt. Take your time, as I probably won’t get to look at it until Monday.

[jackbrannen]

Finally got around to this.

http://f.cl.ly/items/102r0V1V2h1w2e0t391j/Screen%20Recording2.mov

[skurfer]

Figured it out. It turns out that it was related to the original issue you reported.

The clue that led me to the answer was the icon. I would expect triggers that run AppleScripts to have the AppleScript icon, but yours all had text icons. I guessed (correctly) that you must be using text with the “Run as AppleScript” action, instead of an AppleScript file with the “Run” action.

The “Run as AppleScript” action must show the results from the script (if there are any). If you run those scripts in the AppleScript Editor, you’ll notice the number shows up as the result at the bottom.

The easiest fix would be to save these as actual AppleScript files in ~/Library/Scripts, then modify your triggers to run each respective script. Make sure the scripts are in your catalog by enabling “Scripts (User)” in the Scripts section of the Catalog prefs.

[jackbrannen]

MY HERO