Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28167 > unrolled thread

Tkinter bug in Entry widgets on OS X

Back to article view | Back to comp.lang.python

Contents

  Tkinter bug in Entry widgets on OS X Arnaud Delobelle <arnodel@gmail.com> - 2012-08-31 11:18 +0100
    Re: Tkinter bug in Entry widgets on OS X Kevin Walzer <kw@codebykevin.com> - 2012-08-31 10:25 -0400
      Re: Tkinter bug in Entry widgets on OS X Arnaud Delobelle <arnodel@gmail.com> - 2012-08-31 16:18 +0100
        Re: Tkinter bug in Entry widgets on OS X Kevin Walzer <kw@codebykevin.com> - 2012-08-31 11:21 -0400
          Re: Tkinter bug in Entry widgets on OS X Alister <alister.ware@ntlworld.com> - 2012-08-31 15:41 +0000
            Re: Tkinter bug in Entry widgets on OS X Arnaud Delobelle <arnodel@gmail.com> - 2012-08-31 20:05 +0100
            Re: Tkinter bug in Entry widgets on OS X Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-08-31 15:30 -0400
            Re: Tkinter bug in Entry widgets on OS X Peter Otten <__peter__@web.de> - 2012-09-01 12:30 +0200
            Re: Tkinter bug in Entry widgets on OS X Arnaud Delobelle <arnodel@gmail.com> - 2012-09-01 13:56 +0100
      Re: Tkinter bug in Entry widgets on OS X "Russell E. Owen" <rowen@uw.edu> - 2012-09-13 13:33 -0700

#28167 — Tkinter bug in Entry widgets on OS X

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

[toc] | [next] | [standalone]

#28180

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

[toc] | [prev] | [next] | [standalone]

#28183

On 31 August 2012 15:25, Kevin Walzer <kw@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

[toc] | [prev] | [next] | [standalone]

#28184

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.

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

[toc] | [prev] | [next] | [standalone]

#28185

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.

[toc] | [prev] | [next] | [standalone]

#28188

On 31 August 2012 16:41, Alister <alister.ware@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

[toc] | [prev] | [next] | [standalone]

#28190

On Fri, 31 Aug 2012 15:41:01 GMT, Alister <alister.ware@ntlworld.com>
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.

	caveat -- I've only written one simple form using Tkinter, so what
do I know...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#28209

Arnaud Delobelle wrote:

> On Friday, 31 August 2012, Dennis Lee Bieber wrote:
> 
>> On Fri, 31 Aug 2012 15:41:01 GMT, Alister
>> <alister.ware@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/

[toc] | [prev] | [next] | [standalone]

#28213

On 1 September 2012 11:30, Peter Otten <__peter__@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

[toc] | [prev] | [next] | [standalone]

#29074

In article <k1qhgn$me0$1@dont-email.me>,
 Kevin Walzer <kw@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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web