Getting objects by type

[skurfer]

I've added a new method to QSLibrarian that will return an array of objects of a certain type sorted by score. So instead of calling something like

[QSLib scoredArrayForString:nil inSet:[QSLib arrayForType:@"QSBlahType"] mnemonicsOnly:YES];

you can just call

[QSLib scoredArrayForType:@"QSBlahType"];

I've also made a small change to the method that builds type arrays so it will include proxy objects. This means when calling QSLib arrayForType: or QSLib scoredArrayForType:, relevant proxy objects will be returned along with everything else.

Some real-world examples of where this is useful:

• Text ⇥ Find With… ⇥ Current Website (Safari)
• File ⇥ Copy To… ⇥ Finder Selection

And, in returning results sorted by score, I uncovered (and fixed) some bugs in the scoring algorithm. The first three commits address that.

What it was supposed to do: If you search for "xy" and that's never been used before, but "xyz" has been used (or vice versa), increase the score for "xy" a bit based on how often "xyz" has been used.

What it was doing: If the search string was empty, the comparison would always think there was a matching prefix for every abbreviation ever used, so the score would be increased a bit for each one. As a result, if something had 4 abbreviations used 10 times each (40 total) and something else had 3 abbreviations used 1000 times each (3000 total), the thing used 40 times would get a higher rank.

So, I told it not to use that technique for empty strings, and additionally defined specific logic for scoring objects when the search string is nil. (The total usage for all abbreviations is considered. The actual number of abbreviations has no effect.)

[skurfer]

I see NSAccessibilityException over and over when selecting the Move To…/Copy To… actions, but this appears to be a problem with the Current Document proxy. I see the same thing when selecting that proxy object directly in the first pane.

I've also noticed that the inclusion of proxy objects slows down the selection of those actions quite a bit (because they get resolved on the spot). I'm not sure what they best solution is for that. Possibilities:

• Don't resolve proxies until an action is run. Now that they are resolved automatically when actions are run, I wonder if we need to resolve them upon selection. The only reason I can think of is that some might alter their types (and the available actions) depending on context. But most have predictable types. I wonder if we should add a flag to the QSProxies dictionary to identify those that need to be resolved immediately.
• Allow them to be resolved when selected in the first pane, but not the third. That seems like a bit of a hack though.
• Don't pre-populate the third pane for Move To…/Copy To…. (I thought we just did something like this. Was it only when those actions are called via a trigger?)

[pjrobertson]

Allow them to be resolved when selected in the first pane, but not the third. That seems like a bit of a hack though.

Although you say this sounds like a hack, I think it sounds the most plausible. If the proxy isn't actually the right type then you just get an NSBeep or something. Option 1 is pretty similar to this option, except this still resolves the proxy when it's in the 1st pane - a must

Don't pre-populate the third pane for Move To…/Copy To…. (I thought we just did something like this. Was it only when those actions are called via a trigger?)

Yeah, just for triggers so that the default option isn't run. We specifically changed the Move To.../Copy To... actions not too long ago to show the 'current folder' in the 3rd pane to make it easier to move/copy the file(s) to a folder 'close by'

[pjrobertson]

What's the outcome of this? Are you planning on doing this:

Allow them to be resolved when selected in the first pane, but not the third. That seems like a bit of a hack though.

[skurfer]

Yes, I’m still planning to look into it.

[skurfer]

for B71 I think the fix for this depends on #1180. Once we have that, when populating the third pane for Move/Copy To…, we can just test [thisObject isFolder] && ![thisObject isPackage] instead of resolving the path and doing tests on it with NSFileManager and NSWorkspaceManager. That's why it takes so long.

[skurfer]

Reversed the last commit until I can figure out why it causes so many problems when populating the third pane for Moe To/Copy To. It was a minor thing, anyway.

This should be OK to merge now.

[pjrobertson]

@skurfer any ideas how I can reproduce the exception? Other than re-instating your reverted commit?