OmarEmaraDev added a comment. @clayborg I see a number of issues with using forms directly:
- The user will have to bother with form navigation. If we have a text field and a choice field, the user will have to switch between them using Tab and Shift+Tab in order to explore, rectify, and select a match. This is significantly more work then just typing without worry, selecting using arrow keys, and executing using enter. - Not all users will use the OPT+Enter keys, it is likely that once the user sees a button that says "Select", the user will try to navigate to that button ignoring the tip in the windows border. Which is more work than just pressing enter. - Updating the choices will require that we materialize all choices into text, this can work for the common completion searcher, but other searchers will require actual processing that might slow down the update process. The searcher window only materialize the match that it draws, so it can draw things much faster. We could update the choices field to accept a callback to compute its contents, but this will complicate the code, so it is worth considering if this is really needed. - Practically all search dialogs work in a manner similar to the searcher window, like browser search bar, editor search dialogs, and the like. I don't recall seeing a search dialog that is implemented as a form. - We want the ability to do custom styling. One thing I was considering is coloring the matched substring a different color, if we use a choice field, then we give up on custom styling. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108545/new/ https://reviews.llvm.org/D108545 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
