Allow searching in multiple, selected tables (inclusion and exclusion).

[beedell-roke]

Use cases

Like in most desktop file managers, consider checkboxes prepended to list entries, with an "all" entry above them:

1. Sometimes, which table a known key is stored within isn't known, meaning that the user must choose each table and attempt the query individually. This isn't feasible with the amount of tables individually exposed:

   

   I'd consequently like to be able to select the tables to search across, to include them.

2. Additionally, sometimes I want to search solely within a few specific tables to ensure that a key or value is within them. To accomplish this, I would like to be able to exclude certain tables.

[MuntashirAkon]

I've thought about it too. But the way the feature was implemented, it's not possible to implement such a functionality in a simple way. It's probably possible to merged the first three tables into one in order to make it easier to search across the settings.

[gstjee]

It's probably possible to merged the first three tables into one....

I think other best option would atleast keep searched keyword in search box and then user can switch between tables to see anything found. currently it resets search bar when we switch between tables which extremely annoying when searched string is long.
I feel this is only thing which is missing except that app is perfect.

[beedell-roke]

#37 (comment)

@gstjee, that would be useful too, but when searching for multiple keywords, I would like what I've proposed too.

[gstjee]

yeah, if it is feasible for developer then first method is more usefull with little more enhancements like:
resulted tables: should be displayed with their table name and also individual tables should be separated from one another in view window.
Edit: because sometime power user just not only want to edit the value but also wants to know in which table that key pair exists for various his other use cases.

[beedell-roke]

#37 (comment)

@gstjee, there is use for what you've proposed, though - being able to dynamically include tables necessarily necessitates that the user be able to exclude tables too. This would be useful when ascertaining whether a key or value exists in multiple tables. I'll try to re-scope the issue to include your proposal.

because sometime power user just not only want to edit the value but also wants to know in which table that key pair exists for various his other use cases.

Were the search to result in a tabled view, with a column for the database in which the key or value resides, this would be easily discernable.

[gstjee]

@RokeJulianLockhart i guess exclusion inclusion of tables in searched results could leads to complex code which i guess @MuntashirAkon won't wants that. may be i am wrong but he wants things in simple and less complex manner.

so i would suggest just keep it simple like:
after searching keyword then results should be displayed in below manner in view:

---

System Table:
rows if there is any

Secure Table:
rows if there is any

so on for all tables . if any table doesn't have searched key then don't show its heading as well.

---

[beedell-roke]

#37 (comment)

@gstjee, I've considered that. However, this would actually be less spaghettified - implementing the search in such a way that it's designed to include and exclude datasets would be the more consistent implementation, because searching across tables isn't implemented as an exception. Instead, it would merely be possibility of many, as a consequence of a more broadly robust method.

Otherwise, this functionality shall be subsequently proposed by someone, and then it'll be implemented as an edge case too, when we could have refactored it more comprehensively initially.

I'll leave the developer to assess what methods of implementation are feasible due to code debt and complexity, whilst we focus upon what's the best UX for the GUI.

[GfEW]

Alas, technically comprehensive tools often come in remarkably incomprehensive UIs that tend to assume a lot and provide poor UX and cumbersome workflows (let alone accessibility), whilst smooth, comprehensive UIs tend to come with patronizing technical limitations and give little insight - as if techies and users were distinct species (rather than gradually different distributions on the spectra of abilities and needs).
You rarely get the best of both worlds.

I think that @MuntashirAkon works hard to build that bridge, but the stronger parts here lie clearly on the technical side.

Search across all sections is the feature in SetEdit I've missed from day one. (Remembering the search term came second.)
For the time being, however long it may be, I've arrived at working around most of this particular limitation using termux:

adb shell 'for c in "settings list "{system,secure,global} "getprop" "printenv"; do eval "${c}" | sed -Ee "s/^/${c@Q}:/"; done' | less -S

This lists, and allows to search (via /), all settings at once, from

• System table
• Secure table
• Global table
• Android properties
• Linux environment (*)

If you do that frequently like me, you might want to make it an alias, e. g.

alias list_settings='adb shell '\''for c in "settings list "{system,secure,global} "getprop" "printenv"; do eval "${c}" | sed -Ee "s/^/${c@Q}:/"; done'\'' | less -S'

and add that line to your shell initialisation file (e. g. ~/.bashrc) to make list_settings readily available in any shell session started thereafter.

What's missing?

• java properties (supposedly require some jdk)
• boot items (how to retrieve them?)
• shortcuts (how to retrieve them?)

(*)

I don't understand why the respective section in SetEdit is labeled "Linux environments" (plural)j. If I'm not mistaken, there's only one linux environment (singular) that can be inspected in SetEdit or via printenv.