In 2.8 I have a matplotlib plot added to a wx.aui.AUINotebook page,
which requires hiding a panel, showing the notebook, and creating the
plot. In the 2.8 version, all this is wrapped in a Freeze() / Thaw()
to great effect: there is a brief pause (< 1 sec) and then the whole
thing is shown at once, cleanly. Without the Freeze() / Thaw(), the
user can see the UI being built, which looks busy/clunky.
But now with 2.9.3, leaving it that way the plot doesn't layout unless
I resize the frame. Since resizing must be forcing a Layout(), I find
that if I add a Layout() it works--but only if that Layout() is **
after the Thaw() **. If it is within the "frozen" portion of UI code,
it doesn't do anything. However if it is after the Thaw(), the user
sees the widgets being built--defeating the purpose of freezing in the
first place!
This is on WinXP; no sample app yet. Thought I'd first inquire if
there is some simple change about Freeze()/Thaw().
Not that I know of. Freeze basically recursively turns off sending of paint events, and Thaw turns them back on and adds a Refresh. I don't think that has changed since 2.8.
Another possibility is that sizer layout is skipping windows if they are frozen, but I don't see anything in the sizer code that is checking for frozenness.
···
On 4/25/12 12:27 PM, C M wrote:
I just noticed another 2.8 -> 2.9 change concern.
In 2.8 I have a matplotlib plot added to a wx.aui.AUINotebook page,
which requires hiding a panel, showing the notebook, and creating the
plot. In the 2.8 version, all this is wrapped in a Freeze() / Thaw()
to great effect: there is a brief pause (< 1 sec) and then the whole
thing is shown at once, cleanly. Without the Freeze() / Thaw(), the
user can see the UI being built, which looks busy/clunky.
But now with 2.9.3, leaving it that way the plot doesn't layout unless
I resize the frame. Since resizing must be forcing a Layout(), I find
that if I add a Layout() it works--but only if that Layout() is **
after the Thaw() **. If it is within the "frozen" portion of UI code,
it doesn't do anything. However if it is after the Thaw(), the user
sees the widgets being built--defeating the purpose of freezing in the
first place!
This is on WinXP; no sample app yet. Thought I'd first inquire if
there is some simple change about Freeze()/Thaw().
Not that I know of. Freeze basically recursively turns off sending of paint
events, and Thaw turns them back on and adds a Refresh. I don't think that
has changed since 2.8.
Another possibility is that sizer layout is skipping windows if they are
frozen, but I don't see anything in the sizer code that is checking for
frozenness.
Well, not sure how to proceed. I've tried a few things and one
arrangement seemed to reduce the visual clutter to a small rectangle
but it's still not comparable to the clean transition in 2.8 in which
all screen changes happen all at once.
Just to pare it down, simply this will block it from being laid out in
2.9 (not 2.8):
Perhaps. Can you make a sample so I can test with the current code?
···
On 4/25/12 9:16 PM, C M wrote:
Not that I know of. Freeze basically recursively turns off sending of paint
events, and Thaw turns them back on and adds a Refresh. I don't think that
has changed since 2.8.
Another possibility is that sizer layout is skipping windows if they are
frozen, but I don't see anything in the sizer code that is checking for
frozenness.
Well, not sure how to proceed. I've tried a few things and one
arrangement seemed to reduce the visual clutter to a small rectangle
but it's still not comparable to the clean transition in 2.8 in which
all screen changes happen all at once.
Just to pare it down, simply this will block it from being laid out in
2.9 (not 2.8):
Perhaps. Can you make a sample so I can test with the current code?
Yes, a sample is attached. If I run this under Python 2.5 / wx2.8.10
/ WinXP, it works fine.
If I run it under Python 2.7 / wx2.9.3 / WinXP, the Layout() does not
happen until you resize the frame. And, interestingly, even after you
resize in order to force a Layout(), it is not done quite right, since
you can still see the edge of a the original "red square" that is
causing there to be a visual glitch in the notebook (see attached
image in the green region of interest).
As is noted in the code, if you move the Layout() after the frozen
portion, it lays out correctly in 2.9.3--but of course then you can't
hide the act of it laying out (my problem).
The problem seems to be in the wx.aui.AuiNotebook class. If you switch it to be a normal wx.Notebook then it works fine. Keep in mind that the AuiNotebook is a composite window with its own sizers and subwindows that also need to be laid out and managed. It looks like this code in wxTabFrame::DoSizing
if (m_tabs->IsFrozen() || m_tabs->GetParent()->IsFrozen())
return;
ss simply skipping doing the layout of the tabs and page windows if the window is currently frozen. Whether there is some good reason for doing that that I don't know, but that's the way it is.
The wx.lib.agw.aui.AuiNotebook doesn't have this problem and works fine in your sample.
···
On 4/26/12 11:40 AM, C M wrote:
Do you think this is potentially a bug in 2.9.3?
Perhaps. Can you make a sample so I can test with the current code?
Yes, a sample is attached. If I run this under Python 2.5 / wx2.8.10
/ WinXP, it works fine.
If I run it under Python 2.7 / wx2.9.3 / WinXP, the Layout() does not
happen until you resize the frame. And, interestingly, even after you
resize in order to force a Layout(), it is not done quite right, since
you can still see the edge of a the original "red square" that is
causing there to be a visual glitch in the notebook (see attached
image in the green region of interest).
As is noted in the code, if you move the Layout() after the frozen
portion, it lays out correctly in 2.9.3--but of course then you can't
hide the act of it laying out (my problem).
The problem seems to be in the wx.aui.AuiNotebook class. If you switch it
to be a normal wx.Notebook then it works fine. Keep in mind that the
AuiNotebook is a composite window with its own sizers and subwindows that
also need to be laid out and managed. It looks like this code in
wxTabFrame::DoSizing
if \(m\_tabs\->IsFrozen\(\) || m\_tabs\->GetParent\(\)\->IsFrozen\(\)\)
return;
ss simply skipping doing the layout of the tabs and page windows if the
window is currently frozen. Whether there is some good reason for doing
that that I don't know, but that's the way it is.
Just to understand this further: does it seem that this code was
added in 2.9.3, since the AUINotebook worked fine in 2.8.10?
The wx.lib.agw.aui.AuiNotebook doesn't have this problem and works fine in
your sample.
Thanks for that tip and chasing this down further.
The problem seems to be in the wx.aui.AuiNotebook class. If you switch it
to be a normal wx.Notebook then it works fine. Keep in mind that the
AuiNotebook is a composite window with its own sizers and subwindows that
also need to be laid out and managed. It looks like this code in
wxTabFrame::DoSizing
if \(m\_tabs\->IsFrozen\(\) || m\_tabs\->GetParent\(\)\->IsFrozen\(\)\)
return;
ss simply skipping doing the layout of the tabs and page windows if the
window is currently frozen. Whether there is some good reason for doing
that that I don't know, but that's the way it is.
Just to understand this further: does it seem that this code was
added in 2.9.3, since the AUINotebook worked fine in 2.8.10?
As far as I remember, it has been added in 2.9 by Julian to avoid too
much re-layouting when adding many pages to a wxAuiNotebook. Of
course, wxAuiNotebook being a composite control, this approach may not
always work well (as you discovered).
The wx.lib.agw.aui.AuiNotebook doesn't have this problem and works fine in
your sample.
Thanks for that tip and chasing this down further.
