improved function searching in qgsexpressionbuilder #46672
Conversation
roya0045
force-pushed
the
expression_search_helptext
branch
from
0987bf1
to
efd3654
Compare
roya0045
changed the title
|
This can result in spammy results. I think it would be better to properly apply tags to all functions. Only |
I don't think both approach are exclusive. The difference is that I don't want to write tags for functions. The results could be ranked of the filtering could be tweaked with level of relevancy (1: exact name, 2: name & tags, 3: everything) The used helptext could also be filtered and rendered as a list to speed up search and remove words that are too common to skin down the results. But in the meantime I think that more reasults lead to discoverability or functions. But I'll let the others decide and worst case I'll only use it in my custom builds when I create the new one. |
|
I share @uclaros concern here -- tags would be a better approach to avoid the search results becoming flooded with unhelpful results |
I could add something to the UI to toggle it. Otherwise as it stands the only way is to read them one by one or find them through stackexchange. |
|
@uclaros @nyalldawson Another option would be to toggle the extended search when enter is pressed and only return name and tags filter on a 'shallow' search, as this is the case with some search options. A popup box could appear and simply state 'press enter for more results' or something similar, it's doable and there's plenty of space at the top (see https://doc.qt.io/archives/qt-4.8/qt-network-googlesuggest-example.html , but without the autosearch/list) |
|
@uclaros @nyalldawson would you be ok with an extended search when pressing enter? That's a common approach and I still think this approach is validate, especially until the tags are fully implemented (who knows when that will be) and possibly after. I also think others from the community would appreciate it, hence why I'm reluctant to closing it as there can be a good middle-ground. |
No, I'm still -1. That's not a standard QGIS UI paradigm and I don't think it solves the underlying issue. I'd suggest using the effort instead to make a script to auto-add ALL words from the json help as tags, excluding common words like the/and/etc. Then we could refine the tags from there... |
I've thought of that, but it's a fine line, that can end up providing the same level of spammy-ness than with this approach. That still leaves the question of synonyms that would be good to have in tags, but making a python script to edit the json is doable. Just not bespoke tags. |
use helptext
Co-authored-by: Harrissou Sant-anna <delazj@gmail.com>
roya0045
force-pushed
the
expression_search_helptext
branch
from
e18886d
to
518ad52
Compare
|
@nyalldawson Proposal tag branch should be up tomorrow, still need to do some minor improvement on the tagger. |
|
Just pick your favorite functions and add some useful tags! Then we can open a feature request with a "good first issue" tag. |
|
@uclaros I fail to see how doing things that way would have any meaningful impact on the user experience. |
|
Closing to see if the tag pr will be merged. |
Thanks to the work by @3nids I expanded upon it in order to also part the helptext, I was also thinking about adding synonyms/aliases but that could be done py improving the helptext.
Description
The helptext are included in the items as a new attribute/column/key.
The filter is split by space and validation is done on each element of the filter. This allows to use multiple partial strings and disregard the order, and still yield good results.
Increasing the number of possible results is a good thing instead of having to guess the proper name of a function and think of the right synonim.
Makes the following possible :
