bug in flatnotebook in 3.0/wxOSX-Cocoa

Deleting a tab (by clicking the X button) slows down everything in the parent window to the point of being unusable, and also seems to prevent focusing on any child widgets. I’ve attached a runnable sample - this is with 3.0, Cocoa port, Python 2.7.6, OS 10.9. wxPython 2.9.5 does not appear to have this problem, although the flatnotebook module itself appears to be identical, so perhaps it’s a lower-level problem. (Based on my futile attempts at debugging, I suspect the C++ code is the bottleneck here.)

thanks,
Nat

wx_fnb_test.py (1.51 KB)

Nat Echols wrote:

Deleting a tab (by clicking the X button) slows down everything in the
parent window to the point of being unusable, and also seems to prevent
focusing on any child widgets. I've attached a runnable sample - this
is with 3.0, Cocoa port, Python 2.7.6, OS 10.9. wxPython 2.9.5 does not
appear to have this problem, although the flatnotebook module itself
appears to be identical, so perhaps it's a lower-level problem. (Based
on my futile attempts at debugging, I suspect the C++ code is the
bottleneck here.)

It looks to me like something is being triggered in a button event, but deferred until the next idle time, or something like that. Often if I click on the tab and then do nothing for a few seconds, then the page actually gets changed and refreshed shortly after I move the mouse again. Or perhaps when the mouse exits the bounding rectangle of the tab.

I can't imagine wxMac doing anything like that without it showing up all over the place, so it would be good to scour the flatnotebook code to make sure it is not something happening there. Perhaps with my observations about the delayed reaction you may be able to find the issue. If not then a simpler demonstration sample with just stock widget types (no flatnotebook) that can easily be translated to C++ will probably be needed to get the wx-devs to investigate.

···

--
Robin Dunn
Software Craftsman

Yes, it looks like the refresh is delayed until after the mouse leaves the
area that is actually being drawn, at which point it immediately
refreshes. But even after it changes, the text controls are inaccessible.
Is there a way to view what's happening in the event queue? Setting
PYTHONVERBOSE was no help, and using sys.settrace() to view function calls
wasn't much better, probably because these only work on the Python level.

I forgot to mention one other weird feature that I forgot to illustrate in
my sample app: if there is another window in the foreground, it responds
normally. The slowdown only happens when the window with the deleted tabs
has focus (and the problem persists after losing and regaining focus).

thanks,
Nat

···

On Tue, Feb 4, 2014 at 6:38 PM, Robin Dunn <robin@alldunn.com> wrote:

It looks to me like something is being triggered in a button event, but
deferred until the next idle time, or something like that. Often if I
click on the tab and then do nothing for a few seconds, then the page
actually gets changed and refreshed shortly after I move the mouse again.
Or perhaps when the mouse exits the bounding rectangle of the tab.