Mister Vanhalen | 4 Feb 14:33 2012
Picon

get quickly, very fast and directly items in a canvas from a moving button mouse

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

_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss <at> python.org
http://mail.python.org/mailman/listinfo/tkinter-discuss
Michael Lange | 4 Feb 21:34 2012
Picon

Re: get quickly, very fast and directly items in a canvas from a moving button mouse

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
Mister Vanhalen | 5 Feb 22:06 2012
Picon

Re: get quickly, very fast and directly items in a canvas from a moving button mouse

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

_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss <at> python.org
http://mail.python.org/mailman/listinfo/tkinter-discuss
Russell Adams | 8 Feb 01:43 2012

Tkinter and Alt bindings

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
Michael Lange | 8 Feb 11:56 2012
Picon

Re: Tkinter and Alt bindings

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
Russell Adams | 8 Feb 14:51 2012

Re: Tkinter and Alt bindings

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
Bryan Oakley | 8 Feb 15:50 2012
Picon

Re: Tkinter and Alt bindings

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.
Michael Lange | 9 Feb 11:22 2012
Picon

Re: Tkinter and Alt bindings

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
Russell Adams | 9 Feb 15:03 2012

Re: Tkinter and Alt bindings

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
Bryan Oakley | 9 Feb 15:58 2012
Picon

Re: Tkinter and Alt bindings



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.

_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss <at> python.org
http://mail.python.org/mailman/listinfo/tkinter-discuss

Gmane