Skip to content

"Wait before searching" option causes unexpected behaviour #2733

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pjrobertson opened this issue Apr 13, 2022 · 5 comments
Closed

"Wait before searching" option causes unexpected behaviour #2733

pjrobertson opened this issue Apr 13, 2022 · 5 comments

Comments

@pjrobertson
Copy link
Member

pjrobertson commented Apr 13, 2022

Bug description

If I set "wait before searching" to a value > 0 (e.g. 0.02s), it can cause strange behaviour when searching, and out of step events.

Steps to reproduce

  1. Set 'wait before searching' to a high number, e.g. 0.06s (I first came across this bug with a value of 0.02s)
  2. Open quicksilver, and type "X ... Y ... / " really quickly to simulate searching for two letters then arrowing into it. In my case, I search for 's... m...'
  3. Note how the result window 'nudges' at the wrong time - before the search has actually been performed.

This video shows the situation, albeit not that well and it's not 100% reproducable:

Untitled.mov

In the first case, when 'wait before searching' is set to 0.06s, then the arrow into happens before any character has been searched for (i.e. when the first pane is empty). In the 2nd case when 'wait before searching' is set to 0.02s the first item that displays when searching for 's' in my case is 'Shadowsocks' - which fails.

Note that sometimes the correct behaviour does happen sometimes in the above video. When you see a PDF who's name starts with '[Tested]' - that's the correct behaviour.

Expected behavior

Key presses are processed in the correct order.

MacOS Version

macOS 10.14

Quicksilver Version

2.0.3

Relevant Plugins

--

Crash Logs or Spindump

No response

Screenshots

No response

Additional info

There are two solutions to fix this:

  1. We remove the 'wait before searching' option all together.
  2. We actually fix the bug so that processing is done in the right order.

I propose we go with no.1. What's the reason for wanting to delay the search in this day and age? I'd say I'm probably on one of the oldest Macs (10.14) that we still support in QS, and I have no speed issues, so...

@skurfer
Copy link
Member

skurfer commented May 1, 2022

I apparently have had this set to 0.08s for years because I don’t remember the last time I touched it. (I never notice the delay, FWIW. The result is ready faster than I can move my finger over to the Return key.)

I also have results shown manually, so I would never see this normally, but enabling the results window, I guess I can kind of see what you mean, but it happens so fast, it’s hard to say the order is wrong. Maybe I’m not reproducing it correctly.

@pjrobertson
Copy link
Member Author

I think it might be more reproducible for me as I'm on a 10 year old Mac which is a bit slower

@skurfer - can you try changing the time to 0.0s and seeing if that's acceptable? If so, then I'll go ahead and implement this change to remove the option. The fact that you said "I apparently have had this set..." makes me feel like it's not a setting you used/thought was useful - so that makes me further lean towards removing it.

@n8henrie
Copy link
Member

n8henrie commented May 3, 2022

Mine has been set to 0.05s. Just turned it to 0, but I don't see why it would be a problem to remove.

@skurfer
Copy link
Member

skurfer commented May 10, 2022

@skurfer - can you try changing the time to 0.0s and seeing if that's acceptable?

I’ve turned it to 0.00s. I’ll run that way for a while, but I wouldn’t expect to see any problems on an M1 Max.

@pjrobertson
Copy link
Member Author

If all looks good for the two of you, I'll remove this option all together and push :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants