Remove T9 search text-entry option; default to multitap keypad entry#458
Remove T9 search text-entry option; default to multitap keypad entry#458brickbots wants to merge 1 commit into
Conversation
Name Search offered an optional `t9_search` mode (press each key once; match object names against keypad-digit sequences) alongside the default multitap entry (press a key repeatedly to cycle through its letters). This removes the option entirely, so name search always uses multitap entry plus substring text search. - Remove the `t9_search` config key and the "T9 Search" Settings menu item - Drop the t9_search_enabled branch in UITextEntry; always use search_by_text - Remove the now-unused Catalogs.search_by_t9 machinery (keypad digit maps, _t9_cache, helpers) and its dedicated test - Fix the User Pref submenu index shift in the web settings test (Language moves from index 6 to 5) - Update the user guide and ax/catalog/ui docs to drop T9 references Translation catalogs still contain an orphaned "T9 Search" entry; it will be removed by the next `nox -s babel` sync (run periodically, not per-PR). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
hi @brickbots , why did you remove the new entry method, was something broken with it? |
|
Hi @mrosseel thanks for spotting this PR! I don’t think I’m going to merge this, but I wanted to invite a conversation. This is actually a fairly common support question. Either people asking what it is, or enabling it thinking that it is the existing multi-tap method which they couldn’t find otherwise. I like this feature, but I feel like it really needs to be paired with a dynamic list of objects… more like the old smart phone system. As it is you just type numbers with little feedback and I’m not sure many people actually get it. So I’d like to figure out how to make this more understandable and useful. This might just be better documentation, but I’d like it to be more digestible without resorting to the user manual if possible. Thoughts (from anyone)? Is this something people are successfully using and preferring? I only get the negative side of things from the support emails, so I don’t want to over index and hide it or remove it. |
A dynamic list responding to each keypress is a critical part of T9 and provides the feedback needed to use the feature effectively. There was also a learning component to prioritize past choices; I'm not if that's a should or nice-to-have. if there was a T9 option but without an adjacent multitap option, that might explain the support questions. |
Summary
Name Search previously offered an optional T9 search mode (the
t9_searchsetting): press each number key once and object names are matched against their keypad-digit sequence. The default — and now the only — behavior is multitap keypad entry: press a key repeatedly to cycle through its letters (7→a/b/c…), building a text string that is matched with a plain case-insensitive substring search.This PR removes the T9 option entirely and makes multitap the sole text-entry mode.
Changes
t9_searchkey fromdefault_config.json.menu_structure.py.textentry.py): remove thet9_search_enabledproperty and its branches;_perform_searchalways callssearch_by_text, andkey_numberalways uses multitap.catalogs.py): remove the now-unusedsearch_by_t9machinery — keypad digit maps (KEYPAD_DIGIT_TO_CHARS,LETTER_TO_DIGIT_MAP), the_t9_cacheand its helpers, the cache-invalidation calls, and the now-unusedimport re.search_by_textis unchanged.test_t9_search.py; updatetest_web_remote_settings.pyfor the User Pref index shift (Language moves from index 6 → 5, so navigation uses one fewerD).user_guide.rstand thedocs/ax/{catalog,catalog/CONTEXT,ui}references; light wording fixes in the docs skill knowledge base.Notes
RELEASE.md(shipped v2.5.1 changelog, already tagged) is intentionally left unchanged — it's a historical record.locale/*/messages.po) still contain an orphanedT9 Searchentry. It's harmless (no longer referenced) and will be removed at the nextnox -s babelsync. A full babel run here would have churned ~2,600 lines of unrelated source-line references (the catalogs are refreshed periodically, not per-PR), so it was deliberately left out.Testing
pytest -m "smoke or unit"→ 281 passed.ruff checkclean on changed files;mypyreports no errors in the changed modules.🤖 Generated with Claude Code