After a double-click on a script name in the Quick open window, the window is dismissed, the search and found files are lost.
Is it possible to change this behavior and keep the window open until we click on a Close button?
In some case it could be very helpful.
That goes against every other implementation of a quick open feature Iâve ever used. If you really want to open multiple items based on the same search string, command-click them to select multiple files.
My need is not to open several files at once.
I know how and when to use Command-click or Shift-click.
If you think itâs useless, itâs ok for me.
BBEditâs stays open by default:
By default, the âOpen File by Nameâ window stays open when you click the âOpenâ button. However, if you would prefer for it to act more like a modal dialog, you may do so:
But you can change the behavior with an expert preference.
And the state of the window when it was closed is saved, so your query is preserved.
-Chris
Please explain to me why you want this behaviour. How would you use it?
Letâs say some terminology has changed in a library or an app youâre using in dozens of scripts.
To update your scripts with no confusion, you want to open only 2 docs at a time, side by side.
One to pick up the code an the second as the receiver.
In this case (and some other like this), youâll be happy to find your query unchanged, giving you the ability to open the next file in the queue.
[I hope my bad english understandable ;)]
It seems to me that the core feature request is to retain the query and its results so that you can quickly summon the list again. Leaving the window open is not really needed, and I would argue that wouldnât really work given that Open Quickly operates as a sheet when dealing with tabbed windows.
Youâre absolutely right!
As I never use tabs, I havenât thought about it.
Thatâs it.
@ccstone
Witch version of SD?
@alldritt
Some files, in the Quick Open window, appear 2 times: at top and bottom of the list.
My guess is that those files are duplicated in the list because their name and their content contains the query.
Is it an issue?
Script Debugger 6.0.1 (6A180) on OSX 10.11.6
Hereâs and idea: Would it be possible to add a button to the Open Quickly results window to âShow Results in Finderâ Clicking that button would open a Finder/Spotlight search window with the same results displayed in Open Quickly.
This would make OQ a little more useful, as it would not just help open files, but locate where the various versions are stored.
While weâre at it, how about a Quickly Open button on the tool bar? (The more I use it, the more I like Quickly Open)
@ccstone
Same version here but on Yosemite.
As you can see on the screenshots above, everything is fine.
Did you check yours prefs?
@estockly
Whatâs the benefit of a button to open Spotlight?
A âShow in Finderâ button Would not be more appropriate?
Iâm a big fan of open quickly too. Itâs one of my favourite âicing on the cakeâ features of Script Debugger.
That said, note that (pace Mark correcting me) all itâs doing is running an mdfind and filtering out the results for scripts and script bundles. Should you, heavens forbid, be temporarily on a machine bereft of SD for some reason, you can achieve a quick-and-dirty** similar effect in Terminal with
mdfind "<search phrase>" | grep scpt
So, if I want to find all the scripts and bundles that Iâve, say, used any ASObjC in, I could do
mdfind "use framework" | grep scpt
on the command line.
** wonât capture .applescript plain text files, though
(Apologies if this is a double post, I replied to this via email, and it doesnât show up as a post.)
A âShow in Finderâ button Would not be more appropriate?
I think a show finder option (control-click on selected found files, maybe) would also be a really good idea. I had assumed it was already there, but I guess not.
Whatâs the benefit of a button to open Spotlight?
After you click the button a finder window would open with the spotlight search results, the same results displayed in the SD Quickly Open window.
From there you could easily locate, rename, move, duplicate as many of the files and their folders as you wish. The results of your search would be persistent (until you closed the finder window.) I would find this very useful, and see it as a closer integration between SD and the mac.
(Of course, itâs easy enough for me to throw out these feature requests like theyâre nothing, but one thing Iâve learned is sometimes changes that I expect to be trivial are not and vice versa, so I just ask, and leave it to Mark, Shane, Matt, etc. to decide if it is worthwhile or doable.)
While you have the basic plumbing correct (Script Debugger uses the Metadata Query API rather then the mdfind command line tool), the search Script Debugger performs for open quickly is much more complex in order to support discontiguous result hits.
As far as I can tell, the Finder does not provide an API for creating a search window. And there is result filtering and relevance ranking happening within Script Debugger to avoid bogus hits which cannot be transferred to the Finder.
Adding a Reveal In Finder feature for individual search hits would be trivial, but anything beyond that is problematic (at least with the understanding of the Finder APIs I have at present).
The Open In Tabs preferences setting controls this. When checked, the Open Quickly window should appear as a sheet over any existing document window.
What your screenshot is showing is incorrect behaviour. Try as I might, I cannot reproduce what you are seeing here (presuming Open In Tabs is checked).
Show in Finder, along with persistent results would be just fine with me!
Also, how about a âRecent Searchesâ pop-up on the search field too?
(We AppleScripters are so needy and demanding!)
One of the complicating factors is that there are two different metadata search APIs. Script Debugger uses one (NSMetadataQuery and predicates) while Finder uses the other, older one (MDQuery). So although thereâs a simple way of telling the Finder to show a search window, it would effectively involve building a separate search. I donât know whether that would be trivial to do or not; Iâve never tried.
