On Wed, Apr 8, 2009 at 2:02 AM, Ville M. Vainio <[email protected]> wrote:

>
> I think it makes perfect sense to not parse bindings "partially", so
> that you see 0 instead of ). If tk does that, i would say it is broken
> instead.


Imo, when the ctrl key is not down, it would be quite wrong to report ) as
shift-0. Qt does not do that.

But why change the reporting of the character from ) to shift-0 when the
Ctrl key is down?  I don't think of Ctrl-) as Ctrl-Shift-0.  I much prefer
the Tk way.  Furthermore, there is no way for Leo to convert recognize
Ctrl-Shift-0 as Ctrl-) in a keyboard-independent manner.  This problem was
the cause of the just-deleted horrors.

Anyway, after sleeping on this problem,  I think I'll simply add two sets of
bindings in leoSettings.leo for the cases where Tk and Qt differ in how they
report the key event.  This should not cause problems for either of Leo's
gui plugins. It's not a perfect solution: the multiple bindings will show up
in the print-commands and print-bindings listings, but that can't be helped.

I personally can't avoid this problem while I still support both the Tk and
Qt plugins, but most people will use just one of the plugins, so they can
put only the required bindings in myLeoSettings.leo.

The alternative would be to require the user to describe the upper and lower
case versions of problematic keys. I'd rather not do that unless there are
serious problems with the multiple bindings approach.

Any other comments or suggestions?

Edward

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to