https://bugs.kde.org/show_bug.cgi?id=487499

            Bug ID: 487499
           Summary: KWidgetItemDelegate wrongly emits warning about users
                    deleting widgets on itemview destruction
    Classification: Frameworks and Libraries
           Product: frameworks-kitemviews
           Version: unspecified
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: k...@davidedmundson.co.uk
          Reporter: kosse...@kde.org
                CC: kdelibs-b...@kde.org
  Target Milestone: ---

When subclassing KWidgetItemDelegate and installing it on an itemview, serving
widgets by the overridden KWidgetItemDelegate::createItemWidgets(QModelIndex)
method, once the itemview is destructed the internal logic wrongly triggers
warning for each created widget claiming the user would have deleted that
widget:
--- 8< ---
kf.itemviews: User of KWidgetItemDelegate should not delete widgets created by
createItemWidgets!
--- 8< ---

For now consumers decided to work-around this by preventing the state
triggering the warning, by deleting the KWidgetItemDelegate subclass instance
explicitly before the itemview is destroyed, e.g.:
https://invent.kde.org/unmaintained/kdelibs/-/commit/9aaa24814030041f51405182f03c9760e04bc76f
https://invent.kde.org/kdevelop/kdevelop/-/commit/01445fdac0b6d171b7584318a00b5656f3f2db0d

The wrong warnings are triggered due to this:
the widgets returned by the createItemWidgets method are reparented to the
itemview's viewport.
When the itemview is destructed, it will delete the viewport as a child widget.
And even if the delegate has the itemview as parent, if will always be deleted
only after the viewport, as the widget children are deleted at the level of the
itemview QWidget destructor, while the other QObject children only afterwards
at the level of the itemview QObject destructor.
And the viewport again deletes its widget children, to which the created item
widgets now belong. And the QEvent::Destroy event then will be seen by the
still around delegate's KWidgetItemDelegatePool member's
KWidgetItemDelegateEventListener member, as it listens on the created item
widgets' events, in KWidgetItemDelegateEventListener::eventFilter(QObject
*watched, QEvent *event). Wrongly assuming it was the consumer side deleting
the widget.

https://invent.kde.org/unmaintained/kdelibs/-/commit/0225d2895a6f260aa918370e66db483c7d85cf7f
added that check and warning, motivated by double deletion happening from
ktorrent code itself deleting the item widgets as well.
For unknown reasons that commit missed out that at the time already this would
also trigger the warning for "normal" cases, since the reparenting to the
viewport was changed half a year before in
https://invent.kde.org/unmaintained/kdelibs/-/commit/cc38fd9ec8991cb8f89219ddea3efc35325725a3

The logic of the check and warning would need to detect whether the item widget
destruction is a "proper" one done as part of the itemview destruction, or if
it is a bad external one. Besides, the logic is also incomplete as it only
cleans up the KWidgetItemDelegatePoolPrivate's widgetInIndex member, but leaves
a reference in the usedWidgets one.

Dumping analysis here for now. No idea yet how to fix this.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to