search

TBog / TBLauncher

based on https://github.com/Neamar/KISS
GNU General Public License v3.0
140 stars 18 forks source link

On Enter, wait for filter to complete, then start first app #402

Closed ltguillaume closed 7 months ago

ltguillaume commented 1 year ago

Description

Whenever I want to start an app, I type in 2 letters and press Enter on the keyboard. I know beforehand which app is the first (well, visually the last) in the result list and as such should be started when pressing Enter.

However, I find that if the list reorganizing is still busy (I'm not sure of the reason, perhaps because of the animation, perhaps because of the filtering process itself) when I press Enter, another app starts.

As an alternative explanation, it might also be that the filter misses out on the first letter I type, immediately after the keyboard shows, but I think that's less likely.

Steps to Reproduce

To reproduce the behavior:

  1. Optionally turn on Battery Saver to slow down the device a bit
  2. Go to Search
  3. Type in a few letters and press Enter quickly after
  4. See another app started, instead of the app that should be started according to the result list

Expected behavior

The first result (visually last in the list) should be started consistently.

Device info

OS: Android 11 TinyBit Launcher version: 7.4 (and I believe 7.3 as well)

TBog commented 1 year ago

If the animation started the list has already changed so pressing enter will start according to the new list. I think a better fix would be to let the user disable the animation. Do you agree?

ltguillaume commented 1 year ago

No? I don't think animations should in any way influence how the query works, which in turn means that that they shouldn't have to be disabled to have a reliably working filter process.

TBog commented 1 year ago

I'm not sure how you expect me to fix this? At what point during the animation do you expect to switch from the previous result list to the new one?

ltguillaume commented 1 year ago

I don't really care about the animation in this case. The thing that's bugging me isn't the animation at all: I just think that the action "pressing Enter" should reliably use the result list based on all the letters typed before pressing Enter, no matter in what phase the animation might be.

If the animation is somehow intertwined with the filter process, so that it can't reliably offer the same result every time when pressing Enter, then - while I would say this is a design mistake - I'd rather see the animation get the time to finish before the Enter press is processed.

TBog commented 1 year ago

I have misunderstood. What you expect is to wait for the search to finish before launching the result.

ltguillaume commented 1 year ago

Exactly.

So, imagine I type ab [Enter] really fast (and I have a slow device and/or Battery Saver is turned on).

The result is somehow that TBLauncher doesn't open the first entry from the result list for ab, but instead the first entry from the result list for a.

This looks like the somehow [Enter] is processerd before b, or at least before the query for b has finished.

TBog commented 1 year ago

I'm not sure if I can leave the fix as is. I'm thinking of adding a check to see if the time between the [Enter] and the launch is too long.

ltguillaume commented 1 year ago

I'm not sure if I can leave the fix as is. I'm thinking of adding a check to see if the time between the [Enter] and the launch is too long.

The time between [Enter] and the launch is not relevant to this problem. During this time, the search results shouldn't have changed, and if they were (e.g. ab [Enter] c), then the newer search result should not matter for what app is launched.

My thoughts would be, simply put:

Key pressed: a =>

  1. currentResultsQuery = false
  2. Do the search
  3. currentResultsQuery = "a"

Key pressed: b =>

  1. currentResultsQuery = false
  2. Do the search
  3. currentResultsQuery = "ab"

Key pressed: [Enter] =>

  1. launchFirstQuery = currentSearchFieldValue
  2. If (launchFirstQuery = currentResultsQuery) return launch(resultsList[0])
  3. Else
  4. currentResultsQuery = false
  5. search(launchFirstQuery)
  6. currentResultsQuery = launchFirstQuery
  7. If (currentResultsQuery = launchFirstQuery) launch(resultsList[0])
TBog commented 1 year ago

ab [Enter] c This should not happen or else the app that's launching would be unexpected. You should not be able to add search parameters after pressing Enter.

The current implementation will cancel the ab search without getting the results (even if you've pressed Enter) and start a new search for abc This is because searching is a CPU and memory intensive operation and you don't want to do it if you don't intend to use the results

ltguillaume commented 1 year ago

ab [Enter] c This should not happen or else the app that's launching would be unexpected. You should not be able to add search parameters after pressing Enter.

Yeah, I assumed this shouldn't happen, which is why my pseudocode didn't account for it either, but I only brought it up because you said there could be something going on in

the time between the [Enter] and the launch

I guess I still don't understand what could happen in that time frame then, and why you'd need to check this.

The current implementation will cancel the ab search without getting the results (even if you've pressed Enter) and start a new search for abc This is because searching is a CPU and memory intensive operation and you don't want to do it if you don't intend to use the results

That makes sense, of course, but I think the issue at hand can only occur in the following situations:

  1. Somehow the search for the incomplete string isn't canceled and gets used when pressing [Enter]
  2. The first letter of the query isn't registered, so instead of ab, the search is only for b.
TBog commented 1 year ago

the time between the [Enter] and the launch

I guess I still don't understand what could happen in that time frame then, and why you'd need to check this.

I was talking about the wait I added. Let's say you search for ab and then press [Enter] but because the phone is slow it takes a second. In the mean time you get impatient and put the phone on the table. When the search finishes the app (video/music app) opens and loud music fills the room.

ltguillaume commented 1 year ago

I think in that unlikely scenario, the only reason the app maybe shouldn't start is if the user turned off the screen. And actually I would still want it to. In the specific situation you're describing I would most definitely still expect the app to be launched. In summary, I wouldn't complicate the code with any timeout for that.