Make the SearchBar a proper standalone, configurable widget #28

New Issue

2023-04-13T04:38:29+01:00

SuzanneSoy commented

2023-04-13 04:38:29 +01:00

(Migrated from github.com)

One should be able to create a SearchBar anywhere with one line of code, e.g. to place it floating under the cursor, to put it in the toolbar, it in the Preferences Editor (Edit→Preferences…), in the toolbar customization(Tools→Customize…), in the Parameter editor (Tools→Edit parameters…), in the Tree view (to search for objects or their properties in open files/open multi-file projects), in a nodal editor, in the Python editor (searching for known Python method names)…
One should be able to configure which kinds of results are included, e.g. only tools, only preferences, only objects… The global search bar would likely search in nearly everything.
There should be hooks to invoke callbacks when a result is highlighted (e.g. when moving the cursor on a different result in the Preferences editor, it could switch instantly to the tab containing that preference)
There should be hooks to decide on the placement / presence of the search results and info box
One should be able to configure which kinds of prefixes (https://github.com/SuzanneSoy/SearchBar/issues/26) are supported?

Points 1 & 2 require decoupling the creation of result providers from the creation of the search box. We want to create only one instance of ResultsToolbar.py, and let some search bars query it for results or not. This requires the dialog https://github.com/SuzanneSoy/SearchBar/issues/27 for refreshing the cache, otherwise each search box will have some sort of partial "cache refresh" command that only covers some result providers, or will refresh things that the user has no idea it's going to refresh.
Points 3 & 4 require adding these hooks, when creating a new SearchBar one can pass these hooks as parameters.
Point 5 requires properly decoupling the prefixes (https://github.com/SuzanneSoy/SearchBar/issues/26) from the result providers.

Luckily, the code is already pretty modular in these ways, this isn't a big refactor, it's just renaming a few things and extracting a few lines of code here and there to separate functions.

1. One should be able to create a SearchBar anywhere with one line of code, e.g. to place it floating under the cursor, to put it in the toolbar, it in the Preferences Editor (Edit→Preferences…), in the toolbar customization(Tools→Customize…), in the Parameter editor (Tools→Edit parameters…), in the Tree view (to search for objects or their properties in open files/open multi-file projects), in a nodal editor, in the Python editor (searching for known Python method names)… 2. One should be able to configure which kinds of results are included, e.g. only tools, only preferences, only objects… The global search bar would likely search in nearly everything. 3. There should be hooks to invoke callbacks when a result is highlighted (e.g. when moving the cursor on a different result in the Preferences editor, it could switch instantly to the tab containing that preference) 4. There should be hooks to decide on the placement / presence of the search results and info box 5. One should be able to configure which kinds of prefixes (https://github.com/SuzanneSoy/SearchBar/issues/26) are supported? - [ ] Points 1 & 2 require decoupling the creation of result providers from the creation of the search box. We want to create only one instance of `ResultsToolbar.py`, and let some search bars query it for results or not. This requires the dialog https://github.com/SuzanneSoy/SearchBar/issues/27 for refreshing the cache, otherwise each search box will have some sort of partial "cache refresh" command that only covers some result providers, or will refresh things that the user has no idea it's going to refresh. - [ ] Points 3 & 4 require adding these hooks, when creating a new SearchBar one can pass these hooks as parameters. - [ ] Point 5 requires properly decoupling the prefixes (https://github.com/SuzanneSoy/SearchBar/issues/26) from the result providers. Luckily, the code is already pretty modular in these ways, this isn't a big refactor, it's just renaming a few things and extracting a few lines of code here and there to separate functions.

Sign in to join this conversation.