The following python line will bind the method “click” to the event when the user presses the mouse button while the pointer is on the widget; no matter where the pointer is when she releases the button.
self.bind('<Button-1>',self.click)
If I use “ButtonRelease” instead of “Button” in the code, it seems that the method “click” will be called for the widget on which the mouse was pressed after the button release; no matter where you release it.
1- Isn’t there a neat way to make it call the bound method only if the mouse button was released on my widget; no matter where it was pressed?
2- Isn’t there neat way to tell it to react only in case of a full click (press and release both on the same widget)?
No “neat” way, because, as Tkinter’s docs say:
and both of your desires are incompatible with this automatic grabbing of the mouse pointer on press-down (which I don’t know how to disable — I think it may be impossible to disable, but proving a negative is hard;-).
So, you need more work, and a non-“neat” solution: on the button-down event’s callback, bind the enter and leave events (to bound methods of a class instance where you can track whether the mouse is currently inside or inside the widget of interest) of that window as well as the button-release; this way, when the release event comes, you know whether to perform the “actual application callback” (if inside) or do nothing (if outside) — that gives you your desire number 2, but describing this as neat would be a stretch.
Desire number 1 is even harder, because you have to track enter and leave events on EVERY widget of interest — it’s not enough to know one bit, whether the mouse is inside or outside, but rather you must keep track of which widget (if any) it’s currently in, to direct the “actual application callback” properly (if at all) at button release time.
While the internals aren’t going to be neat, each functionality can be bound into one neat-to-call function… with slightly “indaginous” internals (a term that’s used more often to refer to root canal work or the like, rather than programming, but may be appropriate when you’re wanting to go against the grain of functionality hard-coded in a framework… that’s the downside of frameworks — you’re in clover as long as you want to behave in ways they support, but when you want to defeat their usual behaviors to do something completely different, that can hardly ever be “neat”!-).