peranger/qskinny
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

limit the flood of LayoutRequest events

Browse Source
This commit is contained in:
Uwe Rathmann 2018-03-23 09:55:48 +01:00
parent 6005336cf8
commit 5447aa30fa
1 changed files with 26 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
src/controls/QskControl.cpp
View File

@ -1063,10 +1063,13 @@ void QskControl::resetImplicitSize()
Q_D( QskControl );
if ( d->controlFlags & QskControl::DeferredLayout )
{
if ( !d->blockedImplicitSize )
{
d->blockedImplicitSize = true;
layoutConstraintChanged();
}
}
else
{
const QSizeF sz = implicitSize();
@ -1294,6 +1297,14 @@ void QskControl::itemChange( QQuickItem::ItemChange change,
}
case QQuickItem::ItemVisibleHasChanged:
{
#if 1
/*
~QQuickItem sends QQuickItem::ItemVisibleHasChanged recursively
to all childItems. When being a child ( not only a childItem() )
we are short before being destructed too and any updates
done here are totally pointless. TODO ...
*/
#endif
if ( value.boolValue )
{
if ( d->blockedPolish )
@ -1313,16 +1324,20 @@ void QskControl::itemChange( QQuickItem::ItemChange change,
d->isInitiallyPainted = false;
}
#if 1
// Layout code might consider the visiblility of the children
// and therefore needs to be updated. Posting a statement about
// changed layout constraints has this effect, but is not correct.
// The right way to go would be to create show/hide events and to
// handle them, where visibility of the children matters.
// TODO ...
if ( parentItem() && parentItem()->isVisible() )
{
/*
Layout code might consider the visiblility of the children
and therefore needs to be updated. Posting a statement about
changed layout constraints has this effect, but is not correct.
The right way to go would be to create show/hide events and to
handle them, where visibility of the children matters.
TODO ...
*/
layoutConstraintChanged();
#endif
}
break;
}
case QQuickItem::ItemSceneChange: