That's what we're doing, more or less. Adam K
On 1 June 2011 15:44, Sebastian Willing <sebastian.will...@web.de> wrote: > Hi Mark, > > what about a workaround in Padre? We have a Win32 flag which is set in > Windows-Environments, so we could issue an extra update when running on > Windows. It may be limited to Wx versions > 2.8.10 (and < 2.8.13). > > This is no good solution at all but should cause fewer problem than > patching WxWidgets. > > Just my 2 Ct... > > Sebastian > > On 31.05.2011 15:05, Mark Dootson wrote: >> First - sorry for cross posting - but it is of interest to both wxPerl >> and Padre lists. >> >> Around August 2009 ( so after wxWidgets 2.8.10 ) the following changeset >> was applied to wxWidgets 2.8 branch. >> >> http://trac.wxwidgets.org/changeset/62816/wxWidgets/branches/WX_2_8_BRANCH/src/aui/auibook.cpp >> >> It is a partial backport from trunk I think. >> >> The part currently causing problems is: >> >> if (m_tabs->IsFrozen() || m_tabs->GetParent()->IsFrozen()) >> return; >> >> Padre (as an example) uses Wx::WindowUpdateLocker on the top level frame >> to compress window updates and avoid some flicker. >> >> The issue is that on Windows, Wx::WindowUpdateLocker calls ->Freeze on >> the top level frame and all of its children. That is because on Windows, >> the system call used with Freeze does not prevent child windows updating. >> >> On GTK, the system call used with Freeze does prevent child windows >> updating - and so wxWidgets does not call ->Freeze on child windows. >> >> The net effect is that on MS Windows, wxAuiNotebook does not update as >> expected because the code exits as child windows have IsFrozen set at >> the wxWidgets level - but on GTK updates happen as expected - >> wxAuiNotebook instances do not have IsFrozen set at wxWidgets level. >> >> I think that this means wxAuiNotebook is broken in 2.8.11 / 2.8.12 so >> will propose a change on wxWidgets trac. >> >> Even if this change is accepted, wxWidgets 2.8.13 will be some way off. >> >> Should we incorporate a patch into Alien::wxWidgets ? >> >> I think as a general rule, patching wxWidgets other than to allow >> compilation is a bad idea. >> >> Patching to fix this particular issue on 2.8.12 also has problems - >> similar changes are in the 2.9/trunk branch so it is a change that needs >> to be worked with eventually - however, new Freeze and Thaw methods are >> implemented in the wxAUI objects in 2.9/trunk which I'd assume provide a >> way of working with this change. >> >> But - it seems wrong to have the Padre folks struggling for a workaround >> to a change in wxWidgets that I'm fairly sure needs removing in the 2.8 >> branch. >> >> Everyone's thoughts - to patch or not to patch ? Final decision would be >> Mattia's of course as it is not a regular step to patch wxWidgets. >> >> Regards >> >> Mark >> >> >> _______________________________________________ >> Padre-dev mailing list >> Padre-dev@perlide.org >> http://mail.perlide.org/mailman/listinfo/padre-dev > _______________________________________________ > Padre-dev mailing list > Padre-dev@perlide.org > http://mail.perlide.org/mailman/listinfo/padre-dev > _______________________________________________ Padre-dev mailing list Padre-dev@perlide.org http://mail.perlide.org/mailman/listinfo/padre-dev
