[Idle-dev] KeyConfig, KeyBinding and other related issues.
tjreedy at udel.edu
Thu Jun 12 21:10:37 CEST 2014
On 6/12/2014 7:35 AM, Saimadhav Heblikar wrote:
> On 12 June 2014 02:50, Terry Reedy <tjreedy at udel.edu> wrote:
>> ConfigHandler.IdleConf.GetCurrentKeySet adjusts definitions on 'Darwin' by changing 'Alt' to 'Option'. On Windows and Linux, instead of replacing, uppercased key definitions could be added, as appropriate.
> I tried that in http://bugs.python.org/issue12387#msg220338. Let me
> know if that is OK. IIUC, next step would be to revert the changes
> made in Windows key set
We should make the 'officially approved' versions be the ones produced
by the basic mode of the key dialog: Control/Alt/Meta-Key-alpha and
Control/Alt/Meta-Shift-Key-Alpha. (Or we should change what basic mode
produces.) Not needing the alternate binding versions will eliminate the
need to use advanced mode to produce alternate binding versions.
There should be a new patch removing *all* the extraneous definitions,
not just the new ones. Write a program to remove
Control/Alt/Meta-Key-Alpha and ()-Shift-Key-alpha. (You could do the few
latter forms by hand if you prefer).
> AFA tests are concerned to validate the key defs in config-keys.def, I
> have started writing something as below:
> Tokenize the key sequence by splitting on '-'(as in Control-Key-r).
> and do the following:
> 1. ascertain the tokens follow correct order
> I will try various combinations in the existing key def and make a
> note of those orderings, which raise an error. Then ensure those
> orderings should fail during testing
> 2. In alphabet keybindings(Prefix-Key-x),(x is any alphabet) is it
> necessary that x be the lower case? If yes, this is something which
> can be tested.
I think accepting the 'wrong' versions (such as the ones we remove from
the Windows defs) either as an alternative or as supplement to the wrong
versions, depends on the place encountered. We need to list all and
decide for each.
0. Key dialog, basic mode - only produces official versions, I believe.
1. Key dialog, advanced mode - either reject or convert to official
version, if not present, as part of added validation. A message box
could give the user a choice.
2. Runtime: I would be inclined to accept without comment (message box).
However, I do not know how 3rd party extensions get 'installed'.
3. test_configuration, on default files, should fail on wrong versions.
The assert should have a message argument that would be useful to users
that mis-edit the default files.
4. test_configuration: we could consider looking for and testing user
Either configHandler or keybindingDialog should gain a key-binding test
function that can be imported and used in other modules.
> 3. Test simple scenarios like incomplete keybinding like missing '>' at the end.
> The above tests will go into test_keys in
> We can also run the above 3 tests on extension keybindings in
More information about the IDLE-dev