[Idle-dev] RE: idlefork - keybinding config / idle extensions

[Hernan Martinez Foffani]

> De: Stephen M. Gava [mailto:elguavas@users.sourceforge.net]
> Really the points are these:
>
> 1. Moving from 'platform' oriented keybindings to user oriented
> ones.  I must
> admit that this one is slightly more than just a 'proposal', since I've
> already implemented things this way...   8^) , so, more properly
> consder this a 'news item'.

Glad to hear it! Great!

> 2. It's 'one in all in'.  It really isn't possible to satisfactorily
> implement user configurable key bindings for idle 'core', while
> leaving extension's key bindings hard-coded in their modules.
> This problem
> with extensions needs to be addressed in some way. Now. (see point 4 also)

Ah, ok! I just thought that you could use the hard-coded key bindings
as a) to find at runtime all the events the extension needs to be bound
to keys, b) as a 'fallthru default' and c) for a smooth transition of
older extension.
But these are all implementation issues for which, as I read in the 4.b
paragraph, you are studying several approaches.

> 3. SearchBindings.py is a special case since I'm firmly convinced
> that the functions it implements are core to idle, not peripheral or
> optional, and so I think it's keybindings sould be part of the idle
> core keybindings and therefore handled by the idle core keybinding
> configuration mechanism, not by whatever additional mechanism is
> put in place to handle keybindings for extensions.

Ok. So this is a refactoring thing. None of my business here :-)
But, please, do not end making all the standard extension a big ball.
At least leave one (CallTips, or any other) out so we can use it
as an extension sample. I know you will. Or should I say you won't?
Well, you know what I mean... :-P


> 4. The practicalities of handling user configuration of extension
> keybindings are these:
> a)  extension keybindings will need to be defined in one of idle's new
> configuration files (probably most properly in the relevant sections of
> config-extensions.def), _not_ inside the extension source modules.
> b)  whatever mechanism is implemented for allowing user configuration of
> extension keybindings (at the moment I have several different possible
> approaches in mind) it must allow this configuration to participate in
> the general abilty to handle and resolve potential clashes between
> keybindings that will be a part of the core keybinding config handling.
> (ie. obviously you can't use the same keybindings more than once, in
> any given keybinding set, for core keybindings, _or_ extensions).

You realized that there were several things to consider that I did't
think of. Fine for me!

> > As an IDLE user, for me is more useful to have
> > a way to specify keybindings in an non-OS manner but rather
> > in a scheme and user configurable way (that include standard
> > extensions and the ones written by me!), than to do it GUI.
>
> For sure the 'sensible implementation' is much more important
> than the gui (and of course can and should exist happily without
> it ), but the goal of the new config implementation is to also have
> easy gui configuration, to make idle a more comfortable environment
> for one and all, including those who would never edit config files
> by hand.

Hey! If you insist that I can take the lemon-pie with the Combo
all for free, you'll double my smile ! :-)

Well, sorry that you've got to clarify all this. I'll help you
with the future testings.

Thanks and regards,
-Hernan.