Re: [MACTCL] Dvorak - Qwerty input method?

[Ned D. <na...@ac...>]

In article <4E4...@co...>,
 Kevin Walzer <kw...@co...> wrote:
> On 8/17/11 5:01 PM, Ned Deily wrote:
> > In 
> > article<nad...@ne...>,
> >   Ned Deily<na...@ac...>  wrote:
> >
> >> One other, much more serious problem with the 8.5.10.1 Wish (and seen
> >> with Python IDLE as well):  Qwerty "X" == Dvorak "Q" and pressing Cmd-X
> >> for the common Edit menu Cut command appears to be interpreted
> >> unconditionally as Cmd-Q and causes the app to quit!  That's kinda nasty.
> >
> > I've opened a Tk tracker issue for this:
> >
> > https://sourceforge.net/tracker/?func=detail&aid=3393315&group_id=12997&a
> > tid=112997
> >
> 
> This indeed did seem very odd, but it appears that the Dvorak-Qwerty 
> keyboard layout works that way by design:
> 
> http://stackoverflow.com/questions/808422/mac-style-dvorak-qwerty-command-keyb
> oard-mapping-for-windows
> 
> In other words, the layout reverts to Qwerty when the command-key is 
> pressed. It's a hybrid layout. Why it's set up that way I have no idea, 
> but the issue can probably be avoided with a pure Dvorak layout.
> 
> So, I don't think there's anything to do here...

I think you misunderstand the problem.  Yes, it is a hybrid layout and 
elsewhere the layout is working as designed.  (I assume the rationale is 
for people who are used to touchtyping Dvorak on a Qwerty keyboard.)   
The problem here is that Cocoa Tk is not handling the revert to Qwerty 
properly when the command-key is pressed.  It appears that the keyboard 
accelerators that appear in the menus *are* properly interpreted in 
Qwerty when cmd is pressed (probably Cocoa is doing this?) but, *in 
addition*, something (the Tk code?) is still trying to use the Dvorak 
layout as menu accelerators at the same time.  This leads to various 
confusions, depending what menu accelerators are defined.  The nasty one 
I noted was the accelerator cmd-X appears to also get interpreted as 
cmd-Q (since Dvorak Q is the Qwerty X key).  That leads me to think this 
might be a symptom of a bigger problem.  Why are keyboard accelerators 
apparently being processed in two different places?  Perhaps there is 
something in Tk that needs to be disable for Cocoa?  Just wild 
speculation on my part as I have no familiarity with the code.

-- 
 Ned Deily,
 na...@ac...