Various fixes #1029
…se the service on the previous app
… finder (e.g. 1,2...10,11 instead of 1,11,12...2,20,21...)
This has lead me to another bug where it looks like the the ranker doesn't care about strings after the ? character so you can't search http://a.com/?abcde for abcde. At least it now makes finding URLs a bit easier :)
Totally fine, good stuff can always be improved :)
When you have more time to think (during the 64 bit changes), you tend to
On 1 August 2012 00:59, Rob McBroom <
The selection service thing
Sorry, I don't have a handle on all the ways selections make their way into QS. What's supposed to be different here? Is this to address the problem people have when the Dock icon is enabled and they sue "Current Selection" twice in a row? I've tried selecting text in Terminal, then "Current Selection → Large Type". It works the first time, but not the second. With or without a Dock icon. I think it might be because the window itself loses focus, even if the application is still active. I've also tried ⌘⎋ twice in a row and it fails the second time (I think for the same reason).
I tried Terminal, TextMate, and Safari and the frontmost window always becomes inactive when pulling a selection into Quicksilver, so there might not be anything we can do here.
Looks good. Hard to tell with an SSD, but I'll take your word that it's faster. It certainly doesn't look as though it would be slower.
We've already gone over this. I think it'll be a great help to users. (Maybe we should open an issue for that bug you found. I think there are other characters besides
Comma trick duplicates
Never even noticed this, but it should work the way you've made it here. Good catch.
Should we just make it a set instead of an array to avoid this testing, or would that require too many changes in other places (that expect an array)? Sets don't preserve order either, and I know there are some actions that can only handle one object, so they take the first or last. So… maybe ignore me. :-)
Text mode UI
Love this. I never liked the way the text would appear next to the icon behind the text you were typing. It's especially noticable in Nostromo.
I didn't find any interfaces where the results were bad. The "numeric result" icon returned by the calculate action is a little off-putting with this, though. :-)
I remember talking about this before the 64-bit era. Again, I can't really tell a difference, but it seems that this could only be an improvement. The only thing I question is the placement of the new line. Well, that and the use of spaces to indent it, when the rest of the project uses tabs. ;-)
There seem to be some checks on
Hmmm.... I wish I'd sent a pull request when I actually did this. I'm sure I got it working, but alas... I can't now. I'm just reverting.
Not sure what you mean there. From the calculator plugin? It's been around for ages!
OK, another one I wish I'd committed at the time. Seems like QS is already filtering stuff, but not in some cases. I've moved the call a little so it also filters after you've drilled down into something (SearchFilter as opposed to
I've added a few more commits
Sure it did! You mean the the answer to the calculation shows behind the
Like this (The '10')
Anyways, I guess it doesn't matter eh?
On 12 August 2012 04:17, Rob McBroom email@example.com wrote:
I think you're probably right. I'll start squashing things from now on.
That commit shouldn't cause too much problems though as you'll just get a
On 14 August 2012 18:49, Rob McBroom firstname.lastname@example.org wrote:
Yeah, for small things like this, we can probably figure it out. But keep in mind you'd also have to go back and remove the change before going to the next step in the bisect to avoid conflicts.
I like the idea of being able to search the URLs, but at a practical level I find it is kind of "polluting" my global catalog and made it harder to find files, apps, and other things. I think a great feature would be to allow accessing them through a (Catalog) object without them being added to the global catalog - #1066.
Perhaps that's why searching URLs was originally disabled - because it
On 26 August 2012 01:56, David Rees email@example.com wrote:
I'm sure you'll both see my comment on #1066, which I wrote before seeing this here. So that applies here, as well.
As for reverting the change… maybe. There's nothing new in the catalog, so I wouldn't say this is adding pollution, but since URLs can potentially contain so many characters, they are now far more likely to match searches. If you think about it, it's probably not useful to be able to search anything that comes after a
I have found its making hard to find URLs even when I am just searching URLS through Google Chrome -> Other Bookmarks. There are just so many url string matches.
But maybe I have another problem. it also doesn't seem to be prioritizing whole words over letters spread out across the label or url. If you look at this screenshot I am typing "leanstartup" and its picking "How to use Google Contacts as a Unified Address Book" over "The lean startup Arlington Public Library". Its been acting that way for a while, but I tried switching the space behavior and restarting and now its correctly selecting the lean startup entry. Not sure what changed :/.