Tkinter and Alt bindings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Tkinter and Alt bindings

Russell Adams
Can anyone here contribute to the problem documented at:

http://stackoverflow.com/questions/9096341/binding-buttons-to-alt-keypresses

Thanks.

------------------------------------------------------------------
Russell Adams                            [hidden email]

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Michael Lange
Hi,

Thus spoketh Russell Adams <[hidden email]>
unto us on Tue, 7 Feb 2012 18:43:42 -0600:

> Can anyone here contribute to the problem documented at:
>
> http://stackoverflow.com/questions/9096341/binding-buttons-to-alt-keypresses
>

I cannot reproduce this here (debian squeeze with IceWM) either, the
return "break" isn't even necessary. I believe this is either a bug in
Tk, maybe version-specific, or (seems more likely to me) a bug in the
window manager you are using.
A while ago I had a problem with (iirc) the handling of modal windows
with Tk and IceWM - other Gui Toolkits worked with IceWM and other WMs did
not show the problem with Tk (much as what you observe now), so I think
this does not prove anything. Back then I filed a bug report to the IceWM
developers and they fixed it within a few days, so I think a bug report
might be worth a try.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Where there's no emotion, there's no motive for violence.
                -- Spock, "Dagger of the Mind", stardate 2715.1
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Russell Adams
On Wed, Feb 08, 2012 at 11:56:32AM +0100, Michael Lange wrote:

> Hi,
>
> Thus spoketh Russell Adams <[hidden email]>
> unto us on Tue, 7 Feb 2012 18:43:42 -0600:
>
> > Can anyone here contribute to the problem documented at:
> >
> > http://stackoverflow.com/questions/9096341/binding-buttons-to-alt-keypresses
> >
>
> I cannot reproduce this here (debian squeeze with IceWM) either, the
> return "break" isn't even necessary. I believe this is either a bug in
> Tk, maybe version-specific, or (seems more likely to me) a bug in the
> window manager you are using.
> A while ago I had a problem with (iirc) the handling of modal windows
> with Tk and IceWM - other Gui Toolkits worked with IceWM and other WMs did
> not show the problem with Tk (much as what you observe now), so I think
> this does not prove anything. Back then I filed a bug report to the IceWM
> developers and they fixed it within a few days, so I think a bug report
> might be worth a try.

I'd love to find a way to trace what's happening, but I'm not familiar
enough with Tkinter.

I started checking xmodmap and pursuing the xev avenue, but cannot
explain the behavior.

At this I'm isolating that not everyone has this issue.

Thanks.


------------------------------------------------------------------
Russell Adams                            [hidden email]

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Bryan Oakley-2
In reply to this post by Michael Lange
On Wed, Feb 8, 2012 at 4:56 AM, Michael Lange <[hidden email]> wrote:
> I cannot reproduce this here (debian squeeze with IceWM) either, the
> return "break" isn't even necessary.


I don't know why the original poster reports that the bindings
sometimes fire. My guess is that it's related to keyboard focus --
maybe the window doesn't have focus when the user thinks it does, so
the event never goes to the application. However, I can say for
certain why "break" is unnecessary and why the letter "s" is inserted
when they press alt-s.

In the original code the user is binding alt-s to the root window.
Such bindings are at the end of the bindtags for a given window. Thus,
the class bindings (where the insert actually happens) fire _before_
the root window bindings. Thus, the character gets inserted, _and
then_ the root binding fires. Returning "break" is useless at this
point because the character has already been inserted into the widget.
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Michael Lange
In reply to this post by Russell Adams
Hi,

Thus spoketh Russell Adams <[hidden email]>
unto us on Wed, 8 Feb 2012 07:51:21 -0600:

> I'd love to find a way to trace what's happening, but I'm not familiar
> enough with Tkinter.
>
> I started checking xmodmap and pursuing the xev avenue, but cannot
> explain the behavior.
>
> At this I'm isolating that not everyone has this issue.
>

ok, maybe we can try to track down the problem.
First, I am quite sure that it is not a python problem but rather one
with Tk and your WM, so we can try the most simple example in tcl:

##########
entry .e
grid .e -column 0 -row 0
bind . <Alt-s> {puts "Alt-s pressed"}
focus .e
#########

If you store this as test.tcl and then run it with $ wish test.tcl , is it
the same as in your Python example?

Then, which window manager are you using, and can you try it with some
other WM(s) , does the problem persist then?

Then, which version of Tk are you using, and, if your distribution offers
this, can you try and install a second Tcl/Tk-version and try if it is the
same with this one?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Knowledge, sir, should be free to all!
                -- Harry Mudd, "I, Mudd", stardate 4513.3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Russell Adams
On Thu, Feb 09, 2012 at 11:22:47AM +0100, Michael Lange wrote:

> Hi,
>
> ##########
> entry .e
> grid .e -column 0 -row 0
> bind . <Alt-s> {puts "Alt-s pressed"}
> focus .e
> #########
>
> If you store this as test.tcl and then run it with $ wish test.tcl , is it
> the same as in your Python example?

Yes, Alt-s does not work. If I change it to Mod1, that triggers but
still adds "s" to the entry widget.

> Then, which window manager are you using, and can you try it with some
> other WM(s) , does the problem persist then?

I haven't had that opportunity, however I was debugging whether it was
an xmodmap issue.

My xmodmap output:
----------------------------------------------------------------------
$ xmodmap
xmodmap:  up to 5 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Alt_R (0x6c),  Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)
----------------------------------------------------------------------

This is really plain. The only change is Alt_R is bound to mod4. I'm
using the left Alt in my testing. At this point, I'm pretty sure its
not xmodmap.

Every other GUI app works fine with Alt. Emacs, Firefox, Pidgeon,
Dolphin, Urxvt, and the list goes on. If there had been a problem
anywhere else with Alt, I'd have immediately tracked it down as a
local configuration issue.

> Then, which version of Tk are you using, and, if your distribution offers
> this, can you try and install a second Tcl/Tk-version and try if it is the
> same with this one?

Ubuntu's TCL 8.5.8-2build1 and Tk 8.5.8-1.

No other, but I may be upgrading to the latest Ubuntu shortly.

Thanks.


------------------------------------------------------------------
Russell Adams                            [hidden email]

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Bryan Oakley-2


On Thursday, February 9, 2012, Russell Adams <[hidden email]> wrote:
> On Thu, Feb 09, 2012 at 11:22:47AM +0100, Michael Lange wrote:
>> Hi,
>>
>> ##########
>> entry .e
>> grid .e -column 0 -row 0
>> bind . <Alt-s> {puts "Alt-s pressed"}
>> focus .e
>> #########
>>
>> If you store this as test.tcl and then run it with $ wish test.tcl , is it
>> the same as in your Python example?
>
> Yes, Alt-s does not work. If I change it to Mod1, that triggers but
> still adds "s" to the entry widget.

Just to reiterate so there's no confusion: the "s" being inserted is a feature, not a bug. I explained why in an earlier message and on stackoverflow. It has to do with the default ordering of bind tags.


_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Russell Adams
On Thu, Feb 09, 2012 at 08:58:25AM -0600, Bryan Oakley wrote:
> Just to reiterate so there's no confusion: the "s" being inserted is a
> feature, not a bug. I explained why in an earlier message and on
> stackoverflow. It has to do with the default ordering of bind tags.

That's understood. I was just being verbose. ;]

Thanks.

------------------------------------------------------------------
Russell Adams                            [hidden email]

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Michael Lange
In reply to this post by Bryan Oakley-2
Hi,

Thus spoketh Bryan Oakley <[hidden email]>
unto us on Thu, 9 Feb 2012 08:58:25 -0600:

> On Thursday, February 9, 2012, Russell Adams <[hidden email]>
> wrote:
> > On Thu, Feb 09, 2012 at 11:22:47AM +0100, Michael Lange wrote:
> >> Hi,
> >>
> >> ##########
> >> entry .e
> >> grid .e -column 0 -row 0
> >> bind . <Alt-s> {puts "Alt-s pressed"}
> >> focus .e
> >> #########
> >>
> >> If you store this as test.tcl and then run it with $ wish test.tcl ,
> >> is
> it
> >> the same as in your Python example?
> >
> > Yes, Alt-s does not work. If I change it to Mod1, that triggers but
> > still adds "s" to the entry widget.
>
> Just to reiterate so there's no confusion: the "s" being inserted is a
> feature, not a bug. I explained why in an earlier message and on
> stackoverflow. It has to do with the default ordering of bind tags.

now I am getting confused ;)
When I run the above example (or the one by the OP) and press Alt-s,
nothing is inserted in the entry, and that is just what I would expect
as of the widget's default bindings, or am I missing something here?

The default bindings are defined in entry.tcl, the relevant part looks
like:

  # Ignore all Alt, Meta, and Control keypresses unless explicitly bound.
  # Otherwise, if a widget binding for one of these is defined, the
  # <KeyPress> class binding will also fire and insert the character,
  # which is wrong.  Ditto for Escape, Return, and Tab.

  bind Entry <Alt-KeyPress> {# nothing}

Now, when I comment out the above line and run the examples, the "s" is
actually inserted in the entry. Russell, is it possible that you miss
entry.tcl or that it is somehow broken? This would explain why the "s"
is inserted when Mod1 is used - but unfortunately not why Alt is not
working  :(
I still suspect the WM...   ;)

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Immortality consists largely of boredom.
                -- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Bryan Oakley-2


On Feb 9, 2012, at 2:04 PM, Michael Lange <[hidden email]> wrote:

The default bindings are defined in entry.tcl, the relevant part looks
like:

 # Ignore all Alt, Meta, and Control keypresses unless explicitly bound.
 # Otherwise, if a widget binding for one of these is defined, the
 # <KeyPress> class binding will also fire and insert the character,
 # which is wrong.  Ditto for Escape, Return, and Tab.

 bind Entry <Alt-KeyPress> {# nothing}

Well, that's interesting. I rarely use alt bindings and didn't know it had that behavior. Thanks for the clarification. 

_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Russell Adams
In reply to this post by Michael Lange
On Thu, Feb 09, 2012 at 09:04:31PM +0100, Michael Lange wrote:
> now I am getting confused ;)

Welcome to the club. ;]

> When I run the above example (or the one by the OP) and press Alt-s,
> nothing is inserted in the entry, and that is just what I would expect
> as of the widget's default bindings, or am I missing something here?

That was my original expectation, I'm trying to solve why the
implementation does not match.

> The default bindings are defined in entry.tcl, the relevant part looks
> like:
>
>   # Ignore all Alt, Meta, and Control keypresses unless explicitly bound.
>   # Otherwise, if a widget binding for one of these is defined, the
>   # <KeyPress> class binding will also fire and insert the character,
>   # which is wrong.  Ditto for Escape, Return, and Tab.
>
>   bind Entry <Alt-KeyPress> {# nothing}

I see these comments, however they don't exclude Mod1, just alt and
other modifiers.

>
> Now, when I comment out the above line and run the examples, the "s" is
> actually inserted in the entry. Russell, is it possible that you miss
> entry.tcl or that it is somehow broken? This would explain why the "s"
> is inserted when Mod1 is used - but unfortunately not why Alt is not
> working  :(

See below.

> I still suspect the WM...   ;)

I don't believe it's the WM. Awesome is minimal unlike something like
KDE or GNOME. I don't control keyboard mappings from it, only xmodmap.

So here's a rundown.

If I reset my keyboard mappings using setxkbmap, my xmodmap looks
like:

$ xmodmap
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

My .Xmodmap:

$ cat .Xmodmap
keycode 108 = Alt_R Meta_R ISO_Level3_Shift
add mod4 = Alt_R

After applying:

$ xmodmap
xmodmap:  up to 5 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock
control     Control_L (0x25),  Control_L (0x42),  Control_R (0x69)
mod1        Alt_L (0x40),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Alt_R (0x6c),  Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

I just tested this TCL snippet, and when I reset it works, when I use
the xmodmap for making Alt_R mod4 it doesn't work. How odd, so digging deeper.

The following is from xev:

Reset, pressing just s:

KeyPress event, serial 25, synthetic NO, window 0x3400001,
    root 0xac, subw 0x0, time 51186823, (561,583), root:(650,603),
    state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XmbLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

After xmodmap, pressing s:

KeyPress event, serial 28, synthetic NO, window 0x3400001,
    root 0xac, subw 0x0, time 51276203, (609,741), root:(698,761),
    state 0x0, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XmbLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

Reset, pressing Alt-s:

KeyPress event, serial 28, synthetic NO, window 0x3400001,
    root 0xac, subw 0x0, time 51190045, (561,583), root:(650,603),
    state 0x8, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XmbLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

After xmodmap, pressing Alt-s:

KeyPress event, serial 28, synthetic NO, window 0x3400001,
    root 0xac, subw 0x0, time 51277296, (609,741), root:(698,761),
    state 0x8, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (73) "s"
    XmbLookupString gives 1 bytes: (73) "s"
    XFilterEvent returns: False

The xev data is identical, whether I'm using my xmodmap or not. The Tk
behavior *IS* different, without xmodmap Alt works, and with it only
Mod1 is honored.

Getting closer to an answer, but still trying to explain the
behavior.

Does this mean that when Alt_R is bound to anything, the Alt_L
behavior changes? Any why only for Tk?

Thanks.

------------------------------------------------------------------
Russell Adams                            [hidden email]

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Michael Lange
Hi,

Thus spoketh Russell Adams <[hidden email]>
unto us on Thu, 9 Feb 2012 14:51:49 -0600:
(...)
>
> I see these comments, however they don't exclude Mod1, just alt and
> other modifiers.

Here ALt and Mod1 behave exactly the same, so
when I change the line in entry.tcl from <Alt-KeyPress> to
<Mod1-KeyPress> the binding to <Alt-s> in the script still works as
expected. Probably this corresponds with the line
    mod1        Alt_L (0x40),  Meta_L (0xcd)
from xmodmap?

(...)
> Getting closer to an answer, but still trying to explain the
> behavior.
>
> Does this mean that when Alt_R is bound to anything, the Alt_L
> behavior changes? Any why only for Tk?

That's it! I just created a ~/.Xmodmap just like yours and after logging
in again the odd Tk entry behavior is just the same here.
About the reason I can only guess; since Tk apparently only knows about
Alt, but does not differ Alt_L from Alt_R it maybe just takes whichever it
gets and internally treats them both as "Alt".

So if you remove your ~/.Xmodmap, is the issue then fixed?

I am not sure what exactly you want to achieve with your ~/.Xmodmap
entries, probably something like to changing your Alt_R key into something
like the AltGr key which I have here on my german keyboard instead?
Anyway, maybe there is another solution possible which does not interfere
with Tk. Here I found something which seems related, don't know if it
helps you any though : https://bbs.archlinux.org/viewtopic.php?id=58145

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

There comes to all races an ultimate crisis which you have yet to face
.... One day our minds became so powerful we dared think of ourselves as
gods.
                -- Sargon, "Return to Tomorrow", stardate 4768.3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Russell Adams
On Fri, Feb 10, 2012 at 04:45:20PM +0100, Michael Lange wrote:
> > Does this mean that when Alt_R is bound to anything, the Alt_L
> > behavior changes? Any why only for Tk?
>
> That's it! I just created a ~/.Xmodmap just like yours and after logging
> in again the odd Tk entry behavior is just the same here.

Great! I'm glad someone else can duplicate the behavior (finally!).

> About the reason I can only guess; since Tk apparently only knows about
> Alt, but does not differ Alt_L from Alt_R it maybe just takes whichever it
> gets and internally treats them both as "Alt".

I don't use Alt_R with Tk at all. Only Alt_L... I use Alt_R as mod4
which is the "windows key" modifier and that is bound to start
applications via hotkeys in the WM. One of my keyboards has no windows
key...

> So if you remove your ~/.Xmodmap, is the issue then fixed?

If I don't alter Alt_R via xmodmap, yes it works. Now I'm trying to
determine why, because Alt_L works for everything else but Tk.

What I don't understand is why does setting Alt_R to a different
modifier change the behavior of Alt_L??

> I am not sure what exactly you want to achieve with your ~/.Xmodmap
> entries, probably something like to changing your Alt_R key into something
> like the AltGr key which I have here on my german keyboard instead?
> Anyway, maybe there is another solution possible which does not interfere
> with Tk. Here I found something which seems related, don't know if it
> helps you any though : https://bbs.archlinux.org/viewtopic.php?id=58145
>

That's really interesting... Great find!

xev reports my right Alt key as keycode 108 and reports as
ISO_Level3_Shift, it's a laptop keyboard. In my xmodmap I set that to
Alt_R and then set it to mod4.

I'll try the approach they document on the page and see if it works.

...

And it works! If I just set the keycode to Super_L, the Alt behavior
works properly.

I still don't understand why changing Alt_R changes the behavior of
Alt_L, but that was exactly the problem. I'd love to figure it out,
but I suspect its X11 weirdness. I had originally suspected it was
related to Mod1/Alt handling

I'll use this for now!

Thanks.

> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> There comes to all races an ultimate crisis which you have yet to face
> .... One day our minds became so powerful we dared think of ourselves as
> gods.
> -- Sargon, "Return to Tomorrow", stardate 4768.3
> _______________________________________________
> Tkinter-discuss mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/tkinter-discuss
>


------------------------------------------------------------------
Russell Adams                            [hidden email]

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Michael Lange
Hi,

Thus spoketh Russell Adams <[hidden email]>
unto us on Fri, 10 Feb 2012 10:35:36 -0600:

(...)

>
> And it works! If I just set the keycode to Super_L, the Alt behavior
> works properly.
>
> I still don't understand why changing Alt_R changes the behavior of
> Alt_L, but that was exactly the problem. I'd love to figure it out,
> but I suspect its X11 weirdness. I had originally suspected it was
> related to Mod1/Alt handling
>
> I'll use this for now!
>

I'm glad I could help!
I think the problem is that Tk does not seem to differ between the two
Alt keys at all; from man bind:

" Similarly, the Alt modifier refers to whichever modifier is associated
with the alt key(s) on the keyboard (keysyms Alt_L and Alt_R). "

So obviously this has to be taken into account when changing xmodmap
behavior. I am not familiar with xmodmap at all, maybe just defining the
changes for "keysym" instead of "keycode" in ~/.Xmodmap helps (iirc
someone suggested this somewhere, I am not sure at all though).

It is just a guess, but maybe gtk and qt are aware of two different Alt
keys so the problem does not occur there.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Men will always be men -- no matter where they are.
                -- Harry Mudd, "Mudd's Women", stardate 1329.8
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Tkinter and Alt bindings

Russell Adams
On Sat, Feb 11, 2012 at 12:38:43PM +0100, Michael Lange wrote:

> Hi,
>
> Thus spoketh Russell Adams <[hidden email]>
> unto us on Fri, 10 Feb 2012 10:35:36 -0600:
>
> (...)
> >
> > And it works! If I just set the keycode to Super_L, the Alt behavior
> > works properly.
> >
> > I still don't understand why changing Alt_R changes the behavior of
> > Alt_L, but that was exactly the problem. I'd love to figure it out,
> > but I suspect its X11 weirdness. I had originally suspected it was
> > related to Mod1/Alt handling
> >
> > I'll use this for now!
> >
>
> I'm glad I could help!
> I think the problem is that Tk does not seem to differ between the two
> Alt keys at all; from man bind:
>
> " Similarly, the Alt modifier refers to whichever modifier is associated
> with the alt key(s) on the keyboard (keysyms Alt_L and Alt_R). "
>
> So obviously this has to be taken into account when changing xmodmap
> behavior. I am not familiar with xmodmap at all, maybe just defining the
> changes for "keysym" instead of "keycode" in ~/.Xmodmap helps (iirc
> someone suggested this somewhere, I am not sure at all though).
>
> It is just a guess, but maybe gtk and qt are aware of two different Alt
> keys so the problem does not occur there.

My only concern here is Alt_L was never modified. The xev output of
Alt-s remained the same when Alt_R wasn't changed and when it was.

Of course I was careful not to change the left Alt key everything uses
when I reassigned right Alt to the Windows key...

That's why this issue has been so frustrating, the behavior changed
when the key in question wasn't modified.

Thanks.

------------------------------------------------------------------
Russell Adams                            [hidden email]

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
_______________________________________________
Tkinter-discuss mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/tkinter-discuss