Feature Request - Automatic %% in filters

[tonypdmtr]

I would like an option for Filter to automatically enclose whatever typed text in %% so as to not to have to type the % all the time. This is because I have found that practically always I need a “%text%” type search instead of just “text”.

[justinclift]

I'm kind of unsure about this. While that makes sense as a good default, what's a good approach for when someone needs there to be no '%' on the start or end?

A way to accomplish this isn't springing to mind at the moment. 😦

[tonypdmtr]

That's why I thought of it as a settable option (View/Preferences)

Better yet, a checkbox right next to the filters row where one can immediately change the default, and also verify its current state.

[zwrmueller]

Hi,

another problematic point here is the immediate activation of the filter while still typing. With big data it took relevant time to complete the intendet filter phrase, and the program does filtering again and again with every of the next typed in characters.

Alternative solutions might be:

1. drop this auto activation behaviour (not that conveniant)
2. make it optional by Setting (a bit better)
3. define a certain amount of time to wait that no further Input is done in the filter field and only then start filter Action (my best bet, i.e. 400ms might be a good starting point)

Regards
Ralf

[tonypdmtr]

This seems unrelated to this proposal as the only difference is that the LIKE argument will be automatically embraced by % characters. None of the remaining functionality is affected.

As for appropriate solutions to the other issue, I'd go with 3.

[MKleusberg]

@tonypdmtr @justinclift I've just pushed a commit which adds the %% wildcards in filter queries. So this changes the default behaviour of our filters. Because I wanted to avoid yet another option in the preferences dialog or even the main window I've come up with the following solution to work around the problem mentioned by Justin: by default I add the %% wildcards making the filter use more obvious. If you add your own % wildcards somewhere in the query I'll assume though that you know what you're doing and don't want us to mess up your query; so in this case we won't add any extra %% wildcards.

I hope this solution satifies everybody while keeping the UI simple and intuitive. What do you think?

@zwrmueller I've also implemented option 3 of your suggestion. I've set it to a timeout of 300ms but you can also hit Enter/Return or Tab for an immediate effect.

Both changes will be available in the next nightly build.

We'd also need to update our Wiki page on the filters. Any volunteers? @glawrence maybe? 😃 But no worries if you don't have the time. Just wanted to drop this as a To Do somewhere.

[justinclift]

Cool, good stuff @MKleusberg. 😄

[tonypdmtr]

I appreciate all the work put into this, and the result is very good.

However, there is one issue with this always-on use of % that may be a problem. It fails to handle the case where a string is also found as a sub-string of another string. For example, the names: John and Johnson

If I'm looking for John, typing John will give me both and there may be cases where I only need to see just John without Johnson. And, there is no way to make it not find Johnson.

I think some kind of on/off switch for this option is needed.

(BTW, one minor note about the implementation. I looked at the code and when the string is empty it is replaced by '%%' when just one '%' is sufficient. Not important in that it does not change the behavior.)

[MKleusberg]

@tonypdmtr You can still type "=John". It's case-sensitive then but at least doesn't require an additional option. The reason I'm hesitating to add an extra option here is that the filters are meant to be a quick and easy search method which should "just work" for most people without having to think about it. We've implemented quite a complex rule system by now to achieve this (which still might be irritating sometimes) but adding an option would basically double the number of combinations.

As for the double '%%' thing: I think this shouldn't matter because either way '%' or '%%' the column is removed from the list of active filters by the statement a couple of lines further down. So as far as I see (though it's late alrady 😉 ) it should never reach SQLite or the user.

[tonypdmtr]

I didn't know about the = option. That will work just as well. Thanks.

[MKleusberg]

Are we ok to close the issue then? 😄

[tonypdmtr]

It's OK as far as I'm concerned!

[MKleusberg]

Cool, closing this then 😄