Simplify tk tooltip setup. #19011
Simplify tk tooltip setup. #19011
Conversation
|
This causes some kind of deadlock if you mouse over buttons too quickly. I just moved left and right over the pan/zoom buttons and it reacts slower and slower until one of the tooltips stays visible and it stops changing to any other one. Sometimes it will unfreeze but going back over something else will get stuck again. |
|
I can't seem to repro this, either on Arch or on Fedora... do you have a screencast? |
|
This one is on Screencast-master.mp4Tooltips swap around fluidly and disappear as necessary. This one is on this branch: Screencast-tooltip.mp4Whenever the tooltip shows up, it randomly causes freezes and mouse jitteriness. |
|
Ah, you may be using Wayland? I can indeed repro with Wayland, not with X... I'll investigate more; let's convert to draft for now. |
|
Yes I am; maybe this is an XWayland bug too? |
|
Indeed, this was easy enough to repro independently of matplotlib: import tkinter as tk
root = tk.Tk()
w = tk.Toplevel(root)
w.withdraw()
def enter(e):
x = root.winfo_rootx()
y = root.winfo_rooty()
w.geometry(f"+{x+25}+{y+25}") # overlapping windows => very slow
# w.geometry(f"+{x+300}+{y+300}") # non overlapping => no problem
w.deiconify()
def leave(e):
w.withdraw()
root.bind("<Enter>", enter)
root.bind("<Leave>", leave)
root.mainloop()Do you have experience interacting with the wayland devs (I personally don't use wayland at all...)? If so can you report this to them? Otherwise I'll open an issue myself... |
|
Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it. |
|
OK, I went for a much less extensive cleanup, basically keeping the old logic. The new commit message: Remove the separate createTooltip constructor, remove the unused x, y, widget and text remain public attributes as one could imaging wanting to |
| widget.bind('<Leave>', leave) | ||
|
8000 |
||
| def __init__(self, widget): | ||
| def __init__(self, widget, text): |
There was a problem hiding this comment.
Could have a short docstring explaining its use. Instantiating a class without binding it to a variable is an unusual construct. (I'm not even sure who holds the reference to the object, but I suppose, it's through the bound methods?)
There was a problem hiding this comment.
Yes, the callbacks maintain the ToolTip alive (this was already the case previously via the enter() and leave() callbacks).
I agree that instantiating the class without binding it is rather awkward, so I decided again to go back a closure-based approach like I originally tried (but keeping the repeated window create/deletions that existed in the previous code).
... switching everything to use closures.
|
Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it. |
The whole module is private, so we can just clean it up directly.
Instead of creating and hiding a new tip window each time, we can just
create a single one and show/hide it as needed.
PR Summary
PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).