QS sometimes only gets part of my input

[daniels220]

I swear I heard this being discussed on the group, but there doesn't appear to be an issue for it. I could just be missing something, though.

Sometimes when I invoke QS, type an abbreviation that I know should open a particular app, and press Return really quickly, only some of the letters I typed get noticed and a different app is opened.

I'd be really curious to know how this works, internally, because lots of apps have this problem—Firefox, for instance, when you press Cmd-N anything you type after that (that would go to the location bar) is ignored until the window actually opens. (Actually this is sort of the inverse of the problem with QS, but the mechanism ought to be the same AFAIK.) If it's an easy thing to do I'd submit a Bugzilla ticket too...

[pjrobertson]

Are you running OS X Lion, 10.7?

I have experienced this, which I believe to be a combination of a few things for me:

• Lion 10.7 is a slow operating system
• My 4 1/2 year old MacBook is old and slow
• Apps can't keep up anymore with my finger strokes.

So from my point of view, it isn't a problem with Quicksilver (or Firefox) but the operating system itself. Having said that, Quicksilver has a feature that can allow for slower and older computers. Go into Preferences > Command and alter the "Wait before searching" slider to be slightly longer. I have mine set to 0.15s and it eliminates all my problems!

[daniels220]

I'm running 10.6.8, but computer slowness certainly is the trigger for
the problemthis only happens in real-world usage when QS lags.

However, this is a regression between B61 and B62. I've attached
AppleScripts that send keystrokes to QSin B61 and under they give the
intended result, in B62 anything less than a ~0.01 second delay means that
keystrokes get dropped even when QS is performing well. (The advantage of
such high-speed entry is that it ought to break on any machine, revealing
the real bug.) Other Cocoa apps (TextEdit, AppleScript Editor, Camino, and
Safari, at a minimum) behave as expected, even when they lag terribly (the
Camino script I attached, in particular, causes lags of up to several
seconds on my machinebut all the commands happen, in the right order).

So I decided to do git bisect and the bad commit appears to be
"be854cd... remove featureLevel and related variables/methods - closes
#341". I tried mucking around with some of the changes that commit actually
made but was unable to make any further progress (this is probably because
I don't know Objective-C... :/).

Also, re: search delaythat actually makes the problem worse. The problem
isn't that QS is lagging, it's that the last keystroke or two sometimes
gets droppedso adding a delay makes that more likely, not less. (Yes,
I've tested this with the scripts above, which are obviously an extreme
case but when QS isn't lagging, it takes an extreme case to reveal the
problem at alland I'm not much inclined to intentionally RAM-starve my
machine, thus probably hanging XCode, every time I need to test.)

On Wed, Mar 14, 2012 at 1:25 PM, Patrick Robertson <
reply@reply.github.com

wrote:

Are you running OS X Lion, 10.7?

I have experienced this, which I believe to be a combination of a few
things for me:

• Lion 10.7 is a slow operating system
• My 4 1/2 year old MacBook is old and slow
• Apps can't keep up anymore with my finger strokes.

So from my point of view, it isn't a problem with Quicksilver (or Firefox)
but the operating system itself. Having said that, Quicksilver has a
feature that can allow for slower and older computers. Go into Preferences

Command and alter the "Wait before searching" slider to be slightly
longer. I have mine set to 0.15s and it eliminates all my problems!

---

Reply to this email directly or view it on GitHub:
#758 (comment)

[skurfer]

So I decided to do git bisect and the bad commit appears to be be854cd

That’s a big help, thanks. Removing any traces of “feature level” meant that some things are always on that weren’t necessarily before. Most of these things were already enabled for most users, and I can’t think of what would specifically affect input, but that gives us a starting point.

[skurfer]

I wonder if it’s the moreComing stuff in QSSearchObjectView.m. Could you try commenting out this line and see if it helps?

moreComing = nil != [NSApp nextEventMatchingMask:NSKeyDownMask untilDate:[NSDate dateWithTimeIntervalSinceNow:SEARCH_RESULT_DELAY] inMode:NSDefaultRunLoopMode dequeue:NO];

In the latest master, that should be line 1075.

[daniels220]

Yup, that's it. I figured it had to be in that function but couldn't figure
out what line.

So here's what I think is happening:

1. Invoke QS, send a couple keystrokes. moreComing = true for a little
   while because, well, there is.
2. Pause. moreComing = false. Great. Press return now, and everything
   works.
3. Send more keystrokes and then immediately press return. moreComing =
   true the whole way throughat first because more real keystrokes are
   coming, but critically the pressing of return itself counts as a keystroke
   and keeps moreComing set even past the last alphanumeric keystroke. So QS
   drops that whole last sequence of keystrokes on the floor, because
   evidently when it comes time to actually process the keystroke, return
   is handled separately and just goes ahead and does the search even though
   the search isn't done yet.

The solution, it would seem, is to have pressing return set moreComing to
false (and thus force the search to complete before executing). Here, have
some code (ugly but functionalmodify however you like, or do something
else altogether):

NSEvent * nextEvent = [NSApp nextEventMatchingMask:NSKeyDownMask
untilDate:[NSDate dateWithTimeIntervalSinceNow:SEARCH_RESULT_DELAY]
inMode:NSDefaultRunLoopMode dequeue:NO];
moreComing = (nil != nextEvent && [nextEvent keyCode] != 0x24);

Another approach could be to have the function that executes a command ask
if the search is complete (i.e. there are no keystrokes that haven't been
processed yet) and make it finish if not.

On Thu, Mar 15, 2012 at 11:37 AM, Rob McBroom <
reply@reply.github.com

wrote:

I wonder if its the moreComing stuff in QSSearchObjectView.m. Could
you try commenting out this line and see if it helps?

moreComing = nil != [NSApp nextEventMatchingMask:NSKeyDownMask
untilDate:[NSDate dateWithTimeIntervalSinceNow:SEARCH_RESULT_DELAY]
inMode:NSDefaultRunLoopMode dequeue:NO];

In the latest master, that should be line 1075.

---

Reply to this email directly or view it on GitHub:
#758 (comment)

[daniels220]

Hey, any update on the status of this issue?

[skurfer]

Hey, any update on the status of this issue?

I’ve got a branch where I’ve removed the moreComing code entirely. I don’t understand it’s purpose, but I could be missing something so I want to test it a while before I put it in a pull request. (I understand the goal, it just seems that the goal is met without it.)

As you ask for the status, please understand that this is much faster than typical for us to look at something. As you can see, there are nearly 200 issues open. :-)

[daniels220]

Oh, sorry for bothering.

On Thu, Mar 22, 2012 at 9:17 AM, Rob McBroom <
reply@reply.github.com

wrote:

Hey, any update on the status of this issue?

Ive got a branch where Ive removed the moreComing code entirely. I
dont understand its purpose, but I could be missing something so I want
to test it a while before I put it in a pull request. (I understand the
goal, it just seems that the goal is met without it.)

As you ask for the status, please understand that this is much faster than
typical for us to look at something. As you can see, there are nearly 200
issues open. :-)

---

Reply to this email directly or view it on GitHub:
#758 (comment)

[pjrobertson]

Fixed in latest HEAD and ß67 when released

[daniels220]

Nice, thank you.

On Fri, Mar 30, 2012 at 4:12 AM, Patrick Robertson <
reply@reply.github.com

wrote:

Fixed in latest HEAD and 67 when released

---

Reply to this email directly or view it on GitHub:
#758 (comment)