Saimadhav Heblikar
2014-06-13 14:41:29 UTC
Hi,
I would like the keyseq validator to be reviewed.
The diff file: https://gist.github.com/sahutd/0a471db8138383fd73b2#file-test-keyseq-diff
A sample test runner file:
https://gist.github.com/sahutd/0a471db8138383fd73b2#file-test-keyseq-runner-py
In its current form, it supports/has
modifiers = ['Shift', 'Control', 'Alt', 'Meta']
alpha_uppercase = ['A']
alpha_lowercase = ['a']
direction = ['Up',]
direction_key = ['Key-Up']
It supports validating combinations upto 4 in length.
Please test for the above set only. (It will extended easily to fully
represent the respective complete sets. The reason it cant be done
*now* is the due to how RE optionals are coded differently in my
patch. See CLEANUP below). I will also add remaining keys like
Backspace, Slash etc tomorrow.
# Cleanup:
If we decide to go ahead with RE validating keys as in the above patch,
0. I made the mistake of not coding RE optionals -> ((pat)|(pat)) same
for all sets. The result is that, extending the current key set is not
possible without making all RE optional patterns similar.(Read the
starting lines of is_valid_keyseq method).
1. There is a lot of places where refactoring can be done and
appropriate comment added.
2. I left the asserts as-is. They can be used in testing the validator
method itself.
3. The above patch still needs support for Backspace, slash etc to be
added. I decided to add, once I am sure we will use it.
4. I would like to know how it will affect Mac? What are system
specific differences? Please run the test-runner script on it and do
let me know.
---
My friend told that this thing can be done by "defining a grammar and
automata." I did read up about it, but found it hard to grasp
everything. Can you say whether it would be easier to solve it that
way than RE?
Regards
all 800+ obviously, but around 15-20 general ones.). The only
advantage is it can be used without creating a new Tk instance.
(i.eControl-Shift-Alt-Meta+Key-X is not covered. But
Control-Shift-Alt-Key-X is.)
--
Regards
Saimadhav Heblikar
I would like the keyseq validator to be reviewed.
The diff file: https://gist.github.com/sahutd/0a471db8138383fd73b2#file-test-keyseq-diff
A sample test runner file:
https://gist.github.com/sahutd/0a471db8138383fd73b2#file-test-keyseq-runner-py
In its current form, it supports/has
modifiers = ['Shift', 'Control', 'Alt', 'Meta']
alpha_uppercase = ['A']
alpha_lowercase = ['a']
direction = ['Up',]
direction_key = ['Key-Up']
It supports validating combinations upto 4 in length.
Please test for the above set only. (It will extended easily to fully
represent the respective complete sets. The reason it cant be done
*now* is the due to how RE optionals are coded differently in my
patch. See CLEANUP below). I will also add remaining keys like
Backspace, Slash etc tomorrow.
# Cleanup:
If we decide to go ahead with RE validating keys as in the above patch,
0. I made the mistake of not coding RE optionals -> ((pat)|(pat)) same
for all sets. The result is that, extending the current key set is not
possible without making all RE optional patterns similar.(Read the
starting lines of is_valid_keyseq method).
1. There is a lot of places where refactoring can be done and
appropriate comment added.
2. I left the asserts as-is. They can be used in testing the validator
method itself.
3. The above patch still needs support for Backspace, slash etc to be
added. I decided to add, once I am sure we will use it.
4. I would like to know how it will affect Mac? What are system
specific differences? Please run the test-runner script on it and do
let me know.
---
My friend told that this thing can be done by "defining a grammar and
automata." I did read up about it, but found it hard to grasp
everything. Can you say whether it would be easier to solve it that
way than RE?
Regards
On Fri, Jun 13, 2014 at 2:22 PM, Saimadhav Heblikar
Regex. It is not something elegant. The permutations are coded in.(NotJust a heads up to both: I am writing a keyseq validator method.
It currently works for over 800 permutations of ['Shift', 'Control',
'Alt', 'Meta', 'Key-a', 'Key-A', 'Up', 'Key-Up', 'a', 'A']. It works
for permutations of length 2 and 3. Beyond that its not worth it IMO.
I am currently trying to integrate it with test_configuration.py and
catching permutations i missed out.
I post this, so that we dont duplicate work. I hope it to be ready by
the end of the day.(UTC +5.5)
What is the method you are using?It currently works for over 800 permutations of ['Shift', 'Control',
'Alt', 'Meta', 'Key-a', 'Key-A', 'Up', 'Key-Up', 'a', 'A']. It works
for permutations of length 2 and 3. Beyond that its not worth it IMO.
I am currently trying to integrate it with test_configuration.py and
catching permutations i missed out.
I post this, so that we dont duplicate work. I hope it to be ready by
the end of the day.(UTC +5.5)
all 800+ obviously, but around 15-20 general ones.). The only
advantage is it can be used without creating a new Tk instance.
What do you mean by "permutations"? If you mean what I think, then I'm
not sure I agree with >3 not being worth it. I've used keyboard
bindings with more than 2 modifiers before, and we should certainly
support this properly.
I am sorry. I meant to write >3 modifier permutations.not sure I agree with >3 not being worth it. I've used keyboard
bindings with more than 2 modifiers before, and we should certainly
support this properly.
(i.eControl-Shift-Alt-Meta+Key-X is not covered. But
Control-Shift-Alt-Key-X is.)
--
Regards
Saimadhav Heblikar
--
Regards
Saimadhav Heblikar
Regards
Saimadhav Heblikar