From mistervanhalen at gmail.com  Sat Feb  4 14:33:43 2012
From: mistervanhalen at gmail.com (Mister Vanhalen)
Date: Sat, 4 Feb 2012 14:33:43 +0100
Subject: [Tkinter-discuss] get quickly,
 very fast and directly items in a canvas from a moving button mouse
Message-ID: <CADJZtJYS76zE0w-XMrKSRZoDm6dqSg+7FdysSW6Yhvjh7FPT3w@mail.gmail.com>

Hello everyone,

I have got a canvas, where I created some items (rectangles and letters). I
want to catch quickly and directly every item when I move my mouse holding
a button.
I managed to do something but when the movement is too fast, all items are
not selected....

Here is my code
event is from a bind of
canvas.bind('<B1-Motion>', lambda event,a="B1m":self.select(event, a))

def select(self, event, typeofevent):
   #=======================================================================
   # get the canvas object
   #=======================================================================
   canvas = event.widget

   #=======================================================================
   # find object close to mouse
   #=======================================================================
   x = canvas.canvasx(event.x)
   y = canvas.canvasy(event.y)
   item =  canvas.find_closest(x, y, halo=None, start=None)


This code works but when my mouse moves too fast, all items are not select.
I think self.select is called every x milliseconds, so when it is too fast,
it misses some items.
Is there a solution to manage that? I want to get item directly when my
mouse is over and button is held.

Thank you for your help,

Eduard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120204/8b610fb3/attachment.html>

From klappnase at web.de  Sat Feb  4 21:34:16 2012
From: klappnase at web.de (Michael Lange)
Date: Sat, 4 Feb 2012 21:34:16 +0100
Subject: [Tkinter-discuss] get quickly,
 very fast and directly items in a canvas from a moving button mouse
In-Reply-To: <CADJZtJYS76zE0w-XMrKSRZoDm6dqSg+7FdysSW6Yhvjh7FPT3w@mail.gmail.com>
References: <CADJZtJYS76zE0w-XMrKSRZoDm6dqSg+7FdysSW6Yhvjh7FPT3w@mail.gmail.com>
Message-ID: <20120204213416.459409dc.klappnase@web.de>

Hi,

Thus spoketh Mister Vanhalen <mistervanhalen at gmail.com> 
unto us on Sat, 4 Feb 2012 14:33:43 +0100:

> Hello everyone,
> 
> I have got a canvas, where I created some items (rectangles and
> letters). I want to catch quickly and directly every item when I move
> my mouse holding a button.
> I managed to do something but when the movement is too fast, all items
> are not selected....
> 
(...)

there seems to be a certain point where even in the simplest example
some events fail to be handled, not sure if it is Tk- or window manager
related, but here it is the same, if the mouse is *very* fast, the event
might be missed.

>From your example it is hard to tell if there is an additional problem in
your event callback that slows things down further, because the snippet
does not show any visible effect when an item is being selected. Maybe in
your "real world" code some bottleneck is in what happens to "item" later
within your select() method. Maybe some optimization might help.

Two things come to mind which you might try to improve things at least a
little:

* first, using the canvases tag_bind() method instead of bind(). 
* second, try to reduce the amount of Tk calls within the select()
callback; in cases where optimization becomes an issue, tk callbacks
prove to be processed relatively slow and often considerable improvements
can be achieved by storing some Tk related information in Python objects
instead of querying them every time through Tk, or sometimes a trick can
be used to pass them directly to the callback, as in this example:

######
from Tkinter import *

root = Tk()
canv = Canvas(root)
canv.pack(fill='both', expand=1)
t1 = canv.create_text(10, 10, text='foobar', anchor='nw')
t2 = canv.create_text(10, 60, text='foobar', anchor='nw')
t3 = canv.create_text(10, 110, text='foobar', anchor='nw')
t4 = canv.create_text(10, 160, text='foobar', anchor='nw')

def select(event, item):
    print 'selected', item

for t in (t1, t2, t3, t4):
    canv.tag_bind(t, '<Any-Motion>',
                   lambda event, item=t : select(event,item))

root.mainloop()
#######

Now, whem you talk about "selecting" a totally different approach comes
to mind; it sounds to me like you want to draw some kind of "virtual
rectangle" across the canvas to select all the items within this
rectangle, much as you would do in a file browser to select items? If
yes, then maybe you would better actually draw such a rectangle, and then
later "select" all the items within, maybe the ButtonPress and
ButtonRelease event's coords are easier to track than all the coords
within the motion. Just a guess of course.

Regards

Michael

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

[Doctors and Bartenders], We both get the same two kinds of customers
-- the living and the dying.
		-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate
unknown

From mistervanhalen at gmail.com  Sun Feb  5 22:06:46 2012
From: mistervanhalen at gmail.com (Mister Vanhalen)
Date: Sun, 5 Feb 2012 22:06:46 +0100
Subject: [Tkinter-discuss] get quickly,
 very fast and directly items in a canvas from a moving button mouse
In-Reply-To: <20120204213416.459409dc.klappnase@web.de>
References: <CADJZtJYS76zE0w-XMrKSRZoDm6dqSg+7FdysSW6Yhvjh7FPT3w@mail.gmail.com>
	<20120204213416.459409dc.klappnase@web.de>
Message-ID: <CADJZtJb5WcGxPjhLjCJEDY6_Ya70vw48vZ+jq7jEq6Re_XbfUQ@mail.gmail.com>

Hi,

Thank you very much for your answer. I chose your second advice, because
the virtual rectangle seemed to be more adapted for my application. But I
keep in mind also the tag_bind.
Thank you again for your help,
Regards,
Eduard

On Sat, Feb 4, 2012 at 9:34 PM, Michael Lange <klappnase at web.de> wrote:

> Hi,
>
> Thus spoketh Mister Vanhalen <mistervanhalen at gmail.com>
> unto us on Sat, 4 Feb 2012 14:33:43 +0100:
>
> > Hello everyone,
> >
> > I have got a canvas, where I created some items (rectangles and
> > letters). I want to catch quickly and directly every item when I move
> > my mouse holding a button.
> > I managed to do something but when the movement is too fast, all items
> > are not selected....
> >
> (...)
>
> there seems to be a certain point where even in the simplest example
> some events fail to be handled, not sure if it is Tk- or window manager
> related, but here it is the same, if the mouse is *very* fast, the event
> might be missed.
>
> >From your example it is hard to tell if there is an additional problem in
> your event callback that slows things down further, because the snippet
> does not show any visible effect when an item is being selected. Maybe in
> your "real world" code some bottleneck is in what happens to "item" later
> within your select() method. Maybe some optimization might help.
>
> Two things come to mind which you might try to improve things at least a
> little:
>
> * first, using the canvases tag_bind() method instead of bind().
> * second, try to reduce the amount of Tk calls within the select()
> callback; in cases where optimization becomes an issue, tk callbacks
> prove to be processed relatively slow and often considerable improvements
> can be achieved by storing some Tk related information in Python objects
> instead of querying them every time through Tk, or sometimes a trick can
> be used to pass them directly to the callback, as in this example:
>
> ######
> from Tkinter import *
>
> root = Tk()
> canv = Canvas(root)
> canv.pack(fill='both', expand=1)
> t1 = canv.create_text(10, 10, text='foobar', anchor='nw')
> t2 = canv.create_text(10, 60, text='foobar', anchor='nw')
> t3 = canv.create_text(10, 110, text='foobar', anchor='nw')
> t4 = canv.create_text(10, 160, text='foobar', anchor='nw')
>
> def select(event, item):
>    print 'selected', item
>
> for t in (t1, t2, t3, t4):
>    canv.tag_bind(t, '<Any-Motion>',
>                   lambda event, item=t : select(event,item))
>
> root.mainloop()
> #######
>
> Now, whem you talk about "selecting" a totally different approach comes
> to mind; it sounds to me like you want to draw some kind of "virtual
> rectangle" across the canvas to select all the items within this
> rectangle, much as you would do in a file browser to select items? If
> yes, then maybe you would better actually draw such a rectangle, and then
> later "select" all the items within, maybe the ButtonPress and
> ButtonRelease event's coords are easier to track than all the coords
> within the motion. Just a guess of course.
>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> [Doctors and Bartenders], We both get the same two kinds of customers
> -- the living and the dying.
>                -- Dr. Boyce, "The Menagerie" ("The Cage"), stardate
> unknown
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120205/998f5e07/attachment.html>

From RLAdams at AdamsInfoServ.Com  Wed Feb  8 01:43:42 2012
From: RLAdams at AdamsInfoServ.Com (Russell Adams)
Date: Tue, 7 Feb 2012 18:43:42 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
Message-ID: <20120208004341.GG2859@x201>

Can anyone here contribute to the problem documented at:

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

Thanks.

------------------------------------------------------------------
Russell Adams                            RLAdams at AdamsInfoServ.com

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

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

From klappnase at web.de  Wed Feb  8 11:56:32 2012
From: klappnase at web.de (Michael Lange)
Date: Wed, 8 Feb 2012 11:56:32 +0100
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120208004341.GG2859@x201>
References: <20120208004341.GG2859@x201>
Message-ID: <20120208115632.b2ee9e7f.klappnase@web.de>

Hi,

Thus spoketh Russell Adams <RLAdams at AdamsInfoServ.Com> 
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

From RLAdams at AdamsInfoServ.Com  Wed Feb  8 14:51:21 2012
From: RLAdams at AdamsInfoServ.Com (Russell Adams)
Date: Wed, 8 Feb 2012 07:51:21 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120208115632.b2ee9e7f.klappnase@web.de>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
Message-ID: <20120208135121.GA2678@x201>

On Wed, Feb 08, 2012 at 11:56:32AM +0100, Michael Lange wrote:
> Hi,
>
> Thus spoketh Russell Adams <RLAdams at AdamsInfoServ.Com>
> 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                            RLAdams at AdamsInfoServ.com

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

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

From bryan.oakley at gmail.com  Wed Feb  8 15:50:02 2012
From: bryan.oakley at gmail.com (Bryan Oakley)
Date: Wed, 8 Feb 2012 08:50:02 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120208115632.b2ee9e7f.klappnase@web.de>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
Message-ID: <CAKypQnz0k80BivJrokYbbLbn+A-4H8Txo+upfOGN0U2yb7A-Uw@mail.gmail.com>

On Wed, Feb 8, 2012 at 4:56 AM, Michael Lange <klappnase at web.de> 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.

From klappnase at web.de  Thu Feb  9 11:22:47 2012
From: klappnase at web.de (Michael Lange)
Date: Thu, 9 Feb 2012 11:22:47 +0100
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120208135121.GA2678@x201>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
Message-ID: <20120209112247.4a93624a.klappnase@web.de>

Hi,

Thus spoketh Russell Adams <RLAdams at AdamsInfoServ.Com> 
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

From RLAdams at AdamsInfoServ.Com  Thu Feb  9 15:03:20 2012
From: RLAdams at AdamsInfoServ.Com (Russell Adams)
Date: Thu, 9 Feb 2012 08:03:20 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120209112247.4a93624a.klappnase@web.de>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
Message-ID: <20120209140320.GB2858@x201>

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                            RLAdams at AdamsInfoServ.com

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

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

From bryan.oakley at gmail.com  Thu Feb  9 15:58:25 2012
From: bryan.oakley at gmail.com (Bryan Oakley)
Date: Thu, 9 Feb 2012 08:58:25 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120209140320.GB2858@x201>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
Message-ID: <CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>

On Thursday, February 9, 2012, Russell Adams <RLAdams at adamsinfoserv.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120209/6ff501bd/attachment.html>

From RLAdams at AdamsInfoServ.Com  Thu Feb  9 16:01:11 2012
From: RLAdams at AdamsInfoServ.Com (Russell Adams)
Date: Thu, 9 Feb 2012 09:01:11 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
	<CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
Message-ID: <20120209150110.GA5705@x201>

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                            RLAdams at AdamsInfoServ.com

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

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

From klappnase at web.de  Thu Feb  9 21:04:31 2012
From: klappnase at web.de (Michael Lange)
Date: Thu, 9 Feb 2012 21:04:31 +0100
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
	<CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
Message-ID: <20120209210431.7d525f9a.klappnase@web.de>

Hi,

Thus spoketh Bryan Oakley <bryan.oakley at gmail.com> 
unto us on Thu, 9 Feb 2012 08:58:25 -0600:

> On Thursday, February 9, 2012, Russell Adams <RLAdams at adamsinfoserv.com>
> 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

From bryan.oakley at gmail.com  Thu Feb  9 21:49:44 2012
From: bryan.oakley at gmail.com (Bryan Oakley)
Date: Thu, 9 Feb 2012 14:49:44 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120209210431.7d525f9a.klappnase@web.de>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
	<CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
	<20120209210431.7d525f9a.klappnase@web.de>
Message-ID: <DA552E9F-B7F9-4875-BBAA-C85A0F89D321@gmail.com>



On Feb 9, 2012, at 2:04 PM, Michael Lange <klappnase at web.de> 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120209/99f4efcc/attachment.html>

From RLAdams at AdamsInfoServ.Com  Thu Feb  9 21:51:49 2012
From: RLAdams at AdamsInfoServ.Com (Russell Adams)
Date: Thu, 9 Feb 2012 14:51:49 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120209210431.7d525f9a.klappnase@web.de>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
	<CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
	<20120209210431.7d525f9a.klappnase@web.de>
Message-ID: <20120209205149.GE5705@x201>

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                            RLAdams at AdamsInfoServ.com

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

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

From jtlz2 at astro.columbia.edu  Fri Feb 10 12:38:47 2012
From: jtlz2 at astro.columbia.edu (Jonathan Zwart)
Date: Fri, 10 Feb 2012 13:38:47 +0200
Subject: [Tkinter-discuss] python ImageTk.PhotoImage - segfault
Message-ID: <CAJdHgAGPsyNpU8UNRskY3_SN=enXTVNU__WOCXa21BpazSCTnA@mail.gmail.com>

Hi,

I wonder if anyone can help with my segfault question on running tkinter on
a Mac:

http://stackoverflow.com/questions/9142786/python-imagetk-photoimage-segfault

Many thanks,

Jonathan Zwart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120210/408aa411/attachment.html>

From klappnase at web.de  Fri Feb 10 16:45:20 2012
From: klappnase at web.de (Michael Lange)
Date: Fri, 10 Feb 2012 16:45:20 +0100
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120209205149.GE5705@x201>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
	<CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
	<20120209210431.7d525f9a.klappnase@web.de>
	<20120209205149.GE5705@x201>
Message-ID: <20120210164520.787be8fa.klappnase@web.de>

Hi,

Thus spoketh Russell Adams <RLAdams at AdamsInfoServ.Com> 
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

From kw at codebykevin.com  Fri Feb 10 16:52:28 2012
From: kw at codebykevin.com (Kevin Walzer)
Date: Fri, 10 Feb 2012 10:52:28 -0500
Subject: [Tkinter-discuss] python ImageTk.PhotoImage - segfault
In-Reply-To: <CAJdHgAGPsyNpU8UNRskY3_SN=enXTVNU__WOCXa21BpazSCTnA@mail.gmail.com>
References: <CAJdHgAGPsyNpU8UNRskY3_SN=enXTVNU__WOCXa21BpazSCTnA@mail.gmail.com>
Message-ID: <4F353D3C.8090708@codebykevin.com>

On 2/10/12 6:38 AM, Jonathan Zwart wrote:
> Hi,
>
> I wonder if anyone can help with my segfault question on running tkinter
> on a Mac:
>
> http://stackoverflow.com/questions/9142786/python-imagetk-photoimage-segfault
>
> Many thanks,
>
> Jonathan Zwart

Usually a segfault produces a crash log somewhere. Can you post the 
contents of it?

This is using effbot's PIL library, correct, and not Tk's standard image 
support (or TkImg library)?

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

From RLAdams at AdamsInfoServ.Com  Fri Feb 10 17:35:36 2012
From: RLAdams at AdamsInfoServ.Com (Russell Adams)
Date: Fri, 10 Feb 2012 10:35:36 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120210164520.787be8fa.klappnase@web.de>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
	<CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
	<20120209210431.7d525f9a.klappnase@web.de>
	<20120209205149.GE5705@x201>
	<20120210164520.787be8fa.klappnase@web.de>
Message-ID: <20120210163536.GE3259@x201>

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
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss
>


------------------------------------------------------------------
Russell Adams                            RLAdams at AdamsInfoServ.com

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

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

From jtlz2 at astro.columbia.edu  Fri Feb 10 17:39:54 2012
From: jtlz2 at astro.columbia.edu (Jonathan Zwart)
Date: Fri, 10 Feb 2012 18:39:54 +0200
Subject: [Tkinter-discuss] python ImageTk.PhotoImage - segfault
In-Reply-To: <CAJdHgAGPsyNpU8UNRskY3_SN=enXTVNU__WOCXa21BpazSCTnA@mail.gmail.com>
References: <CAJdHgAGPsyNpU8UNRskY3_SN=enXTVNU__WOCXa21BpazSCTnA@mail.gmail.com>
Message-ID: <CAJdHgAEEVo1hOEMDbqR9hGbu3ocoFcYgmh5JVGjLXVz7odPsmw@mail.gmail.com>

>
> On 2/10/12 6:38 AM, Jonathan Zwart wrote:
> >* Hi,
> *>
> >* I wonder if anyone can help with my segfault question on running
> tkinter
> *>* on a Mac:
> *>
> >*
> http://stackoverflow.com/questions/9142786/python-imagetk-photoimage-segfault
> *>
> >* Many thanks,
> *>
> >* Jonathan Zwart
> * Usually a segfault produces a crash log somewhere. Can you post the
> contents of it?
> This is using effbot's PIL library, correct, and not Tk's standard image
> support (or TkImg library)?


I don't know how even to answer either of those questions. Most grateful
for all advice.

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120210/b3549dea/attachment.html>

From klappnase at web.de  Sat Feb 11 12:48:43 2012
From: klappnase at web.de (Michael Lange)
Date: Sat, 11 Feb 2012 12:48:43 +0100
Subject: [Tkinter-discuss] python ImageTk.PhotoImage - segfault
In-Reply-To: <CAJdHgAEEVo1hOEMDbqR9hGbu3ocoFcYgmh5JVGjLXVz7odPsmw@mail.gmail.com>
References: <CAJdHgAGPsyNpU8UNRskY3_SN=enXTVNU__WOCXa21BpazSCTnA@mail.gmail.com>
	<CAJdHgAEEVo1hOEMDbqR9hGbu3ocoFcYgmh5JVGjLXVz7odPsmw@mail.gmail.com>
Message-ID: <20120211124843.68106b4b.klappnase@web.de>

Hi,

Thus spoketh Jonathan Zwart <jtlz2 at astro.columbia.edu> 
unto us on Fri, 10 Feb 2012 18:39:54 +0200:

> >
> > On 2/10/12 6:38 AM, Jonathan Zwart wrote:
> > >* Hi,
> > *>
> > >* I wonder if anyone can help with my segfault question on running
> > tkinter
> > *>* on a Mac:
> > *>
> > >*
> > http://stackoverflow.com/questions/9142786/python-imagetk-photoimage-segfault
> > *>
> > >* Many thanks,
> > *>
> > >* Jonathan Zwart
> > * Usually a segfault produces a crash log somewhere. Can you post the
> > contents of it?
> > This is using effbot's PIL library, correct, and not Tk's standard
> > image support (or TkImg library)?
> 
> 
> I don't know how even to answer either of those questions. Most grateful
> for all advice.
> 

looks like the answer to question #2 is obviously "yes".
Unfortunately I don't know about the Mac, so I cannot help much with
question #1.

So it is just a guess:
maybe you are using a PIL version that has been compiled for a
different Python and/or Tk version than you actually are tryimng to use?
Since the segfault seems to occur immediately after the PhotoImage is
created, maybe it is a Tk-incompatibility rather than one with Python,
but again, it is of course just guessed.

So can you tell us which exact Python, Tk and PIL versions are in use and
are these the default ones on your system or custom installs and do you
have multiple versions of any of these installed?

Regards

Michael

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

Either one of us, by himself, is expendable.  Both of us are not.
		-- Kirk, "The Devil in the Dark", stardate 3196.1

From klappnase at web.de  Sat Feb 11 12:38:43 2012
From: klappnase at web.de (Michael Lange)
Date: Sat, 11 Feb 2012 12:38:43 +0100
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120210163536.GE3259@x201>
References: <20120208004341.GG2859@x201>
	<20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
	<CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
	<20120209210431.7d525f9a.klappnase@web.de>
	<20120209205149.GE5705@x201>
	<20120210164520.787be8fa.klappnase@web.de>
	<20120210163536.GE3259@x201>
Message-ID: <20120211123843.bd7df43f.klappnase@web.de>

Hi,

Thus spoketh Russell Adams <RLAdams at AdamsInfoServ.Com> 
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

From RLAdams at AdamsInfoServ.Com  Sat Feb 11 16:06:43 2012
From: RLAdams at AdamsInfoServ.Com (Russell Adams)
Date: Sat, 11 Feb 2012 09:06:43 -0600
Subject: [Tkinter-discuss] Tkinter and Alt bindings
In-Reply-To: <20120211123843.bd7df43f.klappnase@web.de>
References: <20120208115632.b2ee9e7f.klappnase@web.de>
	<20120208135121.GA2678@x201>
	<20120209112247.4a93624a.klappnase@web.de>
	<20120209140320.GB2858@x201>
	<CAKypQnxt-vy-vBZMzFjQSg3R7=89D1pmO6K1xbxoF56ubpU24Q@mail.gmail.com>
	<20120209210431.7d525f9a.klappnase@web.de>
	<20120209205149.GE5705@x201>
	<20120210164520.787be8fa.klappnase@web.de>
	<20120210163536.GE3259@x201>
	<20120211123843.bd7df43f.klappnase@web.de>
Message-ID: <20120211150643.GA3140@x201>

On Sat, Feb 11, 2012 at 12:38:43PM +0100, Michael Lange wrote:
> Hi,
>
> Thus spoketh Russell Adams <RLAdams at AdamsInfoServ.Com>
> 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                            RLAdams at AdamsInfoServ.com

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

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

From jrm at exa.com  Tue Feb 14 03:04:49 2012
From: jrm at exa.com (jrm at exa.com)
Date: Mon, 13 Feb 2012 21:04:49 -0500 (EST)
Subject: [Tkinter-discuss] Building python 2.6.5 w/TK-TCL 8.5.11 on linux,
	32 & 64 bit
Message-ID: <32942.149.65.134.19.1329185089.squirrel@www.exa.com>

Trying to build python 2.6.5 with a modern TK.  The obvious approach of
setting --with-tcl and --with-tk at configure time is nicely consumed
without error...and then does nothing!   When the setup.py script runs to
build _tkinter later, the 8.5 information is nowhere to be found.

I'm presently trying to hack the 8.5 information directly into setup.py
but that's not going smoothly.  There must be a better way...

Has anyone else experienced this situation?

BTW, upgrading to 3 is not an option...

Thanks!

-jrm



From hxs7709 at tom.com  Tue Feb 14 03:29:53 2012
From: hxs7709 at tom.com (focalization)
Date: Mon, 13 Feb 2012 18:29:53 -0800 (PST)
Subject: [Tkinter-discuss] help: _tkinter.TclError appears when calling
	tkMessageBox.showinfo
Message-ID: <1329186593265-4467314.post@n6.nabble.com>

I have searched the web, and can not find any clue about it.
Please give me some clue about where is the possible root cause of this
problem?
Thanks a lot.

#code
import Tkinter
import tkMessageBox
tkMessageBox.showinfo('aaaaaaaaaa')

#error
Traceback (most recent call last):
  File "/home/xshuang/workspace/CPP/pydemo/src/test.py", line 4, in <module>
    tkMessageBox.showinfo('aaaaaaaaaa')
  File "/usr/local/lib/python2.7/lib-tk/tkMessageBox.py", line 83, in
showinfo
    return _show(title, message, INFO, OK, **options)
  File "/usr/local/lib/python2.7/lib-tk/tkMessageBox.py", line 72, in _show
    res = Message(**options).show()
  File "/usr/local/lib/python2.7/lib-tk/tkCommonDialog.py", line 48, in show
    s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: bad attribute "-type": must be -alpha, -topmost, -zoomed,
or -fullscreen

#how to reproduce
1. In Fedora 12, no problem appears with default python. 
But, after using the following command to update python, yum reinstall
tcl.i686 / tk.i686 / tkinter / tklib, the above problem appears.

2. In Windows, no problem appears.



--
View this message in context: http://python.6.n6.nabble.com/help-tkinter-TclError-appears-when-calling-tkMessageBox-showinfo-tp4467314p4467314.html
Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.

From klappnase at web.de  Tue Feb 14 11:56:33 2012
From: klappnase at web.de (Michael Lange)
Date: Tue, 14 Feb 2012 11:56:33 +0100
Subject: [Tkinter-discuss] Building python 2.6.5 w/TK-TCL 8.5.11 on
 linux, 32 & 64 bit
In-Reply-To: <32942.149.65.134.19.1329185089.squirrel@www.exa.com>
References: <32942.149.65.134.19.1329185089.squirrel@www.exa.com>
Message-ID: <20120214115633.c450eee6.klappnase@web.de>

Hi,

Thus spoketh jrm at exa.com 
unto us on Mon, 13 Feb 2012 21:04:49 -0500 (EST):

> Trying to build python 2.6.5 with a modern TK.  The obvious approach of
> setting --with-tcl and --with-tk at configure time is nicely consumed
> without error...and then does nothing!   When the setup.py script runs
> to build _tkinter later, the 8.5 information is nowhere to be found.
> 
> I'm presently trying to hack the 8.5 information directly into setup.py
> but that's not going smoothly.  There must be a better way...
> 
> Has anyone else experienced this situation?
> 
> BTW, upgrading to 3 is not an option...
> 

I am not sure what actually happens, is no _tkinter built at all or does
it build, but against the wrong of multiple installed Tk versions?

Then, have you checked that all necessary Tcl/Tk headers are installed?
If yes, maybe before compiling Python calling

   $ export LD_LIBRARY_PATH=/usr/local/lib

(or where ever your Tk-8.5 install resides of course) may help. If not,
then please give us more information about your system, installed library
versions, error messages while compiling and so on.

Best regards

Michael

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

It would seem that evil retreats when forcibly confronted.
		-- Yarnek of Excalbia, "The Savage Curtain", stardate
                   5906.5

From klappnase at web.de  Tue Feb 14 12:19:05 2012
From: klappnase at web.de (Michael Lange)
Date: Tue, 14 Feb 2012 12:19:05 +0100
Subject: [Tkinter-discuss] help: _tkinter.TclError appears when calling
 tkMessageBox.showinfo
In-Reply-To: <1329186593265-4467314.post@n6.nabble.com>
References: <1329186593265-4467314.post@n6.nabble.com>
Message-ID: <20120214121905.a2be4304.klappnase@web.de>

Hi,

Thus spoketh focalization <hxs7709 at tom.com> 
unto us on Mon, 13 Feb 2012 18:29:53 -0800 (PST):

> I have searched the web, and can not find any clue about it.
> Please give me some clue about where is the possible root cause of this
> problem?
> Thanks a lot.
> 
> #code
> import Tkinter
> import tkMessageBox
> tkMessageBox.showinfo('aaaaaaaaaa')
> 
> #error
> Traceback (most recent call last):
>   File "/home/xshuang/workspace/CPP/pydemo/src/test.py", line 4, in
> <module> tkMessageBox.showinfo('aaaaaaaaaa')
>   File "/usr/local/lib/python2.7/lib-tk/tkMessageBox.py", line 83, in
> showinfo
>     return _show(title, message, INFO, OK, **options)
>   File "/usr/local/lib/python2.7/lib-tk/tkMessageBox.py", line 72, in
> _show res = Message(**options).show()
>   File "/usr/local/lib/python2.7/lib-tk/tkCommonDialog.py", line 48, in
> show s = w.tk.call(self.command, *w._options(self.options))
> _tkinter.TclError: bad attribute "-type": must be -alpha, -topmost,
> -zoomed, or -fullscreen
> 
> #how to reproduce
> 1. In Fedora 12, no problem appears with default python. 
> But, after using the following command to update python, yum reinstall
> tcl.i686 / tk.i686 / tkinter / tklib, the above problem appears.
> 
> 2. In Windows, no problem appears.
> 

from here it looks like a bug in the Tk version that comes with your
Fedora version update.
Oddly, the error message reported by Tk is the same I get here when I try
to pass an illegal option to a window's wm_attributes command. I have no
idea though why this command should be called in this context. I am not
sure which exactly is the handler in Tk that decides which command to run
when tk_messageBox is called, but it seems to do something weird here.
Maybe you can try and run directly the equivalent Tk code from a
terminal:

    $ wish
    % tk_messageBox -type ok -message "aaaaaaa" -icon info

which is basically what the tkMessageBox Python module does. Does this
produce the same error?

Best regards

Michael

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

Spock: The odds of surviving another attack are 13562190123 to 1, Captain.

From jrm at exa.com  Tue Feb 14 18:26:01 2012
From: jrm at exa.com (jrm at exa.com)
Date: Tue, 14 Feb 2012 12:26:01 -0500 (EST)
Subject: [Tkinter-discuss] Building python 2.6.5 w/TK-TCL 8.5.11 on
 linux, 32 & 64 bit
In-Reply-To: <20120214115633.c450eee6.klappnase@web.de>
References: <32942.149.65.134.19.1329185089.squirrel@www.exa.com>
	<20120214115633.c450eee6.klappnase@web.de>
Message-ID: <42133.149.65.134.19.1329240361.squirrel@www.exa.com>

I may have made some headway, everything seems to build, but still no joy.

1) My configure command looks like this:

  ./configure --prefix="/proj/python/2.6.5-08-jrm-01/x86_linux_na" \
                   --with-tk="/proj/tools/tk/8.5.11-01/x86_linux_na/lib" \
                  --with-tcl="/proj/tools/tcl/8.5.11-01/x86_linux_na/lib" \


2) I've also set LD_LIBRARY_PATH and CFLAGS to include the appropriate
-I and -L flags beforehand invoking configure

CFLAGS="-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES=1 -D_XOPEN_SOURCE=1
-march=i686 -O3 -DQT_NO_DEBUG  -L/proj/readline/6.1-03/x86_linux_na/lib
-L/proj/tools/tk/8.5.11-01/x86_linux_na/lib
-L/proj/tools/tcl/8.5.11-01/x86_linux_na/lib
-I/proj/tools/tk/8.5.11-01/x86_linux_na/include
-I/proj/tools/tcl/8.5.11-01/x86_linux_na/include
-I/proj/readline/6.1-03/x86_linux_na/include" ; export CFLAGS;
LDFLAGS="-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES=1 -D_XOPEN_SOURCE=1
-march=i686 -O3 -DQT_NO_DEBUG  -L/proj/readline/6.1-03/x86_linux_na/lib
-L/proj/tools/tk/8.5.11-01/x86_linux_na/lib
-L/proj/tools/tcl/8.5.11-01/x86_linux_na/lib" ; export LDFLAGS;


3) I added some print statements to the setup.py operation, and it's now
definitely finding what I want it to:
ENTERING detect_tkinter!
  inc_dirs = ['.', 'Include', './Include',
'/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Include',
'/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5',
'/usr/include']
  lib_dirs = ['/proj/readline/6.1-03/x86_linux_na/lib',
'/proj/tools/tk/8.5.11-01/x86_linux_na/lib',
'/proj/tools/tcl/8.5.11-01/x86_linux_na/lib', '/lib64', '/usr/lib64',
'/lib', '/usr/lib']
  for version 8.5, found
/proj/tools/tk/8.5.11-01/x86_linux_na/lib/libtk8.5.so and
/proj/tools/tcl/8.5.11-01/x86_linux_na/lib/libtcl8.5.so
  finished library search with
/proj/tools/tk/8.5.11-01/x86_linux_na/lib/libtk8.5.so and
/proj/tools/tcl/8.5.11-01/x86_linux_na/lib/libtcl8.5.so


4) The build of the _tkinter module seems to go correctly too!

...
building '_tkinter' extension
/opt/gcc-4.3.2/bin/gcc -m32 -D__LINUX__ -D__X86_LINUX__
-D__X86_LINUX2_NA__ -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -DWITH_APPINIT=1 -I/usr/X11R6/include -I.
-I/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/./Include -I.
-IInclude -I./Include
-I/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Include
-I/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5 -c
/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Modules/_tkinter.c
-o
build/temp.linux-x86_64-2.6/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Modules/_tkinter.o
/opt/gcc-4.3.2/bin/gcc -m32 -D__LINUX__ -D__X86_LINUX__
-D__X86_LINUX2_NA__ -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -O3
-Wall -Wstrict-prototypes -DWITH_APPINIT=1 -I/usr/X11R6/include -I.
-I/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/./Include -I.
-IInclude -I./Include
-I/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Include
-I/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5 -c
/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Modules/tkappinit.c
-o
build/temp.linux-x86_64-2.6/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Modules/tkappinit.o
/opt/gcc-4.3.2/bin/gcc -m32 -D__LINUX__ -D__X86_LINUX__
-D__X86_LINUX2_NA__ -pthread -shared -D_FILE_OFFSET_BITS=64
-D_LARGE_FILES=1 -D_XOPEN_SOURCE=1 -march=i686 -O3 -DQT_NO_DEBUG
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES=1 -D_XOPEN_SOURCE=1 -march=i686 -O3
-DQT_NO_DEBUG
build/temp.linux-x86_64-2.6/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Modules/_tkinter.o
build/temp.linux-x86_64-2.6/proj/python/2.6.5-08-jrm-01/x86_linux_na/Python-2.6.5/Modules/tkappinit.o
-L/usr/X11R6/lib64 -L/usr/X11R6/lib
-L/proj/readline/6.1-03/x86_linux_na/lib
-L/proj/tools/tk/8.5.11-01/x86_linux_na/lib
-L/proj/tools/tcl/8.5.11-01/x86_linux_na/lib -ltk8.5 -ltcl8.5 -lX11 -o
build/lib.linux-x86_64-2.6/_tkinter.so
/opt/binutils-2.19.1/bin/ld: skipping incompatible
/usr/X11R6/lib64/libX11.so when searching for -lX11
/opt/binutils-2.19.1/bin/ld: skipping incompatible
/usr/X11R6/lib64/libX11.a when searching for -lX11
creating build/temp.linux-x86_64-2.6/libffi
...


5) Yet, at the ultimate moment of invocation.... :( !!!!


dust:/sw/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib% exapython
Python 2.6.5 (r265:79063, Feb 14 2012, 11:46:18)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter
>>> print Tkinter.TkVersion
8.4


6) I checked sys.path, and verified that it had a specification for
tk-lib.  I thought that perhaps the system library versions of 8.4
tcl/tk might be getting found so I put the 8.5 versions in a location
I figured would be checked first:

>>> import os
>>> print os.environ["LD_LIBRARY_PATH"]
/proj/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib:/grid/sge/lib/glinux:/usr/exaplat/lib:/opt/gm/lib:/opt/mx/lib
>>>
dust:/sw/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib% ls
/proj/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib/*tk*.so
/proj/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib/libtk8.5.so
dust:/sw/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib% ls
/proj/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib/*tcl*.so
/proj/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib/libtcl8.5.so

The files were there alright - but it didn't help...

-jrm



> Hi,
>
> Thus spoketh jrm at exa.com
> unto us on Mon, 13 Feb 2012 21:04:49 -0500 (EST):
>
>> Trying to build python 2.6.5 with a modern TK.  The obvious approach of
>> setting --with-tcl and --with-tk at configure time is nicely consumed
>> without error...and then does nothing!   When the setup.py script runs
>> to build _tkinter later, the 8.5 information is nowhere to be found.
>>
>> I'm presently trying to hack the 8.5 information directly into setup.py
>> but that's not going smoothly.  There must be a better way...
>>
>> Has anyone else experienced this situation?
>>
>> BTW, upgrading to 3 is not an option...
>>
>
> I am not sure what actually happens, is no _tkinter built at all or does
> it build, but against the wrong of multiple installed Tk versions?
>
> Then, have you checked that all necessary Tcl/Tk headers are installed?
> If yes, maybe before compiling Python calling
>
>    $ export LD_LIBRARY_PATH=/usr/local/lib
>
> (or where ever your Tk-8.5 install resides of course) may help. If not,
> then please give us more information about your system, installed library
> versions, error messages while compiling and so on.
>
> Best regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> It would seem that evil retreats when forcibly confronted.
> 		-- Yarnek of Excalbia, "The Savage Curtain", stardate
>                    5906.5
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss
>



From klappnase at web.de  Tue Feb 14 20:02:39 2012
From: klappnase at web.de (Michael Lange)
Date: Tue, 14 Feb 2012 20:02:39 +0100
Subject: [Tkinter-discuss] Building python 2.6.5 w/TK-TCL 8.5.11 on
 linux, 32 & 64 bit
In-Reply-To: <42133.149.65.134.19.1329240361.squirrel@www.exa.com>
References: <32942.149.65.134.19.1329185089.squirrel@www.exa.com>
	<20120214115633.c450eee6.klappnase@web.de>
	<42133.149.65.134.19.1329240361.squirrel@www.exa.com>
Message-ID: <20120214200239.32fd5d8f.klappnase@web.de>

Hi,

Thus spoketh jrm at exa.com 
unto us on Tue, 14 Feb 2012 12:26:01 -0500 (EST):

> I may have made some headway, everything seems to build, but still no
> joy.
> 
> 1) My configure command looks like this:
> 
>   ./configure --prefix="/proj/python/2.6.5-08-jrm-01/x86_linux_na" \
>                    --with-tk="/proj/tools/tk/8.5.11-01/x86_linux_na/lib"
> \
>                   --with-tcl="/proj/tools/tcl/8.5.11-01/x86_linux_na/lib"
> \

(...)

> 5) Yet, at the ultimate moment of invocation.... :( !!!!
> 
> 
> dust:/sw/registry/13796-tk_python-01/serverdist/dist/x86_linux/lib%
> exapython Python 2.6.5 (r265:79063, Feb 14 2012, 11:46:18)
> [GCC 4.3.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import Tkinter
> >>> print Tkinter.TkVersion
> 8.4

maybe you could try a quick and dirty way of fixing this, and (if
possible) remove the tcl- and tk-dev(el) packages of the 8.4 version,
it looks like something (maybe the tclConfig.sh and/or tkConfig.sh ? Or
rather the *.h files ?) are present somewhere and setup.py uses these
instead of the correct 8.5-files. I admit that I don't know the
"official" way to handle this either, it should definitely be possible
somehow. However, at least with Python-2.7.2 when trying to pass
--with-tk and --with-tcl to configure I get:

   # ./configure --with-tk=/foo --with-tcl=/bar
   configure: WARNING: unrecognized options: --with-tk, --with-tcl

so it is no surprise that these don't have any effect. After this
configure runs smoothly, so maybe you just missed this error message?

Regards

Michael


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

	"What happened to the crewman?"
	"The M-5 computer needed a new power source, the crewman merely
        got in the way."
		-- Kirk and Dr. Richard Daystrom, "The Ultimate Computer",
		   stardate 4731.3.

From jtlz2 at astro.columbia.edu  Tue Feb 14 23:35:27 2012
From: jtlz2 at astro.columbia.edu (Jonathan Zwart)
Date: Tue, 14 Feb 2012 22:35:27 +0000
Subject: [Tkinter-discuss] python ImageTk.PhotoImage - segfault
In-Reply-To: <CAJdHgAEEVo1hOEMDbqR9hGbu3ocoFcYgmh5JVGjLXVz7odPsmw@mail.gmail.com>
References: <CAJdHgAGPsyNpU8UNRskY3_SN=enXTVNU__WOCXa21BpazSCTnA@mail.gmail.com>
	<CAJdHgAEEVo1hOEMDbqR9hGbu3ocoFcYgmh5JVGjLXVz7odPsmw@mail.gmail.com>
Message-ID: <CAJdHgAGFWqabKO=rnCFPez=84sW-_+Lh2nFjhVKvjCS35eOyCQ@mail.gmail.com>

>looks like the answer to question #2 is obviously "yes".
>Unfortunately I don't know about the Mac, so I cannot help much with
>question #1.

>So it is just a guess:
>maybe you are using a PIL version that has been compiled for a
>different Python and/or Tk version than you actually are tryimng to use?
>Since the segfault seems to occur immediately after the PhotoImage is
>created, maybe it is a Tk-incompatibility rather than one with Python,
>but again, it is of course just guessed.

>So can you tell us which exact Python, Tk and PIL versions are in use and
>are these the default ones on your system or custom installs and do you
>have multiple versions of any of these installed?

I've upgraded to EDP 7.2-2, but the segfault still happens. So the
versions are (see http://www.enthought.com/products/epdlibraries.php):

python 2.7.2

PIL 1.1.7

Tk is I believe part of the Standard Library.

There are other versions of python on my system but as far as I know
EDP is self-contained. The EDP installation is the default.

Can anyone else reproduce this?

Jon Zwart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120214/9d678b8d/attachment-0001.html>

From hxs7709 at tom.com  Thu Feb 16 02:45:13 2012
From: hxs7709 at tom.com (focalization)
Date: Wed, 15 Feb 2012 17:45:13 -0800 (PST)
Subject: [Tkinter-discuss] help: _tkinter.TclError appears when calling
 tkMessageBox.showinfo
In-Reply-To: <20120214121905.a2be4304.klappnase@web.de>
References: <1329186593265-4467314.post@n6.nabble.com>
	<20120214121905.a2be4304.klappnase@web.de>
Message-ID: <1329356713777-4474509.post@n6.nabble.com>

Hi, Michael:

Thanks a lot, the same problem appears when running the equivalent  tk code:
    $ wish
    % tk_messageBox -type ok -message "aaaaaaa" -icon info
Seems the tk does not run correctly in my environment.
If possible, please give me more clue about this problem.
I will get back to you after getting to learn more knowledge about tk:)

Best regards 
Focalization



> 
> 2. In Windows, no problem appears.
> 

from here it looks like a bug in the Tk version that comes with your
Fedora version update.
Oddly, the error message reported by Tk is the same I get here when I try
to pass an illegal option to a window's wm_attributes command. I have no
idea though why this command should be called in this context. I am not
sure which exactly is the handler in Tk that decides which command to run
when tk_messageBox is called, but it seems to do something weird here.
Maybe you can try and run directly the equivalent Tk code from a
terminal:

    $ wish
    % tk_messageBox -type ok -message "aaaaaaa" -icon info

which is basically what the tkMessageBox Python module does. Does this
produce the same error?




--
View this message in context: http://python.6.n6.nabble.com/help-tkinter-TclError-appears-when-calling-tkMessageBox-showinfo-tp4467314p4474509.html
Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.

From hxs7709 at tom.com  Fri Feb 17 10:34:37 2012
From: hxs7709 at tom.com (focalization)
Date: Fri, 17 Feb 2012 01:34:37 -0800 (PST)
Subject: [Tkinter-discuss] help: _tkinter.TclError appears when calling
 tkMessageBox.showinfo
In-Reply-To: <1329356713777-4474509.post@n6.nabble.com>
References: <1329186593265-4467314.post@n6.nabble.com>
	<20120214121905.a2be4304.klappnase@web.de>
	<1329356713777-4474509.post@n6.nabble.com>
Message-ID: <1329471277601-4479163.post@n6.nabble.com>

The possible reason has been found (still not clear about the root cause).
Multiple tk in my environment lead to some collision.

There have 3 tk in my environments:
/usr/local/lib/tk8.5 with 8.5.11
/usr/lib/tk8.5 with 8.5.11
/usr/share/tk8.5 with 8.5.7, which should be installed by rpm in fedora

So, after I remove the /usr/local/lib/tk8.5 and /usr/lib/tk8.5, the code
works now.
Also the code for wish from Michael works, also.
    tk_messageBox -type ok -message "aaaaaaa" -icon info 

--
View this message in context: http://python.6.n6.nabble.com/help-tkinter-TclError-appears-when-calling-tkMessageBox-showinfo-tp4467314p4479163.html
Sent from the Python - tkinter-discuss mailing list archive at Nabble.com.

From lionkimbro at gmail.com  Tue Feb 21 02:22:54 2012
From: lionkimbro at gmail.com (Lion Kimbro)
Date: Mon, 20 Feb 2012 17:22:54 -0800
Subject: [Tkinter-discuss] General Tkinter Assistance Module
Message-ID: <CAEmWhSgO=jkr6C=bV_dS7HuEBwDOfGA-GFtGw2vxUAzu-x6S_w@mail.gmail.com>

  Has anybody written a general tkinter assistance module?

  I'm thinking of a module that:

  * supplies functions/tools to examine the widget hierarchy from the shell
  * pretty print information about widgets
  * wraps event binding and implements a multiplexer, to work around the
widget.unbind(funcid=...) bug,
  * wraps idle binding and .after scheduling, so that you can review
bindings (like a task manager), see what's going on, pause/continue
(control) idle executions
  * setup Tk & withdraw in 1 call
  * return the full path for a widget
  * standardize access to the text content of Text, Entry, etc.,.
  * ...
  * ... (and anything else that makes life with tkinter generally easier)

  Has anyone created such a thing?

  If no one has created one, is there a good reason for that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120220/ffe7d754/attachment.html>

From python at bdurham.com  Tue Feb 21 14:32:04 2012
From: python at bdurham.com (python at bdurham.com)
Date: Tue, 21 Feb 2012 08:32:04 -0500
Subject: [Tkinter-discuss] General Tkinter Assistance Module
In-Reply-To: <CAEmWhSgO=jkr6C=bV_dS7HuEBwDOfGA-GFtGw2vxUAzu-x6S_w@mail.gmail.com>
References: <CAEmWhSgO=jkr6C=bV_dS7HuEBwDOfGA-GFtGw2vxUAzu-x6S_w@mail.gmail.com>
Message-ID: <1329831124.17260.140661039341089@webmail.messagingengine.com>

Hi Lion,

I've thought about what you've proposed many times (a Tkinter
framework), but have never had the time to implement it.

I think all your suggestions are on target.

Malcolm

<snipped>
I'm thinking of a module that:
  * supplies functions/tools to examine the widget hierarchy from
the shell
  * pretty print information about widgets
  * wraps event binding and implements a multiplexer, to work
around the widget.unbind(funcid=...) bug,
  * wraps idle binding and .after scheduling, so that you can
review bindings (like a task manager), see what's going on,
pause/continue (control) idle executions
  * setup Tk & withdraw in 1 call
  * return the full path for a widget
  * standardize access to the text content of Text, Entry, etc.,.
  * ...
  * ... (and anything else that makes life with tkinter generally
easier)

Has anyone created such a thing?
If no one has created one, is there a good reason for that?
</snipped>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120221/b4f3e912/attachment.html>

From lionkimbro at gmail.com  Tue Feb 21 20:59:42 2012
From: lionkimbro at gmail.com (Lion Kimbro)
Date: Tue, 21 Feb 2012 11:59:42 -0800
Subject: [Tkinter-discuss] General Tkinter Assistance Module
In-Reply-To: <1329831124.17260.140661039341089@webmail.messagingengine.com>
References: <CAEmWhSgO=jkr6C=bV_dS7HuEBwDOfGA-GFtGw2vxUAzu-x6S_w@mail.gmail.com>
	<1329831124.17260.140661039341089@webmail.messagingengine.com>
Message-ID: <CAEmWhSggjWm18ZXCnhkzR7ezinhOx8V-6Xj970WYLqq+n8QpYQ@mail.gmail.com>

  Well, I want to take this on.

  I've already implemented many of these functions, but they are not neatly
implemented, and tied into my personal code at the moment.  A spec should
help clean things up.

  I'll create a Google Doc to collaboratively sketch out aims, an API, put
together requirements, and a basic plan for a team and soliciting
participation.  I'll curate from discussions and what I can find.

  Is anyone else interested?

  I'm looking broadly for things like:
  * specific functions that you think would be valuable
  * advice on who to talk with
  * any advice, generally
  * people who'd be willing to review the sketch API
  * ...

  I'm broadly looking for supporters, users, advisers, etc.,.


On Tue, Feb 21, 2012 at 5:32 AM, <python at bdurham.com> wrote:

>  Hi Lion,
>
>  I've thought about what you've proposed many times (a Tkinter framework),
> but have never had the time to implement it.
>
>  I think all your suggestions are on target.
>
>  Malcolm
>
>  <snipped>
>   I'm thinking of a module that:
>
>   * supplies functions/tools to examine the widget hierarchy from the shell
>   * pretty print information about widgets
>   * wraps event binding and implements a multiplexer, to work around the
> widget.unbind(funcid=...) bug,
>   * wraps idle binding and .after scheduling, so that you can review
> bindings (like a task manager), see what's going on, pause/continue
> (control) idle executions
>   * setup Tk & withdraw in 1 call
>   * return the full path for a widget
>   * standardize access to the text content of Text, Entry, etc.,.
>   * ...
>   * ... (and anything else that makes life with tkinter generally easier)
>
>  Has anyone created such a thing?
>
> If no one has created one, is there a good reason for that?
> </snipped>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120221/277144a2/attachment.html>

From cabraut at yahoo.com  Mon Feb 27 21:55:12 2012
From: cabraut at yahoo.com (CAB)
Date: Mon, 27 Feb 2012 12:55:12 -0800 (PST)
Subject: [Tkinter-discuss] askopenfilename
Message-ID: <1330376112.51452.YahooMailNeo@web39402.mail.mud.yahoo.com>

I am observing some strange behavior in askopenfilename.  I am working 
under Python 2.7 on a Windows7 system.  Let's say I have the following 
bit of code:




f = askopenfilename(parent=root, filetypes=[('Text', '.txt'), ('Documents', '.doc'), ('All Files', '*.*')])


When
 the Open File dialog opens, it has a pulldown list of the filetypes.  
That's great.  However, in my hands, the filetype that is chosen by 
default by tkinter in that list changes from call to call.  That is, on 
some occasions, the default selection in that dropdown is "Text 
(*.txt)".  Other times, from the same bit of code, the default selction 
is "All Files (*.*)".  It always seems to default to either the first 
item in the list or the last item.

I wish I could post the code 
in which I observe this behavior, but it is quite complex and long.  I 
can't recapitulate the behavior in a little jiffy that I wrote to test 
this.  In that jiffy, the default item selected in the pulldown filetype
 list is *always* the first item in the list.

And so, I guess my 
question is, what would cause askopenfilename to default this pulldown list to 
the last item?  Is there any way to tell it which item in the list to 
select as the default?? I can't find anything in the docs that helps.

Thanks,
Chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120227/8cddb4e9/attachment.html>

From raycores at gmail.com  Tue Feb 28 20:22:14 2012
From: raycores at gmail.com (Lynn Oliver)
Date: Tue, 28 Feb 2012 11:22:14 -0800
Subject: [Tkinter-discuss] LabelFrame question: why do options change when
	importing from tkFileDialog?
Message-ID: <EECB381C-31B5-4007-A8A9-F869D180DB90@gmail.com>

I have a main module that includes this statement correctly:

self.fc_inFrame = LabelFrame(self.fc_Frame, height=150, width=300, text="Input File Type", labelanchor=NW, relief="groove", bd=4, font=self.boldfont)

When I move that statement to another module, I get:
_tkinter.TclError: unknown option "-bd"

If I change '-bd' to 'borderwidth' the error does not occur, but next I get:
_tkinter.TclError: unknown option "-font"

I've discovered that 'bd=4' and 'font=...' both work if I import:
from tkFileDialog import askopenfilename, asksaveasfilename, askdirectory
from Tkinter import *
import tkFont
from ttk import *

And they both fail if I import only:
from Tkinter import *
import tkFont
from ttk import *

Can anyone explain what is going on here?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120228/3f897818/attachment.html>

From lionkimbro at gmail.com  Tue Feb 28 20:41:49 2012
From: lionkimbro at gmail.com (Lion Kimbro)
Date: Tue, 28 Feb 2012 11:41:49 -0800
Subject: [Tkinter-discuss] LabelFrame question: why do options change
 when importing from tkFileDialog?
In-Reply-To: <EECB381C-31B5-4007-A8A9-F869D180DB90@gmail.com>
References: <EECB381C-31B5-4007-A8A9-F869D180DB90@gmail.com>
Message-ID: <CAEmWhSiHGFhQNE3v-pKVPKxvMUR-WtWe6ApJpK=R=6QZMVKMEw@mail.gmail.com>

  I don't know for sure, but just an off-the-cuff hunch:
  The ttk widgets have different signatures than the Tk widgets.
  I think that these arguments that you are setting are (if I recall
correctly) some of the arguments that are different.
  I am wondering if somehow you have an import * clobbering a value.

  Perhaps printing the value of LabelFrame to make sure that it is the
class that you think that it is.


On Tue, Feb 28, 2012 at 11:22 AM, Lynn Oliver <raycores at gmail.com> wrote:

> I have a main module that includes this statement correctly:
>
> self.fc_inFrame = LabelFrame(self.fc_Frame, height=150, width=300,
> text="Input File Type", labelanchor=NW, relief="groove", bd=4,
> font=self.boldfont)
>
> When I move that statement to another module, I get:
> _tkinter.TclError: unknown option "-bd"
>
> If I change '-bd' to 'borderwidth' the error does not occur, but next I
> get:
> _tkinter.TclError: unknown option "-font"
>
> I've discovered that 'bd=4' and 'font=...' both work if I import:
> from tkFileDialog import askopenfilename, asksaveasfilename, askdirectory
> from Tkinter import *
> import tkFont
> from ttk import *
>
> And they both fail if I import only:
> from Tkinter import *
> import tkFont
> from ttk import *
>
> Can anyone explain what is going on here?
>
>
>
>
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> http://mail.python.org/mailman/listinfo/tkinter-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120228/f5550c18/attachment.html>

From bryan.oakley at gmail.com  Tue Feb 28 21:47:04 2012
From: bryan.oakley at gmail.com (Bryan Oakley)
Date: Tue, 28 Feb 2012 14:47:04 -0600
Subject: [Tkinter-discuss] LabelFrame question: why do options change
 when importing from tkFileDialog?
In-Reply-To: <EECB381C-31B5-4007-A8A9-F869D180DB90@gmail.com>
References: <EECB381C-31B5-4007-A8A9-F869D180DB90@gmail.com>
Message-ID: <CAKypQnw+CXTr95v47dRzMyoB8ghiApXOFoMfS8no8=mooJW-Mw@mail.gmail.com>

On Tue, Feb 28, 2012 at 1:22 PM, Lynn Oliver <raycores at gmail.com> wrote:
> I've discovered that 'bd=4' and 'font=...' both work if I import:
> from tkFileDialog import askopenfilename, asksaveasfilename, askdirectory
> from Tkinter import *
> import tkFont
> from ttk import *
>
> And they both fail if I import only:
> from Tkinter import *
> import tkFont
> from ttk import *
>
> Can anyone explain what is going on here?

Both Tkinter and ttk define objects with the same name, such as Button
and Label. These two widgets don't share the same set of options. When
you do "import *", whichever one you import second "wins". Thus, in
one file you might be getting a tk button with one set of options, and
in another you get a ttk button with a different set, even though in
both files you use "Button".

IMHO this is a perfect example why you should _never_ "import *".
Instead, I wholeheartedly recommend always working like this:

    import Tkinter as tk
    import ttk
    ...
    tk.Button(...)
    ttk.Button(...)

With that, it becomes completely obvious which sort of button or label
you are creating. Even if you don't mix tk and ttk widgets I think you
should import this way. It makes the code more self-documenting at the
expense of a tiny bit more typing.

From raycores at gmail.com  Tue Feb 28 21:51:36 2012
From: raycores at gmail.com (Lynn Oliver)
Date: Tue, 28 Feb 2012 12:51:36 -0800
Subject: [Tkinter-discuss] Fwd: LabelFrame question: UPDATE
References: <EECB381C-31B5-4007-A8A9-F869D180DB90@gmail.com>
Message-ID: <0F79047E-FF89-4E9F-A517-F109AB9884C7@gmail.com>

My apologies, but on further investigation I discovered that the problem is solved if I put  "Tkinter import " after "from ttk import " it works. 

The order was wrong in the main routine, but it seems that importing another module that imports Tkinter will fix the conflict.



Begin forwarded message:

> From: Lynn Oliver <RaycoRes at gmail.com>
> Subject: LabelFrame question: why do options change when importing from tkFileDialog?
> Date: February 28, 2012 11:22:14 AM PST
> To: Python-Tkinter <tkinter-discuss at python.org>
> 
> I have a main module that includes this statement correctly:
> 
> self.fc_inFrame = LabelFrame(self.fc_Frame, height=150, width=300, text="Input File Type", labelanchor=NW, relief="groove", bd=4, font=self.boldfont)
> 
> When I move that statement to another module, I get:
> _tkinter.TclError: unknown option "-bd"
> 
> If I change '-bd' to 'borderwidth' the error does not occur, but next I get:
> _tkinter.TclError: unknown option "-font"
> 
> I've discovered that 'bd=4' and 'font=...' both work if I import:
> from tkFileDialog import askopenfilename, asksaveasfilename, askdirectory
> from Tkinter import *
> import tkFont
> from ttk import *
> 
> And they both fail if I import only:
> from Tkinter import *
> import tkFont
> from ttk import *
> 
> Can anyone explain what is going on here?
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20120228/7fcba88d/attachment-0001.html>

From raycores at gmail.com  Tue Feb 28 21:52:47 2012
From: raycores at gmail.com (Lynn Oliver)
Date: Tue, 28 Feb 2012 12:52:47 -0800
Subject: [Tkinter-discuss] LabelFrame question: why do options change
	when importing from tkFileDialog?
In-Reply-To: <CAKypQnw+CXTr95v47dRzMyoB8ghiApXOFoMfS8no8=mooJW-Mw@mail.gmail.com>
References: <EECB381C-31B5-4007-A8A9-F869D180DB90@gmail.com>
	<CAKypQnw+CXTr95v47dRzMyoB8ghiApXOFoMfS8no8=mooJW-Mw@mail.gmail.com>
Message-ID: <D33E6319-E1E6-4A6F-B936-C81EBB220CF4@gmail.com>

While I was chasing this down Bryan provided the correct answer.  Thanks, Bryan.  I believe I will follow your advice.

On Feb 28, 2012, at 12:47 PM, Bryan Oakley wrote:

> On Tue, Feb 28, 2012 at 1:22 PM, Lynn Oliver <raycores at gmail.com> wrote:
>> I've discovered that 'bd=4' and 'font=...' both work if I import:
>> from tkFileDialog import askopenfilename, asksaveasfilename, askdirectory
>> from Tkinter import *
>> import tkFont
>> from ttk import *
>> 
>> And they both fail if I import only:
>> from Tkinter import *
>> import tkFont
>> from ttk import *
>> 
>> Can anyone explain what is going on here?
> 
> Both Tkinter and ttk define objects with the same name, such as Button
> and Label. These two widgets don't share the same set of options. When
> you do "import *", whichever one you import second "wins". Thus, in
> one file you might be getting a tk button with one set of options, and
> in another you get a ttk button with a different set, even though in
> both files you use "Button".
> 
> IMHO this is a perfect example why you should _never_ "import *".
> Instead, I wholeheartedly recommend always working like this:
> 
>    import Tkinter as tk
>    import ttk
>    ...
>    tk.Button(...)
>    ttk.Button(...)
> 
> With that, it becomes completely obvious which sort of button or label
> you are creating. Even if you don't mix tk and ttk widgets I think you
> should import this way. It makes the code more self-documenting at the
> expense of a tiny bit more typing.


From klappnase at web.de  Tue Feb 28 22:24:04 2012
From: klappnase at web.de (Michael Lange)
Date: Tue, 28 Feb 2012 22:24:04 +0100
Subject: [Tkinter-discuss] Fwd: LabelFrame question: UPDATE
In-Reply-To: <0F79047E-FF89-4E9F-A517-F109AB9884C7@gmail.com>
References: <EECB381C-31B5-4007-A8A9-F869D180DB90@gmail.com>
	<0F79047E-FF89-4E9F-A517-F109AB9884C7@gmail.com>
Message-ID: <20120228222404.f82bedc8.klappnase@web.de>

Hi,

Thus spoketh Lynn Oliver <raycores at gmail.com> 
unto us on Tue, 28 Feb 2012 12:51:36 -0800:

> My apologies, but on further investigation I discovered that the
> problem is solved if I put  "Tkinter import " after "from ttk import "
> it works. 
> 
> The order was wrong in the main routine, but it seems that importing
> another module that imports Tkinter will fix the conflict.
> 
> 

I have not read the whole thread, so I am not sure if this actually was
the root of your problem, but if you do:

from Tkinter import *
from ttk import *

of course the LabelFrame class imported from ttk will override the one
that came from Tkinter! You can easily verify this from a shell:

$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Tkinter import *
>>> LabelFrame
<class Tkinter.LabelFrame at 0xf708bbfc>
>>> from ttk import *
>>> LabelFrame
<class ttk.Labelframe at 0xf62eb89c>
>>> 


So while it is generally considered to be save to
do "from Tkinter import *" I would strongly recommend to prefer "import
ttk" to "from ttk import *" in order to avoid namespace confusion.

Regards

Michael


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

Men of peace usually are [brave].
		-- Spock, "The Savage Curtain", stardate 5906.5