I have to say that I am sure that the cmd-esc to select a file used to always jump to second pane for example and now, or since SL does not meaning the extra tab which is annoying and one reason my use of QS dropped off to almost nothing
I can also not think of one case where i use QS to select something that i don't want it to jump to 2nd pane for relevant actions, QS is all about saving not only mouse use but unnecessary keystrokes for me at least :) -ian On 21 Apr 2011, at 00:08, Tony wrote: > > On Apr 20, 2011, at 4:17 PM, dsanson wrote: > >> First, I like the proposal. But here are some worries about it. >> >> This is probably obvious, but when activated, QS often already has >> something in the first pane---the result of the previous action. This >> might be a document that I recently opened or an application that I >> recently launched or a phone number that I recently looked up and >> copied to the clipboard or displayed in large text. Sometimes I want >> to perform some new action on this thing; sometimes I want to arrow >> away from it (into it, or to one of its neighbors, or to its parent >> folder, etc.); but most often, I want to start a completely new >> search. So this seems like a case where the first pane has been >> populated by some previous activity, but I would not want the second >> pane to be active by default. > > Definitely wouldnt want this either and i dont think thats what either myself > or Rob is suggesting? This would not affect your typical QS invocation but > rather any action that would auto-populate the first pane of QS with some > type of object that you want to perform an action on. > >> So the proposal cannot be read too broadly. The narrowest proposal >> would be to have this behavior for cmd-G and cmd-esc. The one frequent >> use case for me that goes against this is cmd-G (or `qs .`) to get a >> file or folder, then arrowing to browse the file system. But that is >> less frequent, so I could "tab back" to do that. > > Are you saying that sometimes you will be browsing files/folders within your > file manager, then Cmd-Esc/Cmd-g on a folder/file and then continue browsing > the folder within QS? Why not just continue to use the file manager unless i > misunderstood? > >> But Rob's suggestion that it would apply to the result of Get Path >> suggests this behavior not just when the first pane has been populated >> by cmd-G or cmd-Esc, but whenever it has been populated by some >> immediately preceding act (cmd-G, Get Path, etc.) that did not involve >> dismissing QS. >> >> I can't think, of the top of my head, of which actions automatically >> repopulate the first pane with their result and keep QS active. I take >> it that these are all going to be actions that one might wish to daisy >> chain together with other actions. But I suspect I often "break the >> chain" and decide to search for something else instead (or drill >> around with arrows on the result). When I use "Move To...", for >> example, I usually don't go on to do something else to the moved file. > > I have gone through most of the actions that i use which repopulate the first > pane of QS with a result and i cant think of one that i would not rather have > the focus set to the second pane. Now obviously with a tool as powerful and > flexible as QS there are bound to be 10 different ways to achieve the same > result with ppl taking diff paths to get there. However i still feel that > this would really be an added benefit that most users would make use of. > >> Also, the current behavior feels "consistent" to me (but that may just >> be the result of habit), and I worry that the proposed behavior would >> not feel as consistent. I don't want to have to pay attention to the >> details of how I got where I am, and I don't want to have to look >> before knowing whether hitting tab is going to move me from the first >> pane to the second or the second to the first... > > While it may not feel "consistent" in the way you visualize it, it would be > consistent in its application. LaunchBar actually takes this functionality > one step further with its "Instant Send" feature > http://www.obdev.at/resources/launchbar/help/InstantSend.html. I have found > it to be a very effective power feature and ideally i would love to see some > variation of this implemented in QS and perhaps this could be one way to > implement it. Lastly, it might seem "inconsistent" to read or think about it > but once you actually start using it over and over again it really begins to > feel "right" and plays right into QS's motto to "Act without doing" ;-) > > Tony >
