Repository navigation
ttk.Scrollbar in Notebook widget freezes #59164
Description
| BPO | 14959 |
|---|---|
| Nosy | @ronaldoussoren, @ned-deily |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/ronaldoussoren'
closed_at = <Date 2012-06-02.21:55:30.048>
created_at = <Date 2012-05-30.01:23:11.643>
labels = ['OS-mac', 'invalid', 'type-bug', 'expert-tkinter']
title = 'ttk.Scrollbar in Notebook widget freezes'
updated_at = <Date 2012-06-03.13:28:32.980>
user = 'https://bugs.python.org/davidjamesbeck'bugs.python.org fields:
activity = <Date 2012-06-03.13:28:32.980>
actor = 'davidjamesbeck'
assignee = 'ronaldoussoren'
closed = True
closed_date = <Date 2012-06-02.21:55:30.048>
closer = 'ned.deily'
components = ['macOS', 'Tkinter']
creation = <Date 2012-05-30.01:23:11.643>
creator = 'davidjamesbeck'
dependencies = []
files = ['25758']
hgrepos = []
issue_num = 14959
keywords = []
message_count = 7.0
messages = ['161923', '161924', '161951', '161952', '162033', '162180', '162209']
nosy_count = 3.0
nosy_names = ['ronaldoussoren', 'ned.deily', 'davidjamesbeck']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue14959'
versions = ['Python 3.2', 'Python 3.3']
Activity
davidjamesbeck commentedon May 30, 2012
I am working on an iMac running OS 10.7, TK 8.5.11. I built a simple app containing a Notebook widget, and with Listboxes and linked tkk.Scrollbars on each of three tabs. All of the Scrollbars work the first time I manipulate them, but once the Scrollbar on third tab (the last one created by the script) is manipulated, the others become unresponsive to mouse clicks (though the Scrollbars continue to move when the Listboxes are scrolled using the mouse/trackpad. I first found this issue working with Python 3.2.3 (using IDLE), but the same thing happens with Python 3.3. I asked someone to try this on a PC (Windows 7, Python 3.2.3, Tkinter 8.5), but the problem wasn't recreated.
ned-deily commentedon May 30, 2012
For what it's worth, I was able to reproduce the behavior you describe (also on OS X 10.7 using Python 3.3 and the latest ActiveState Tcl/Tk 8.5.11). Scrolling is a lower level GUI operation that, AFAIK, managed by Tk and OS X frameworks, and not by Python or Tkinter, so my guess is that the problem you're seeing would need to be addressed there. Unless someone else has a better suggestion, I would advise asking about this on the Tkinter-discuss mailing list (http://mail.python.org/mailman/listinfo/tkinter-discuss) and/or, possibly even better, on the Tcl Mac mailing list (http://dir.gmane.org/gmane.comp.lang.tcl.mac) particularly if you can demonstrate the problem with a Tcl code segment. Please report back any updates you receive. Good luck!
davidjamesbeck commentedon May 30, 2012
After playing around with this a bit more, I've found that if the Scrollbars on the different tabs are not aligned (that is, they don't occupy the same EW position in the frame) the effect disappears. I thought that might mean that the last Scrollbar "persists" when you go back to earlier tabs, but the position of the slider in a frozen Scrollbar isn't necessarily the same as the position the last Scrollbar is left in (that is, after you manipulate the Scrollbar that causes the others to freeze, the frozen sliders are still in the configuration they were left in previously, so we're not just seeing a "ghost" of a scrollbar on another tabs).
I've posted this query to the other lists you mentioned as well.
ronaldoussoren commentedon May 30, 2012
I agree with Ned that this is a bug in Tk, especially because the problem goes away with small changes to the layout of the UI.
ned-deily commentedon May 31, 2012
Another data point: I just tried the same test using a Python 3.2.3 linked with an X11 Tk 8.5 (MacPorts) rather than the ActiveState Cocoa Tk 8.5.11 (python.org Python). I was not able to get the test to fail with X11 Tk so that tends to support the idea that the root cause is somewhere in Aqua Tk.
ned-deily commentedon Jun 2, 2012
One final data point: I was unable to reproduce the failure when using a Python 3.2.3 when linked with a current ActiveState Tcl/Tk 8.4, which uses an older Aqua Carbon Tk. The python.org 32-bit-only Pythons use Tcl/Tk 8.4 like this; see http://www.python.org/download/mac/tcltk/ for more info. No guarantee that the problem won't show up there for you or that there won't be other issues (for instance, the Aqua Carbon Tcl/Tk is only available in 32-bit mode) but it *might* be worth a try. Given Kevin's response to your enquiry on the Mac Tcl list, the consensus seems to be that the problem here is indeed in the Cocoa port of Tcl/Tk and is unlikely to be addressed there soon. Sorry!
http://permalink.gmane.org/gmane.comp.lang.tcl.mac/7029
davidjamesbeck commentedon Jun 3, 2012
That's a shame, though I guess it means I can stop struggling with the installation of Tix. Since that's another extension of Tk, the same issue will probably be lurking in there as well. Maybe I'll give wxPyton or QT a shot.
Thanks for your help.