Thanks Howard, It seems we've both got one foot in features, whereas 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. In OS X apps' Help menu, searching for 'open' or 'Open' finds the menu 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. I don't see this as case sensitivity in either command or shortcut. I 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. Yes, matching is insensitive. Subsequently though, QS is also able to 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. The search field has a different function. Searching with an 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. True. In setting a default Action for ⇧letter in pane 2, the user is 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. I'm arguing that both are true. :) Search is case insensitive, and 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). I like your option modifier idea. It removes the confusion of shift- 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. Agreed. OS X shortcuts are usually predefined. Here, the user can set 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). Shift-modified letters have a special function within the QS 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 Nov 12, 3:44 am, Howard Melman <[email protected]> wrote: > 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
