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 > *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. > > On Nov 11, 2:50 am, Howard Melman <[email protected]> wrote: >> 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
