ß60 is here!
philostein
ß59).
Great job devs - shout out to Patrick, Rob, Henning, Matt, Eric,
Florian and the rest on the changelog page:
http://QSApp.com/changelog.php
Thanks everybody, been enjoying the latest build a lot! (Bleeding
edge, all my custom icons bled away…)
Cheers.
Rob McBroom
> Get it at http://QSApp.com/download.php (or 'Check for updates' in
> ß59).
It’s waaay better. Just FYI, anyone using BezelHUD should re-download it from qsapp.com. It’s not a new version, just rebuilt against the latest Quicksilver which seems to fix an issue with the results list.
--
Rob McBroom
<http://www.skurfer.com/>
Tim
Glad you mentioned the BevelHUD issue, Rob - when I saw the details list nearly empty, I nearly had to go and lie down!
EMRK
On 6月6日, 上午2時41分, Tim <stationf...@gmail.com> wrote:
> Thanks so much for everyone's hard work on QS. This version seems so, so much snappier to me.
>
> Glad you mentioned the BevelHUD issue, Rob - when I saw the details list nearly empty, I nearly had to go and lie down!
>
> On 5 Jun 2011, at 15:23, Rob McBroom wrote:
>
>
>
> > On Jun 5, 2011, at 4:59 AM, philostein wrote:
>
hrh3
work!
On Jun 5, 10:23 am, Rob McBroom <mailingli...@skurfer.com> wrote:
> On Jun 5, 2011, at 4:59 AM, philostein wrote:
>
Dave Land
> Get it at http://QSApp.com/download.php
I'm very grateful to the hard-working developers who have kept QuickSilver alive,
even through the difficult Snow Leopard upgrade. Yay!
I wonder if anyone else is seeing this:
Although I've installed the latest version of the Apple Mail Module from qsapp.com (vers. 118 from 2011-04-25), the QA Plug-ins list still lists it as having been updated 09/01/06. Am I missing something? Is it really updated?
Dave
Rob McBroom
> Although I've installed the latest version of the Apple Mail Module from qsapp.com (vers. 118 from 2011-04-25), the QA Plug-ins list still lists it as having been updated 09/01/06. Am I missing something? Is it really updated?
The dates you see there are still being pulled from blacktree.com (which has very old plug-ins) instead of the files actually installed on your machine. The next version is all about fixing the plug-in update system (for real this time). I believe you can trust the version number at least.
R
financially for the app that I use most on my mac.
On Jun 5, 4:59 am, philostein <phildoo...@gmail.com> wrote:
> Get it athttp://QSApp.com/download.php(or 'Check for updates' in
Paul Oppenheimer
Paul E. Oppenheimer
pa...@peoppenheimer.org
http://peoppenheimer.org/
Ian Hay
bn
back. This is the most useful app on my mac. No questions.
Howard Melman
QS B60 (3850) 10.6.8. MacBookPro4,1 Intel Core 2 Due 2.4GHz, 4 GB RAM
Made backups of:
~/Libary/Application Support/Quicksilver
~/Libary/Preferences/com.blacktree.quicksilver.plist
~/Applications/Quicksilver.app
Quit Quicksilver
Downloaded B60, installed on Desktop
Startup was fine
Brought up prefs including Preferences which was nice to see (didn't work in B54)
All plugins still show older dates (itunes is 2/13/08 everything else is 07 or before), Do I understand correctly that this is just a display issue (dates still coming from blacktree but plugins have been updated?) The ~/Library/Application Support/Quicksilver/PlugIns/*.qsplugin files also show older dates in Finder.
Seems quick
Catalog found my address book entry. Navigating into it worked fine. ctl-n and ctl-p to navigate results list works.
Web search for "Itchy & Scratchy" didn't quite work (issue 313). The generated URL is http://www.google.com/search?q=itchy+&+scratchy which just searches for itchy.
Existing Current Application (Hide) trigger on a mouse corner was null. The corner highlighted when I moused to it but nothing happened. Recreated trigger and it seems to work even after restart
My google search trigger was renamed to "Stock Symbol Quicksearch (Search for...)". Other triggers look ok. I recreated, restarted and it's back to the Stock Symbol name though it seems to be working correctly.
I've been having a problem that I had a trigger on ctl-cmd-k to Toggle Application NetNewsWire. In B54 several times I've changed to Reeder and updated the trigger but it keeps reverting to NNW. I've updated it now in B60 to Reeder and it seems to be remembering Reeder even after QS restsart.
The shelf seems ok, the contents are correct, but it double displays text now. A folder is fine, it shows folder name and then path on the next line, same with a file, but text is duplicated and I don't think it did that (I could be wrong).
My custom catalog of web searches was retained and is working fine (with the exceptions above noted).
My triggers doing web searches on current selection work fine.
The new action Get Path was disabled at first.
Console showed a few errors:
6/29/11 2:28:15 PM Quicksilver[12358] Prevented load of unidentified action from bundle Chat Support.qsplugin because the action's featureLevel (set from its Info.plist) is higher than NSApp's current featureLevel. This is not neccessarily an error. Sometimes this mechanism is used to prevent unstable actions from loading.
6/29/11 2:43:06 PM Quicksilver[12409] Incorrect NSStringEncoding value 0x0000 detected. Assuming NSStringEncodingASCII. Will stop this compatiblity mapping behavior in the near future.
6/29/11 3:01:58 PM Quicksilver[12409] *** WARNING: Method selectRow:byExtendingSelection: in class QSTableView is deprecated. It will be removed in a future release and should no longer be used.
6/29/11 3:06:21 PM Quicksilver[12409] Failed loading bundle (null)
Overall, nice job. If nothing else comes up I'll be sticking with B60. FYI, here are the plugins and triggers I'm using:
philostein
It's really great to see you've jumped to the latest Quicksilver. Your
manual is still the best way to learn QS, despite it being a few
versions old.
I think the devs will be happy to get your seal of approval. :)
On Jun 30, 4:27 am, Howard Melman <hmel...@gmail.com> wrote:
> I apologize for taking so long to get around to it, but as you might imagine, Quicksilver is burned into my fingers, so I was a little shy about possibly breaking what was working for me. Still I upgraded to B60 today and after an hour it seems to be working well for me. Here are some notes I took:
>
> QS B60 (3850) 10.6.8. MacBookPro4,1 Intel Core 2 Due 2.4GHz, 4 GB RAM
>
> Made backups of:
> ~/Libary/Application Support/Quicksilver
> ~/Libary/Preferences/com.blacktree.quicksilver.plist
> ~/Applications/Quicksilver.app
>
> Quit Quicksilver
>
> Downloaded B60, installed on Desktop
>
> Startup was fine
> Brought up prefs including Preferences which was nice to see (didn't work in B54)
>
> All plugins still show older dates (itunes is 2/13/08 everything else is 07 or before), Do I understand correctly that this is just a display issue (dates still coming from blacktree but plugins have been updated?) The ~/Library/Application Support/Quicksilver/PlugIns/*.qsplugin files also show older dates in Finder.
>
> Seems quick
>
> Catalog found my address book entry. Navigating into it worked fine. ctl-n and ctl-p to navigate results list works.
>
> Existing Current Application (Hide) trigger on a mouse corner was null. The corner highlighted when I moused to it but nothing happened. Recreated trigger and it seems to work even after restart
>
> My google search trigger was renamed to "Stock Symbol Quicksearch (Search for...)". Other triggers look ok. I recreated, restarted and it's back to the Stock Symbol name though it seems to be working correctly.
>
> I've been having a problem that I had a trigger on ctl-cmd-k to Toggle Application NetNewsWire. In B54 several times I've changed to Reeder and updated the trigger but it keeps reverting to NNW. I've updated it now in B60 to Reeder and it seems to be remembering Reeder even after QS restsart.
>
> The shelf seems ok, the contents are correct, but it double displays text now. A folder is fine, it shows folder name and then path on the next line, same with a file, but text is duplicated and I don't think it did that (I could be wrong).
>
> My custom catalog of web searches was retained and is working fine (with the exceptions above noted).
>
> My triggers doing web searches on current selection work fine.
>
> The new action Get Path was disabled at first.
>
> Console showed a few errors:
> 6/29/11 2:28:15 PM Quicksilver[12358] Prevented load of unidentified action from bundle Chat Support.qsplugin because the action's featureLevel (set from its Info.plist) is higher than NSApp's current featureLevel. This is not neccessarily an error. Sometimes this mechanism is used to prevent unstable actions from loading.
>
> 6/29/11 2:43:06 PM Quicksilver[12409] Incorrect NSStringEncoding value 0x0000 detected. Assuming NSStringEncodingASCII. Will stop this compatiblity mapping behavior in the near future.
>
> 6/29/11 3:01:58 PM Quicksilver[12409] *** WARNING: Method selectRow:byExtendingSelection: in class QSTableView is deprecated. It will be removed in a future release and should no longer be used.
>
> 6/29/11 3:06:21 PM Quicksilver[12409] Failed loading bundle (null)
>
> Overall, nice job. If nothing else comes up I'll be sticking with B60. FYI, here are the plugins and triggers I'm using:
>
> 372KViewDownload
>
>
>
> Screen shot 2011-06-29 at 3.15.17 PM.png
> 291KViewDownload
guy manchester
I do sometimes wonder how many extra applications I'd need if I didn't have Quicksilver. If loss of one tiny bit of functionality like this necessitated the downloading of two new items of software imagine how cluttered our Applications folders would be if we didn't have Quicksilver at all.
Incidentally I was wondering if there was any way that users of Quicksilver could 'vote up' an issue if it's important to them. Obviously I've got no problem with you guys prioritising issues that are important to yourselves but there must come a time when you've dealt with all these and rather than just 'sticking a pin in' this would give you some guidance as to what's importance to us humble users who lack the requisite coding skillz. It may be interesting to see how important things like a dedicated Twitter client might be to users say. I know there are a couple of workarounds but they aren't slick as the old Twitter plugin that was broken when twitter went to OAuth & is obviously still broken under xAuth.
> <Screen shot 2011-06-29 at 3.14.53 PM.png><Screen shot 2011-06-29 at 3.15.17 PM.png>
Patrick Robertson
Patrick Robertson
Howard Melman
All plugins still show older dates (itunes is 2/13/08 everything else is 07 or before), Do I understand correctly that this is just a display issue (dates still coming from blacktree but plugins have been updated?)
Web search for "Itchy & Scratchy" didn't quite work (issue 313).Works fine here. Just to be sure. It required ß60 and the latest web search module from http://qsapp.com/plugins The '&' should be encoded to '%26'
Henning Jungkurth
> So that's the question. To get the new plugins I have to download them
> individually from here? Is there an easy way to download them all? Will they
> then update on their own using the reload button on the plugins prefs?
You have to download them individually, manually from qsapp.com. And
then you have to install them individually, manually (install a plugin
by double-clicking on the .qsplugin once it's un-archived). Then the
date in the plugins list will still be the old one, but the version
number should be the new one.
We know it's a major PITA and we are working on it, but for now that's
how it has to be. Hopefully it will be working as it used to be in the
next version.
Rob McBroom
> Incidentally I was wondering if there was any way that users of Quicksilver could 'vote up' an issue if it's important to them.
GitHub used to have votes on issues, but they removed that for some reason. So probably commenting on them and providing as much detail as possible is the way to go. I usually view the list of issues sorted by last update, so the ones with active comments will be higher.
On Jun 30, 2011, at 6:01 AM, Patrick Robertson wrote:
> The encoding error message you have in the console might be through the use of an older web search module. I know Rob's said he's experienced it though, so not sure.
I still see them. Since Howard posted his list of plug-ins, I’ll compare it to mine and see if I can narrow it down.
Howard Melman
So I had thought I needed to download plugins separately but I didn't see anything about that in the wiki. New plugins installed. And I updated the Where is Everything page on the wiki with a note.
Howard
Howard Melman
For a more complete reply:All plugins still show older dates (itunes is 2/13/08 everything else is 07 or before), Do I understand correctly that this is just a display issue (dates still coming from blacktree but plugins have been updated?)Yep, that's correct. When we get everything on QSApp.com it should work properly
Web search for "Itchy & Scratchy" didn't quite work (issue 313).
Works fine here. Just to be sure. It required ß60 and the latest web search module from http://qsapp.com/plugins The '&' should be encoded to '%26'
The shelf seems ok, the contents are correct, but it double displays text now.I think I may have seen this, but it's working fine for me now...
The new action Get Path was disabled at first.That's the desired behaviour. Rob's reasoning on this is here:
The encoding error message you have in the console might be through the use of an older web search module. I know Rob's said he's experienced it though, so not sure.The other messages are known 'problems', but fixing them is the unknown thing ;)
Rob McBroom
> The cyberduck module did not replace my existing one, both were installed and active. That seems undesirable.
I had to rewrite it from scratch and probably chose a different bundle ID. I’ll be sure not to do that in the future.
> I'm impressed that my triggers that used Current Web Page all still work and are renamed Current Web Page (Safari)
Yeah, I noticed the same thing. QS uses the internal identifier for the proxy instead of the displayed name (thankfully).
> Also the path display changed from using ~ to using a full path, I don't like this as much as the useful stuff is cut off.
I wonder if that’s because of this: https://github.com/quicksilver/Quicksilver/commit/ca5b51859369b8493bab445493d9124e5040c180
Though I can’t explain how you ever had a ~ path there to begin with. We could change this to be relative path using ~, but I think that would affect the details string for every file object.
Howard Melman
I brought up a contact in the first pane. Show Contact is the highest ranked action for S (I checked this by typing S in the 2nd pane). But if in the first pane I type shift-cmd-S it runs Show Source in Catalog or Put on Shelf (the 2nd and 3rd ranked actions for S). In fact if I do it over and over it switches between those two but not Show Contact.
Not a deal breaker, but it is a function I use pretty often as it's a great time saver.
Howard
(Enjoy the holiday weekend, if you celebrate it. :)
Patrick Robertson
Rob McBroom
> Doh, it seems cmd-shift-letter in the first pane, no longer executes the highest ranking action for that letter, it's not even consistent.
I had the same problem, but it was with an in-progress build of the TextStart ranker (formerly the TextMate ranker). Are you using that? If so, make sure you have the latest and make sure an old copy with the “TextMate” name isn’t laying around. (And make sure it’s set right under Handlers.)
Howard Melman
Doh, it seems cmd-shift-letter in the first pane, no longer executes the highest ranking action for that letter, it's not even consistent.
Never knew about this before. An interesting feature!I've just tested it on the latest HEAD and I don't have any problems. It runs the correct action as expected. The only time it doesn't run is for letters such as A and F but these correspond to Assign Abbreviation... and Open File... so need an iObject.Have you tried clearing your cache?... Just tried with ß60 and it also works fine for me. Maybe something quirky happened during the upgrade?
On Jul 1, 2011, at 9:35 AM, Howard Melman wrote:Doh, it seems cmd-shift-letter in the first pane, no longer executes the highest ranking action for that letter, it's not even consistent.
I had the same problem, but it was with an in-progress build of the TextStart ranker (formerly the TextMate ranker). Are you using that? If so, make sure you have the latest and make sure an old copy with the “TextMate” name isn’t laying around. (And make sure it’s set right under Handlers.)
Patrick Robertson
Howard Melman
Rob McBroom
> I note that shift-cmd-E does run the Edit Contact action as expected, but shift-cmd-S still does not run Show Contact. That confuses me.
I’m not able to reproduce this either. I went back to B60 just to see if it was something that’s been fixed since then, but I still couldn’t reproduce. ⇧⌘E runs the Edit Contact action like you said. On my system, Show Contact is the default, but the first action when typing S in the second pane is Spotlight in Window, which is what I get if I hit ⇧⌘S. Useless, but correct.
What interface are you using? Have to tried it in another? (No, it shouldn’t matter but I’m running out of ideas.)
Howard Melman
On Jul 6, 2011, at 1:09 PM, Rob McBroom wrote:
> On Jul 6, 2011, at 9:36 AM, Howard Melman wrote:
>
>> I note that shift-cmd-E does run the Edit Contact action as expected, but shift-cmd-S still does not run Show Contact. That confuses me.
>
> I’m not able to reproduce this either. I went back to B60 just to see if it was something that’s been fixed since then, but I still couldn’t reproduce. ⇧⌘E runs the Edit Contact action like you said. On my system, Show Contact is the default, but the first action when typing S in the second pane is Spotlight in Window, which is what I get if I hit ⇧⌘S.
I don't understand. How can Show Contact be your default action but something else appear when typing S in the 2nd pane? AFAIK actions are not like catalog items, they work solely on the rank in the Actions prefs. If Show Contact is ranked higher than S should bring that up first.
> Useless, but correct.
>
> What interface are you using? Have to tried it in another? (No, it shouldn’t matter but I’m running out of ideas.)
I'm using Bezel. I can try another later today. Any particular suggestions (I haven't kept up with which interfaces are working these days).
Howard
Patrick Robertson
Howard Melman
philostein
Regarding the ⇧[letter] issue where a different Action is selected in
pane 2 than the default for [letter]:
When I press ⇧[letter] and mouse to an Action from the list in pane 2,
I can click the dot and 'Set as Default for [letter]'. This becomes
the default for ⇧[letter], and is independent of the default for
[letter]. Make ⇧[letter] and [letter] defaults for the same Action to
have the expected result. I think this is more versatile, but the
letter in the contextual menu should reflect whether it's capitalized
or not. Currently it's always capitalized.
I have 'Capitalized keys modify action…' checked in Prefs. Unchecking
this means the same system can be used in pane 1 to set different
default Objects for [letter] and ⇧[letter].
> 225KViewDownload
>
>
>
> Hmm, so FYI, Captialized keys modify action in command window is not checked. The above is what happens if I right click on the Show Contacts action. The others are similar but without the "Rank: 2". I don't see anything as Rank 1. Show Source in catalog is Score 193 and Put on Shelf is 185. I don't recall ever having done Set as Default for "S" but it's possible, is there a way to check that?
>
> Howard
Rob McBroom
> How can Show Contact be your default action but something else appear when typing S in the 2nd pane? AFAIK actions are not like catalog items, they work solely on the rank in the Actions prefs. If Show Contact is ranked higher than S should bring that up first.
I think that’s what you’d see with a fresh installation, but after QS starts learning, these will deviate.
On Jul 6, 2011, at 4:10 PM, Howard Melman wrote:
> I don't recall ever having done Set as Default for "S" but it's possible, is there a way to check that?
For catalog items, I think this is all determined by ~/Library/Application Support/Quicksilver/Mnemonics.plist. I don’t see any actions mentioned in mine and I don’t see specific sequences of keys mentioned in Actions.plist, so I’m not sure where it’s stored.
Lvood
works very well up to now (despite one crash, where the Quicksilver
window could not be hidden and no text could be entered any more).
It feels more responsive than b58 - thanks to everyone who has
contributed to this update!!
Kind regards
Martin
Howard Melman
So I'm still having this problem with cmd-shift-s in the first pane not running the default action Show Contacts but rather doing Show Source in Catalog. I'm running the latest on Snow Leopard (QS B61 (3900) 10.6.8. MacBookPro4,1 Intel Core 2 Due 2.4GHz, 4 GB RAM). I've tried quitting QS, removing these folders and restarting:
~/Library/Caches/Quicksilver/
~/Library/Caches/com.blacktree.Quicksilver/
There was no ~/Library/Application Support/Quicksilver/Caches/ folder.
Show Contact is the default action for S for a contact and appears if I type it in the second pane (as shown below). The same is true for Edit Contact and cmd-shift-e which does perform Edit Contact as expected. I don't have the TextMate Ranker installed and have no duplicate plugins and I believe they are all up-to-date.
Patrick Robertson
I have a lot of triggers defined and a number of catalog sources and other preferences (including action ranking) that I'm not particularly interested in reseting all my preferences.
Does anyone know where this information is stored? I looked in Actions.plist and the only thing that seems odd is in actionPrecedence, QSABContactShowAction has the value 3 while most have the value 0 (including QSObjectShowSourceAction) and some have other integers and some have decimal values like 0.5, -0.5 and 0.1000000014901161.
Mnemonics.plist has the following under Root -> abbreviation for e and s:
Thanks for any help.
Howard
Henning Jungkurth
"Show Contact" as default both for "s" and "S" and now it works.
Are lowercase and uppercase letters really supposed to be something
different? Or is that a bug?
philostein
If it's not Show Contact, try scrolling down the drop-down list till
you find it, and pressing ⌘⌃d twice.
This works for me in ß61, and it worked for all the Actions I did it
with in ß60.
On Nov 8, 5:16 am, Patrick Robertson <robertson.patr...@gmail.com>
wrote:
>
> * From my limited testing it seems 's' and 'S' are considered different by
> QS. I'm guessing you've got the right one
> * Rob's done a bit of work cleaning up mnemonics, he'll probably have a
> good idea where the things are stored.
> * He may also be able to send over a script that can 'clean up' your
> mnemonics.
>
philostein
that QS doesn't show lowercase s in the contextual menu behind the
grey dot in the drop-down list. It's always a capital s, no matter
what the case of the mnemonic is.
On Nov 8, 7:04 am, Henning Jungkurth <henning.jungku...@gmail.com>
wrote:
> "Show Contact" as default both for "s" and "S" and now it works.
> Are lowercase and uppercase letters really supposed to be something
> different? Or is that a bug?
>
> On Mon, Nov 7, 2011 at 9:16 PM, Patrick Robertson
>
>
>
>
>
>
>
> <robertson.patr...@gmail.com> wrote:
> > All that I can think of off the top of my head is:
> > * From my limited testing it seems 's' and 'S' are considered different by
> > QS. I'm guessing you've got the right one
> > * Rob's done a bit of work cleaning up mnemonics, he'll probably have a good
> > idea where the things are stored.
> > * He may also be able to send over a script that can 'clean up' your
> > mnemonics.
>
Henning Jungkurth
> I'm pretty sure it's a feature. Don't fix it! :) The bug should be
> that QS doesn't show lowercase s in the contextual menu behind the
> grey dot in the drop-down list. It's always a capital s, no matter
> what the case of the mnemonic is.
Ok, but then it should show up as lowercase/uppercase everywhere. The
top of the resultslist as well as the "Set/Remove as Default for..."
Howard Melman
Indeed, Show Contact was the default for 's' and Show Source in Catalog was the default for 'S'.
I'm not sure if this distinction was always in QS, but I doubt it. I'm certain I've never heard of it before. If it's easy to figure out from git history if it was added post B54 I'd defer to that if it's a bug or a feature otherwise I don't really have an opinion.
Howard
philostein
alternative mnemonic for that letter, and it allows the new mnemonic's
Action to be called up from pane 1 or 2.
It's possible to create different mnemonics using the same string of
letters, but a different mixture of cases.
The ⌘ modifier only works on single ⇧letter mnemonics.
I bet it was always around. Howard, you said in your manual the result
of ⌘⇧letter Commands was sometimes unclear. Probably because the same
Action would often come up coincidentally for letter and ⇧letter
making it unclear that there was a difference between the two.
> Ok, that fixed it for me!
>
> Indeed, Show Contact was the default for 's' and Show Source in Catalog was the default for 'S'.
>
> I'm not sure if this distinction was always in QS, but I doubt it. I'm certain I've never heard of it before. If it's easy to figure out from git history if it was added post B54 I'd defer to that if it's a bug or a feature otherwise I don't really have an opinion.
>
> Howard
>
> On Nov 7, 2011, at 5:04 PM, Henning Jungkurth wrote:
>
>
>
>
>
>
>
> > I just tried what Howard said and had the same problem. But then I set
> > "Show Contact" as default both for "s" and "S" and now it works.
> > Are lowercase and uppercase letters really supposed to be something
> > different? Or is that a bug?
>
> > On Mon, Nov 7, 2011 at 9:16 PM, Patrick Robertson
> > <robertson.patr...@gmail.com> wrote:
> >> All that I can think of off the top of my head is:
> >> * From my limited testing it seems 's' and 'S' are considered different by
> >> QS. I'm guessing you've got the right one
> >> * Rob's done a bit of work cleaning up mnemonics, he'll probably have a good
> >> idea where the things are stored.
> >> * He may also be able to send over a script that can 'clean up' your
> >> mnemonics.
>
Rob McBroom
> * Rob's done a bit of work cleaning up mnemonics, he'll probably have a good idea where the things are stored.
> * He may also be able to send over a script that can 'clean up' your mnemonics.
The script makes up for a previous bug as described in the fix.
https://github.com/quicksilver/Quicksilver/pull/446
It’ll remove useless entries [potentially] speeding up the matching process. We’ve talked about including the script in a couple of Quicksilver releases and having it run in the background, but I’m not sure of the best way to handle that.
Feel free to run it manually for now (`python clean_mnemonics.py` in the Terminal). Your original file will be copied to the Desktop. Hang onto it in case you run into any problems. It’ll quit Quicksilver for you and restart it after, so leave it up and running.
Rob McBroom
> Indeed, Show Contact was the default for 's' and Show Source in Catalog was the default for 'S'.
>
> I'm not sure if this distinction was always in QS, but I doubt it. I'm certain I've never heard of it before. If it's easy to figure out from git history if it was added post B54 I'd defer to that if it's a bug or a feature otherwise I don't really have an opinion.
Agreed. When in doubt, I always see how B54 behaves. It still runs in Lion. Care to try it out and see what you find?
Howard Melman
On Nov 8, 2011, at 12:52 AM, philostein wrote:
> Howard, you said in your manual the result of ⌘⇧letter Commands was sometimes unclear. Probably because the same Action would often come up coincidentally for letter and ⇧letter making it unclear that there was a difference between the two.
I wrote: "To make it faster you can type the letter with the ⇧⌘ modifiers from the first pane. So to edit Ashish’s contact entry I would activate Quicksilver, type a to bring up her entry and then type ⇧⌘E to have Quicksilver execute the command. This only allows you to use one letter to identify the action and has the same risk that you have to know what action will be run, but if you do, it can be convenient."
What I meant about it being confusing was that a (novice) user would need to know what the default action for a (single) letter was with no visual hints (like a results list) and no opportunity to check before the command is run. In this case that E was for Edit Contact. It's more confusing because the default changes based on the type of the object in the first pane. For a URL E might run Email To...
I'm surprised the whole Actions section is still TODO but I do remember being surprised when I learned that actions worked differently from objects, that the matching algorithm wasn't really used and that actions were ranked in the preferences (which I note at the end of the matching algorithm section).
I know that OS X confuses the issue. Shortcuts in menus are always shown as uppercase letters even though you type the lowercase counterpart and only use the ⇧ if it's explicitly indicated. Quicksilver does the same at the top of the results list (at least in Bezel) showing what you typed in all uppercase even when you type in all lowercase.
Quicksilver's (apparently current) behavior of allowing different defaults for different cases of action strikes me as inconsistent because action names are case insensitive and QS's matching algorithm is also case-insensitive (thankfully). The action named "Edit Contact" appears if I type e or E. In the Action Preferences I see the same list of actions (in the same order) whether I search there for e or E. Also, (as you noted) in the actions results lists if I right click the menu choice says 'Set as Default for "E'"' even if I type 'e'.
If there was UI to examine and modify the saved the mnemonics, abbreviations and defaults then I'd be more accepting. But without it, this seems like an easy way to confuse things without that much gain. In fact what is the potential benefit? You can't type two different quick shortcuts using ⌘⇧ because you can't type a lowercase letter with that combination. In the case of "Capitalized keys modify action in command window" you can't type a lowercase letter to run a different command. I suppose in normal usage in the second pane you could match differently for upper and lowercase, but does QS actually do that?
I guess I do care. :)
(And note, I'm just talking about what QS should do here, whether this is a bug or a feature. I'm not discussing or qualified to discuss the potential risk of fixing this breaking something else, I leave that to the developers to consider and prioritize.)
Howard
Howard Melman
QS seems to be working fine and startup does seem a little faster.
Howard
Rob McBroom
> And note, I'm just talking about what QS should do here, whether this is a bug or a feature. I'm not discussing or qualified to discuss the potential risk of fixing this breaking something else, I leave that to the developers to consider and prioritize.
I see no benefit to case-sensitivity in matching (especially when it’s inconsistent and undiscoverable), and you’ve run across an obvious drawback.
On Nov 10, 2011, at 12:59 PM, Howard Melman wrote:
> I ran it and my Mnemonics.plist went from 1.4MB to 889KB. I guess in six years of usage QS learned a lot about what I typed. :)
I forget exact numbers, but mine was reduced by about 40%. Users of the comma trick will see a more dramatic change. I’m sure you fall into that group. :-)
> QS seems to be working fine and startup does seem a little faster.
I don't know about startup, but matching should be faster. (It only has to look at half as much stuff.)
And you shouldn’t need to run it again. The useless entries shouldn’t be created by B61 or later.
The one exception I guess is that it removes references to files that don’t exist. If you’re worried about those building up, you could run it again.
philostein
lowercase letter will find any Object that contains that letter,
whatever the letter's case is in that Object.
Typing a lowercase letter into pane 2 is comparable - any Action that
contains that letter can be found, and assigned as the default using
the drop-down list's contextual menu. It makes sense that typing 'e'
will result in different Actions for different types of Objects, as
the list of Actions generated is different.
The Action 'Edit Contact' appears for 'e' and 'E' because initially QS
will often decide that both cases should default to the same Action.
Try typing ⇧e in pane 1, and assigning that to a different Action in
pane 2. 'E' and 'e' should now return different Actions.
One benefit of having different Actions for different case: the most-
used Action can be executed with ⌘⇧e (for example), and the next most-
used Action can be executed with just ⇥e (from pane 1).
I don't really view ⇧letter as a matter of case. Shift is a modifier
that allows a letter to be assigned to another Action. It also moves
the focus from pane 1 to pane 2. I view ⇧letter Actions as a 'Trigger
creation' process - once an Action has been assigned to ⇧letter,
⌘⇧letter becomes a QS 'internal Trigger' for that Action/Command. This
is a pretty neat feature. Users need to know what Action ⇧letter will
return before using it as an internal Trigger, but that's the same for
the lowercase letter in normal use (particularly if users like to hold
the letter to execute the Command immediately). If users set the
⇧letter abbreviation in the contextual menu, they're likely to know
what'll be the result of the internal Trigger.
Perhaps QS should show the case of letters typed in the interface.
Here's a post I wrote about ⌘⇧letter Triggers:
http://lovequicksilver.com/post/7413266835/putting-in-a-shift
For me it's like advanced features will be shortly - there for the
experienced user, but unlikely to affect novices.
*Edit* Capital letters can be used in pane 1. When ‘Capitalized keys
modify action in command window’ is unchecked, case affects the Object
returned, but previously setup ⌘⇧letter Triggers still work.
Howard Melman
On Nov 11, 2011, at 2:58 AM, philostein wrote:
> Typing in pane 1 is consistent with OS X menus, in that typing a
> lowercase letter will find any Object that contains that letter,
> whatever the letter's case is in that Object.
I don't think these are the same. Pane 1 matches case-insensitive.
OS X menus show uppercase letters when they explicitly mean lowercase letters because they show the ⇧ explicitly. It's consistent with the markings on the keyboard which also show uppercase letters (though not on the soft keyboards like in iOS and in the keyboard viewer in OS X). If there are shortcuts for ⌘A and ⇧⌘A you always get one command or the other based on whether the shift is used. If there is just a shortcut for ⌘A and non for ⇧⌘A then typing ⇧⌘A will never run the ⌘A command. OS X menus are not case insensitive.
> Typing a lowercase letter into pane 2 is comparable - any Action that
> contains that letter can be found, and assigned as the default using
> the drop-down list's contextual menu. It makes sense that typing 'e'
> will result in different Actions for different types of Objects, as
> the list of Actions generated is different.
Obviously when the list of actions are different (as with different object types) you'll see different results. The question is whether the matching is done case sensitively or insensitively. If both e and E yield the same results (and in the same order) then it's insensitive and that's what I see unless an a default is assigned.
> The Action 'Edit Contact' appears for 'e' and 'E' because initially QS
> will often decide that both cases should default to the same Action.
> Try typing ⇧e in pane 1, and assigning that to a different Action in
> pane 2. 'E' and 'e' should now return different Actions.
It's certainly true that the match could be sensitive and unless something explicit is done it behaves as insensitive. If that's the case then once I do that I want everything in QS to behave the same case sensitive way. That's why I tried the search field in the action preferences. Even if defaults are set differently for the same letter with different cases, it still shows the same list of actions in the same order.
Also the "Capitalized keys modify action in command window" option only works for a single case. If I set a different default for S and s then I can never choose the s action from the first pane. And even without that (advanced) option the ⇧⌘S trick works and only with a single case. There's no way to run the s action.
Now you can argue that that makes uppercase letter defaults special, but I think it's more consistent with QS behavior to say action name matching is case insensitive.
> One benefit of having different Actions for different case: the most-
> used Action can be executed with ⌘⇧e (for example), and the next most-
> used Action can be executed with just ⇥e (from pane 1).
>
> I don't really view ⇧letter as a matter of case. Shift is a modifier
> that allows a letter to be assigned to another Action. It also moves
> the focus from pane 1 to pane 2. I view ⇧letter Actions as a 'Trigger
> creation' process - once an Action has been assigned to ⇧letter,
> ⌘⇧letter becomes a QS 'internal Trigger' for that Action/Command. This
> is a pretty neat feature.
Agreed. Trigger isn't quite the right word (and terminology in QS unfortunately inconsistent) but I did use ⇧⌘S all the time for Show Contact and ⇧⌘E for Edit Contact and there would be no way to create a real trigger to do such a thing. Sure tab s return is similar but ⇧⌘S is faster. That's why I describe it in the manual in a section titled "Immediate Execution".
> Users need to know what Action ⇧letter will
> return before using it as an internal Trigger, but that's the same for
> the lowercase letter in normal use (particularly if users like to hold
> the letter to execute the Command immediately). If users set the
> ⇧letter abbreviation in the contextual menu, they're likely to know
> what'll be the result of the internal Trigger.
>
> Perhaps QS should show the case of letters typed in the interface.
Well that's the problem. It's fine until you accidentally set it as I apparently did. And the UI doesn't help. The results list in the second pane does change the order if you type s or S but that's all.
But still the behavior of ⇧⌘s in the first pane or ⇧s with "Capitalized keys modify action in command window" seems to suggest that action names are meant to be case insensitive. If case was supposed to matter, why choose shift as the modifier for that option? Why not say 'hold down option to modify action in first pane' then you could type either lower or uppercase letters in the first pane to match actions. I think the fact that shift is used indicates that it's supposed to be used as a modify and case doesn't matter (for either objects or actions).
> Here's a post I wrote about ⌘⇧letter Triggers:
> http://lovequicksilver.com/post/7413266835/putting-in-a-shift
It's a good post, I have issues with one paragraph:
"Try to avoid using ⇧⌘[letter] key combos for Triggers made in Preferences, as they will override the equivalent internal versions. Internal Triggers are not useful for Actions that use pane 3; QS will carry out the Command without waiting for the necessary user input. There’s at least one combo that shouldn’t be used - ⇧⌘Q activates the system’s logout panel."
The reason to using ⇧⌘[letter] for trigger keys is because many applications define shortcuts on such keys (mostly commonly ⇧⌘Z is redo). It's not just for QS "internal triggers". Also while using ⇧⌘[letter] isn't helpful for actions that use the third pane, checking "Capitalized keys modify action in command window" and using ⇧[letter] works just fine.
> For me it's like advanced features will be shortly - there for the
> experienced user, but unlikely to affect novices.
I (now) get that having two different single key action defaults (if you count both s and S as single keys which I do) is a pro. But I think it's not supported in any other part of QS and so I think it's a bug and not a feature. To support it in the other places I think would require a few (somewhat odd) things.
1. The results list would have to show what's typed in it's exact case (easy)
2. "Set as default" would need to show the right case (easy)
3. The search field in the actions preferences would need to show different results based on the case entered (weird)
4. "Capitalized keys modify action in command window" should probably change to option or something (odd)
5. ⇧⌘[letter] should change to something else, I'm not sure what, to allow it to work for both cases of letters. (running out of usable modifier combinations).
Howard
philostein
you have one in consistency and I have one in flexibility.
However, I don't think QS is as inconsistent as you posit. I've
answered your points:
> > Typing in pane 1 is consistent with OS X menus, in that typing a
> > lowercase letter will find any Object that contains that letter,
> > whatever the letter's case is in that Object.
>
> I don't think these are the same. Pane 1 matches case-insensitive.
item 'Open'. In pane 2, typing 'open' and 'Open' both find (for me)
the 'Open' Action. The effect is similar in pane 1 when 'Capitalized
keys modify action in command window' is unchecked. This is
consistent.
> OS X menus show uppercase letters when they explicitly mean lowercase letters because they show the ⇧ explicitly. It's consistent with the markings on the keyboard which also show uppercase letters (though not on the soft keyboards like in iOS and in the keyboard viewer in OS X). If there are shortcuts for ⌘A and ⇧⌘A you always get one command or the other based on whether the shift is used. If there is just a shortcut for ⌘A and non for ⇧⌘A then typing ⇧⌘A will never run the ⌘A command. OS X menus are not case insensitive.
see this as the shift modifier creating a new shortcut for a new
command. The command returned doesn't have a different case. In
Finder's File menu, ⌘T shows 'Add To Sidebar', and ⇧ modifies it to
'Add To Dock'. In the same menu, ⌘N executes 'New Finder Window', and
⇧⌘N executes 'New Folder'. The last two commands occupy different
spaces in the menu. Whether shift-modified commands are modified in-
line, or occupy different spaces in the menu is dependant on how often
Apple feels they are used, and not on the case of the shortcut (or the
command).
⌘A and ⇧⌘A are separate shortcuts executing separate commands. If
there's no command for ⇧⌘A, then I agree, pressing ⇧⌘A shouldn't
execute the ⌘A command. The shift modifier is a device Apple often
uses to give functionally similar (but distinct) commands similar (but
distinct) shortcuts.
> Obviously when the list of actions are different (as with different object types) you'll see different results. The question is whether the matching is done case sensitively or insensitively. If both e and E yield the same results (and in the same order) then it's insensitive and that's what I see unless an a default is assigned.
associate a shift-modified letter with an alternative Action/Command
than the unmodified letter. For me, this is analogous to the ⌘T and
⇧⌘T example in Finder, except a 't' has to be present in the Action.
> It's certainly true that the match could be sensitive and unless something explicit is done it behaves as insensitive. If that's the case then once I do that I want everything in QS to behave the same case sensitive way. That's why I tried the search field in the action preferences. Even if defaults are set differently for the same letter with different cases, it still shows the same list of actions in the same order.
unmodified or modified letter doesn't return as the top result the
Action that letter returns in pane 2. It lists the Actions that
contain that letter in the same order as the un-searched list. Search
is case insensitive. Again, analogous the the search field in OS X
menus.
> Also the "Capitalized keys modify action in command window" option only works for a single case. If I set a different default for S and s then I can never choose the s action from the first pane. And even without that (advanced) option the ⇧⌘S trick works and only with a single case. There's no way to run the s action.
in effect deciding their top Action for that Object and letter. I made
⇧d the default for 'Dropbox public link' when handling file Objects,
as I use that more than 'Set Desktop Picture' (the default for 'd').
It should be an explicit process - one which will help the user to
understand which Command will be executed using ⇧⌘d.
> Now you can argue that that makes uppercase letter defaults special, but I think it's more consistent with QS behavior to say action name matching is case insensitive.
shift-modified letters can provide an alternative default Action.
> But still the behavior of ⇧⌘s in the first pane or ⇧s with "Capitalized keys modify action in command window" seems to suggest that action names are meant to be case insensitive. If case was supposed to matter, why choose shift as the modifier for that option? Why not say 'hold down option to modify action in first pane' then you could type either lower or uppercase letters in the first pane to match actions. I think the fact that shift is used indicates that it's supposed to be used as a modify and case doesn't matter (for either objects or actions).
modified letters appearing to indicate case when returning alternate
Actions. I did a quick test though, and searching for ⌥letter in pane
1 returns some results, including ⌥a and ⌥s (the curse of eszett
strikes again). ⌥m for µTorrent anyone? Shift is good in that search
is case insensitive, so ⇧letter doesn't affect the list of Actions
available in pane 2.
> The reason to using ⇧⌘[letter] for trigger keys is because many applications define shortcuts on such keys (mostly commonly ⇧⌘Z is redo). It's not just for QS "internal triggers". Also while using ⇧⌘[letter] isn't helpful for actions that use the third pane, checking "Capitalized keys modify action in command window" and using ⇧[letter] works just fine.
their own shortcuts, which can cause conflicts with other system
shortcuts. It's a small issue though. If pane 3 defaulted to 'Type to
search' when using internal triggers that require it, it would be
extremely useful!
> > For me it's like advanced features will be shortly - there for the
> > experienced user, but unlikely to affect novices.
>
> I (now) get that having two different single key action defaults (if you count both s and S as single keys which I do) is a pro. But I think it's not supported in any other part of QS and so I think it's a bug and not a feature. To support it in the other places I think would require a few (somewhat odd) things.
>
> 1. The results list would have to show what's typed in it's exact case (easy)
> 2. "Set as default" would need to show the right case (easy)
> 3. The search field in the actions preferences would need to show different results based on the case entered (weird)
> 4. "Capitalized keys modify action in command window" should probably change to option or something (odd)
> 5. ⇧⌘[letter] should change to something else, I'm not sure what, to allow it to work for both cases of letters. (running out of usable modifier combinations).
interface, so I don't think they need to be supported anywhere else in
the program.
1. I agree.
2. I agree.
3. I disagree. Search should always be case insensitive, as results
are not based on Actions' order in pane 2.
4. A good idea, but what to use? Also, what would QS show as typed? At
least with shift, QS can show capital letters easily.
5. Yeah, tricky. As you said, ⌘⇧letter shortcuts are widely used in OS
X, so aren't often used for *real* QS Triggers. That makes ⌘⇧letters
great for *internal* Triggers - they don't conflict. Using option or
control would result in ⇧⌥⌘letter or ⌃⌥⌘letter shortcuts, which would
likely conflict with users' *real* Triggers.
Sorry if I didn't make my points clear, or I've misunderstood your
concerns. It'd be easy to do… :)
In summary, search is case insensitive. The shift modifier allows for
alternative Actions using the same letter, and also ⇧⌘letter internal
Triggers.
My wish-list:
1. Keep shift as the modifier to define alternate Actions (unless a
better one is found).
2. QS to show the case of letters typed in the panes, results list and
contextual menu.
3. Change 'Capitalized keys modify action in command window' to 'Shift-
modified letters snap to their Alternative Action in pane 2', or
similar
4. Make the third pane default to 'Type to search' anytime a file is
required (and not just with ⇧⌘letter shortcuts).
5. Promote the shift modifier as also a 'Trigger creation' process for
⇧⌘letter shortcuts - remember, 'Capitalized keys…' doesn't have to be
checked for this to work
Rob McBroom
> I (now) get that having two different single key action defaults (if you count both s and S as single keys which I do) is a pro. But I think it's not supported in any other part of QS and so I think it's a bug and not a feature.
I fired up B54 (which like I said, runs fine under Lion). S and s match the same action. You cannot use ⇧ to assign an additional “shortcut”.
As for any functionality lost by this revelation: Using the “Dropbox public link” example, I have to wonder, is hitting D then B (or P or L) really that much harder than hitting ⇧ then D? To me it seems even easier, as you don’t have to hold one down.
Howard, did you ever report this as an issue on GitHub? I couldn’t find it mentioned.
Howard Melman
I did not, since it seemed that only two of us were discussing it and hadn't come to consensus. :) Also I was going to reply but got busy this week and hadn't gotten to it yet.
Howard