From: David B. <db...@ua...> - 2012-05-30 14:27:04
|
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. 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). David Beck |
From: Kevin W. <kw...@co...> - 2012-05-31 21:21:05
|
On 5/30/12 9:56 AM, David Beck wrote: > 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. > > 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). > This is more of a Python question than a Tcl question; you might want to post this query on this list: http://mail.python.org/mailman/listinfo/tkinter-discuss --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Ned D. <na...@ac...> - 2012-05-31 23:35:59
|
In article <4FC...@co...>, Kevin Walzer <kw...@co...> wrote: > On 5/30/12 9:56 AM, David Beck wrote: > > 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. > > > > 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). > This is more of a Python question than a Tcl question; you might want to > post this query on this list: > > http://mail.python.org/mailman/listinfo/tkinter-discuss Actually, he did post it there already. I suggested that he post it there and here (particularly if it could be reproduced in Wish) because it seems to me this is most likely an Aqua Tk problem of some sort rather than a Python one. Anyone have any thoughts on that? http://bugs.python.org/issue14959 -- Ned Deily, na...@ac... |
From: Ned D. <na...@ac...> - 2012-05-31 23:57:04
|
In article <nad...@ne...>, Ned Deily <na...@ac...> wrote: > Actually, he did post it there already. I suggested that he post it > there and here (particularly if it could be reproduced in Wish) because > it seems to me this is most likely an Aqua Tk problem of some sort > rather than a Python one. Anyone have any thoughts on that? > > http://bugs.python.org/issue14959 Another data point, FWIW: I just tried the OP's test with Python 3.2.3 linked with an X11 Tk 8.5 (a current MacPorts Python 3.2.3) rather than the python.org 3.2.3 linked with A/S Aqua Cocoa Tk 8.5.11. While I was easily able to reproduce the problem with the latter, I could not reproduce with the former. -- Ned Deily, na...@ac... |
From: Kevin W. <kw...@co...> - 2012-06-01 00:18:57
|
On 5/31/12 7:56 PM, Ned Deily wrote: > Another data point, FWIW: I just tried the OP's test with Python 3.2.3 > linked with an X11 Tk 8.5 (a current MacPorts Python 3.2.3) rather than > the python.org 3.2.3 linked with A/S Aqua Cocoa Tk 8.5.11. While I was > easily able to reproduce the problem with the latter, I could not > reproduce with the former. My guess is that the symptoms the OP are reporting are related to this bug: http://sourceforge.net/tracker/?func=detail&aid=3166688&group_id=12997&atid=112997 I had originally said in the comments to that bug that it may simply be a difference in performance between Cocoa and Carbon, and Cocoa / X11, but I think it goes deeper than this, into some very low-level issues with the event loop integration between Cocoa and Tk, which affects things like screen redraw. I go into those issues here: http://sourceforge.net/mailarchive/message.php?msg_id=27868831 Bottom line, these issues are most likely insoluable without some significant re-architecting of the event loop integration between Cocoa and Tk--a task that is beyond my skills. The original author of the Tk-Cocoa port, Daniel Steffen, is no longer able to devote significant time to maintaining the port because of his employment at Apple, certainly not the level of time required to make changes to the event loop. As I mention in my archived message, it's sometimes possible to work around the screen redraw issues through judicious use of "after" and "update idletasks" commands, but that's often a matter of trial and error. I'm sorry I'm not able to provide further guidance on this or make a more substantial effort to tackle these bugs. As I've said before on this mailing list, patches are welcome, but no one has stepped forward to offer one in this particular case. Thanks, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |