Tkinter bug in Entry widgets on OS X

[Arnaud Delobelle]

Hi all,

I'm writing a small GUI on OS X (v. 10.7.4) using Tkinter. I'm using
stock Python. It mostly works fine but there is a bug in Entry
widgets: if and Entry widget has focus and I press the UP arrow, a
"\uf700" gets inserted in the widget. If I press the DOWN arrow, a
"\uf701" gets inserted.

I'm very inexperienced with Tkinter (I've never used it before). All
I'm looking for is a workaround, i.e. a way to somehow suppress that
output.

Thanks in advance,

--
Arnaud

[Kevin Walzer]

On 8/31/12 6:18 AM, Arnaud Delobelle wrote:
> I'm very inexperienced with Tkinter (I've never used it before). All
> I'm looking for is a workaround, i.e. a way to somehow suppress that
> output.

What are you trying to do? Navigate the focus to another widget? You
should use the tab bar for that, not the arrow key. The entry widget is
a single-line widget, and doesn't have up/down as the text widget does.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

[Arnaud Delobelle]

On 31 August 2012 15:25, Kevin Walzer <k...@codebykevin.com> wrote:
> On 8/31/12 6:18 AM, Arnaud Delobelle wrote:
>>
>> I'm very inexperienced with Tkinter (I've never used it before). All
>> I'm looking for is a workaround, i.e. a way to somehow suppress that
>> output.
>
>
> What are you trying to do? Navigate the focus to another widget? You should
> use the tab bar for that, not the arrow key. The entry widget is a
> single-line widget, and doesn't have up/down as the text widget does.

I'm not trying to do anything. When a user presses the UP or DOWN
arrow, then a strange character is inserted in the Entry box. I'd
rather nothing happened.

--
Arnaud

[Kevin Walzer]

On 8/31/12 11:18 AM, Arnaud Delobelle wrote:

>
> I'm not trying to do anything. When a user presses the UP or DOWN
> arrow, then a strange character is inserted in the Entry box. I'd
> rather nothing happened.
>

Why is the user doing that? If they are trying to navigate to a
different part of the interface, they need to use the tab key, not the
arrow key. It's not a multi-line text widget and shouldn't be expected
to work like one.

[Alister]

On Fri, 31 Aug 2012 11:21:14 -0400, Kevin Walzer wrote:

> On 8/31/12 11:18 AM, Arnaud Delobelle wrote:
>
>
>> I'm not trying to do anything. When a user presses the UP or DOWN
>> arrow, then a strange character is inserted in the Entry box. I'd
>> rather nothing happened.
>>
> Why is the user doing that? If they are trying to navigate to a
> different part of the interface, they need to use the tab key, not the
> arrow key. It's not a multi-line text widget and shouldn't be expected
> to work like one.

I agree that it is unexpected in a single line entry box but isn't the 1st
rule of user interface design to assume the user is a moron & will do
things they are not supposed to do?

Therefore invalid inputs should be handled gracefully (not just insert
random characters) which is what I think the original poster is
suggesting.




--
Walk softly and carry a megawatt laser.

[Arnaud Delobelle]

On 31 August 2012 16:41, Alister <aliste...@ntlworld.com> wrote:
> On Fri, 31 Aug 2012 11:21:14 -0400, Kevin Walzer wrote:
>
>> On 8/31/12 11:18 AM, Arnaud Delobelle wrote:
>>
>>
>>> I'm not trying to do anything. When a user presses the UP or DOWN
>>> arrow, then a strange character is inserted in the Entry box. I'd
>>> rather nothing happened.
>>>
>> Why is the user doing that? If they are trying to navigate to a
>> different part of the interface, they need to use the tab key, not the
>> arrow key. It's not a multi-line text widget and shouldn't be expected
>> to work like one.

So you make software that only behaves well when the user does what
they're supposed to do?

> I agree that it is unexpected in a single line entry box but isn't the 1st
> rule of user interface design to assume the user is a moron & will do
> things they are not supposed to do?
>
> Therefore invalid inputs should be handled gracefully (not just insert
> random characters) which is what I think the original poster is
> suggesting.

Indeed.

--
Arnaud

[Peter Otten]

Arnaud Delobelle wrote:

> On Friday, 31 August 2012, Dennis Lee Bieber wrote:
>
>> On Fri, 31 Aug 2012 15:41:01 GMT, Alister
>> <aliste...@ntlworld.com<javascript:;>
>> >
>> declaimed the following in gmane.comp.python.general:

>>
>> > I agree that it is unexpected in a single line entry box but isn't the
>> 1st
>> > rule of user interface design to assume the user is a moron & will do
>> > things they are not supposed to do?
>> >
>> > Therefore invalid inputs should be handled gracefully (not just insert
>> > random characters) which is what I think the original poster is
>> > suggesting.
>>

>> To which I'd suggest the programmer (vs the user), probably needs
>> to
>> code some sort of per-character validation check... After all, there may
>> be situations where accepting pretty much any key-code is desired, and
>> if the widget filters characters before they get to the programmer level
>> that becomes impossible.
>>
>>
> It would be good if I could intercept the key press event and cancel its
> action on the Entry widget. It's easy to intercept the key event, but I
> haven't found out how to prevent the funny characters from being inserted
> into the Entry widget input area.

Untested as I have no Mac:

import Tkinter as tk

def suppress(event):
if event.keycode in {111, 116}:
print "ignoring", event.keycode
return "break"
print event.keycode, "accepted"

root = tk.Tk()
entry = tk.Entry(root)
entry.bind("<Key>", suppress)
entry.pack()

root.mainloop()

> I've struggled to find good tkinter
> docs on the web.

For my (basic) needs I keep coming back to

http://infohost.nmt.edu/tcc/help/pubs/tkinter/

[Arnaud Delobelle]

On 1 September 2012 11:30, Peter Otten <__pet...@web.de> wrote:

> Arnaud Delobelle wrote:
>> It would be good if I could intercept the key press event and cancel its
>> action on the Entry widget. It's easy to intercept the key event, but I
>> haven't found out how to prevent the funny characters from being inserted
>> into the Entry widget input area.
>
> Untested as I have no Mac:
>
> import Tkinter as tk
>
> def suppress(event):
> if event.keycode in {111, 116}:
> print "ignoring", event.keycode
> return "break"
> print event.keycode, "accepted"
>
> root = tk.Tk()
> entry = tk.Entry(root)
> entry.bind("<Key>", suppress)
> entry.pack()
>
> root.mainloop()

This works fine!

return "break" is the piece of knowledge that I was missing. Thanks a
lot! In fact I lied a bit in my original message - I do use the UP
and DOWN arrows on one Entry widget for navigating its command
history. To do this I was binding the "<Up>" and "<Down>" events to a
function, which simply has to return "break" to work around the bug.
On other Entry widgets, I just bind "<Up>" and "<Down>" to a suppress
function which simply returns "break".

>> I've struggled to find good tkinter
>> docs on the web.
>
> For my (basic) needs I keep coming back to
>
> http://infohost.nmt.edu/tcc/help/pubs/tkinter/

Thanks for the link. I was using the docs on effbot which are nice
but probably incomplete (and old).

I guess I should flag up this bug but I don't even know if it's a
Python or Tk problem and have little time or expertise to investigate.

--
Arnaud

[Russell E. Owen]

In article <k1qhgn$me0$1...@dont-email.me>,

Kevin Walzer <k...@codebykevin.com> wrote:

> On 8/31/12 6:18 AM, Arnaud Delobelle wrote:
> > I'm very inexperienced with Tkinter (I've never used it before). All
> > I'm looking for is a workaround, i.e. a way to somehow suppress that
> > output.
>
> What are you trying to do? Navigate the focus to another widget? You
> should use the tab bar for that, not the arrow key. The entry widget is
> a single-line widget, and doesn't have up/down as the text widget does.

Based on other replies it looks as if the OP found a way to intercept
the event with suitable binding.

But I can answer the "why": on Mac OS X in a one-line text box up-arrow
should move the cursor to the beginning and down-arrow to the end.
That's standard behavior.

In any case I can't imagine ever wanting to see special chars get added
when arrow keys are pressed. The default behavior of the Entry widget is
unfortunate.

-- Russell