New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Input Gestures dialog: provide an edit field to search for commands by command descriptions #4458
Comments
Comment 1 by blindbhavya on 2014-09-14 14:57 |
Comment 4 by vgjh2005 on 2014-09-16 01:53 |
Comment 6 by zahari_bgr on 2014-10-31 18:45 You can find this on my bitbucket repository under t4458 branch: |
Comment 7 by nvdakor on 2014-10-31 19:29
|
Comment 8 by jteh (in reply to comment 6) on 2014-11-01 02:08 Replying to zahari_bgr:
Why a regular expression? At least for the Elements List, it's a simple text filter, so you can just .lower() both strings and use the "in" operator. |
Comment 9 by zahari_bgr (in reply to comment 7) on 2014-11-01 19:06 Replying to jteh:
I've used regular expression, cause it allows me to do a more complex search, i.e. I split the filter by words and then construct a regular expression using positive lookaheads for every word, which allows searching for the given keywords at any position and in any order. Replying to nvdakor:
I was led by the expression that in most of the programs (or websites) which provide some kind of search, the input field is above the content (or search results), so I didn't think when I placed it before the treeview - it looked natural to me; like you've said - type some words and press tab smile.
Yeah, we could probably read the first command programmatically. But which items we should expand and when? And should we collapse them afterwords? Thanks, |
Comment 10 by nvdakor on 2014-11-01 19:11 |
Comment 11 by jteh (in reply to comment 9) on 2014-11-03 07:15 Replying to zahari_bgr:
Very interesting and potentially quite useful. Makes sense. Please add a comment to this effect above the regexp.
It's true that it's inconsistent with the Elements List, but I agree with your reasoning. The Elements List is a bit trickier because there are other controls before the tree as well that are arguably more important than the filter box.
While I do understand your argument, I think the initial focus should still stay on the tree view. As you note above, having to shift+tab to the field is a common pattern these days.
I don't think we should read or move to any specific items by default, as there's no "best match" here. Perhaps all of the categories could be expanded whenever we filter, since the user wants to see filtered items.
When the filter is cleared, they should be collapsed.
I don't think so. A few other points:
Thanks! |
Comment 12 by zahari_bgr on 2014-11-05 00:52 |
Comment 13 by jteh on 2014-11-05 11:52 I forgot to ask you about this in the first code review; sorry. :( It's probably better to not compile/match against the regexp at all if there's no filter. You could just set it to None and don't try to match if it's None. Is there any reason you expand/collapse the items (in onFilterChange) after adding them all? I imagine you could just expand the category tree items when adding them in populateTree if there is a filter. If there isn't a filter, you don't need to do anything, since I think new items will be collapsed by default. In _addChoice, I just realised (at least, I'm pretty sure) that scriptInfo is actually exactly what you need, so you can just append to scriptInfo.gestures without having to get the parent tree item, etc. Same for onRemove. This needs testing, but if I'm right, sorry for the confusion. :) |
Attachment t4458.diff added by zahari_bgr on 2014-11-05 17:30 |
Comment 14 by zahari_bgr (in reply to comment 13) on 2014-11-05 17:48
I wanted to avoid too many checks, but you're right - no need to compile the regexp in this case.
At first I wanted to use ExpandAllChildren() and CollapseAllChildren() without realizing that ExpandAllChildren() will expand all ansesters , and after that I was misled by that. Now I changed it the way you suggest.
Yeah, you are right - it works exactly the same - I've changed it now. |
Comment 15 by James Teh <jamie@... on 2014-11-06 03:40
|
Comment 16 by jteh on 2014-11-06 03:41 |
Comment 17 by James Teh <jamie@... on 2014-11-06 04:46
Changes:
|
Comment 18 by blindbhavya on 2014-11-06 05:42 |
Comment 19 by jteh on 2014-11-06 06:02 Here are two alternatives. Let me know which is easier for you to follow.
|
Comment 20 by nvdakor on 2014-11-06 10:52
The problem line says evt.GetClientObject().GetValue() which returns None (the client object is None). Changing this to evt.GetEventObject().getValue() resolves this problem. Thanks. |
Comment 21 by zahari_bgr on 2014-11-06 13:14 |
Comment 22 by beqa on 2014-11-06 14:32 i am getting this error when trying to write something in filter by editbox ERROR - unhandled exception (18:30:19): |
Comment 23 by zahari_bgr on 2014-11-06 14:48 |
Comment 24 by nvdakor on 2014-11-06 19:21 |
Comment 25 by jteh (in reply to comment 21) on 2014-11-07 02:49
You probably didn't update submodules, so you were running wxPython 2 still. The problem occurs with wxPython 3.
According to the wx documentation, GetClientObject is only relevant for ListBox/Choice selection events. It seems this is another case of something that used to work in wx 2 but was actually incorrect according to the docs. We've been bitten by a few of those. :) Btw, while I think of it, for future reference, don't worry about attaching a patch to the ticket if you have a public branch, as we'll just look at the branch. |
Comment 26 by James Teh <jamie@... on 2014-11-07 02:54
|
Comment 27 by blindbhavya (in reply to comment 19) on 2014-11-07 15:02
GO for option 2. |
Comment 28 by James Teh <jamie@... on 2014-12-03 04:44
Changes:
|
Comment 29 by jteh on 2014-12-03 04:47 |
Comment 30 by bhavyashah on 2014-12-03 11:20 |
Comment 31 by bhavyashah on 2014-12-03 11:21 |
Comment 32 by jteh (in reply to comment 30) on 2014-12-03 23:29
Yeah, wrong commit message, but the entry in the What's New is correct, which is what users will read. |
Comment 33 by bhavyashah on 2014-12-04 16:54 |
Comment 34 by leonarddr on 2015-02-16 19:56
|
Comment 35 by jteh on 2015-02-18 03:51 |
…pecific words using the new "Filter by" field. Fixes #4458.
Reported by nvdakor on 2014-09-14 11:34
Hi,
Consider the following scenario: a user wishes to reassign the command for announcing the name of the executable and any app modules present for this executable (Control+NVDA+F1) but doesn't quite know what that command is actually called. As of NvDA 2014.3, the user would use the input gestures treeview to locate the command, but with various categories, the user may not know which one to expand. To help this user locate the command quickly, an edit field which filters commands based on keywords would be useful.
This new edit box will allow users new to NVDA to quickly locate commands for reassignment. This would also allow users to assign commands to scripts which has no gestures attached or add a touch or braille command for scripts assigned to keyboard commands.
The implementation of this feature would closely mirror that of elements list dialog in browse mode, in that this new filter or command search field would filter commands based on keywords entered by the user. Thus, after typing some phrases, the user would press tab to go to search results list, which would populate the area occupied by input gestures treeview, similar to what happens in elements list dialog.
Thanks.
The text was updated successfully, but these errors were encountered: