Skip to content
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

Filter improvements #18084

Closed
qgib opened this issue Feb 4, 2014 · 4 comments
Closed

Filter improvements #18084

qgib opened this issue Feb 4, 2014 · 4 comments

Comments

@qgib
Copy link
Contributor

qgib commented Feb 4, 2014

Author Name: Jonathan Moules (Jonathan Moules)
Original Redmine Issue: 9493

Redmine category:browser
Assignee: Etienne Tourigny


There are a number of simple improvements that I believe can be made to the Browser filter function to make it more useable:

a) By Default wildcards should be placed at the start and end of all search terms automatically. Maybe add this as a new "default" search called "Normal".

b) By Default make it case-insensitive. If necessary add a checkbox for "match case", but it should be unchecked by default.

The current behaviour for both of these is extremely non-obvious and I almost reported a bug saying that the filter wasn't working. Both of these are the default for most search functions in most applications I can think of, including ironically, the filters in the WFS and Oracle add-data dialogs.

@qgib
Copy link
Contributor Author

qgib commented Feb 4, 2014

Author Name: Etienne Tourigny (@etiennesky)


Hi,

when I implemented the filter functionality I did things as simple as possible, using QT's QRegexp [1] class with minimal work (basically passing the search string to QRegExp).

The "Wildcard" option uses QRegExp::Wildcard PatternSyntax (defined in [2]) and the "Regular Expression" option uses QRegExp::RegExp.
Also, when using the "Wildcard" option, you can use | to separate search strings.

Note that this was implemented with files in mind, which is where it is most useful (imagine a directory of 1000s of files).

Your suggestions are valid. The behavior is different from WFS and Oracle add-data dialogs simply because they were implemented by different people.
I come from the Linux world, and find it normal to specify wildcards in the beginning and end if need be.

What would your suggestion for "Normal" search? Should wildcards like * and ? be permitted inside the string? or just a simple string with wildcards at beginning and end?

Case-insensitive search should have an option, it would be ok to have it case-insensitive by default.

[1] http://qt-project.org/doc/qt-4.8/qregexp.html
[2] http://qt-project.org/doc/qt-4.8/qregexp.html#PatternSyntax-enum


  • assigned_to_id was configured as Etienne Tourigny

@qgib
Copy link
Contributor Author

qgib commented Feb 4, 2014

Author Name: Etienne Tourigny (@etiennesky)


see my implementation here with commit "browser dock: add normal syntax (with wildcards at begin and end) and case insensitive search, both default"

https://github.com/etiennesky/Quantum-GIS/tree/browser_search

If satisfactory I will add to master after 2.2 is out

@qgib
Copy link
Contributor Author

qgib commented Feb 5, 2014

Author Name: Jonathan Moules (Jonathan Moules)


Hi Etienne,
Don't get me wrong, the current implementation is good for power users, but most users aren't that technical (there's a reason Linux has a low % of the home-users market ;-) ), hence my suggestion.

I'd suggest the default behaviour should be the same as a web-browser search (when you Ctrl-F). I think no wildcards from the user, at least not in the default search. There are current two search functions (Wildcards, Regexp). I'd suggest a third "Normal" which is the default and has this specified behaviour. Then you don't need to change the other two (except probably the case insensitive checkbox).

I'm afraid I'm not a dev so can't look at a commit and have any clue what it'll do.

And thanks for the prompt response!

@qgib
Copy link
Contributor Author

qgib commented Feb 22, 2014

Author Name: Etienne Tourigny (@etiennesky)


Fixed in changeset "ececdb71aec28882c49eab4acd0fcdb31b8155ff".


  • status_id was changed from Open to Closed

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

No branches or pull requests

1 participant