https://bugs.kde.org/show_bug.cgi?id=438675
nttkde changed:
What|Removed |Added
CC||watisthis...@outlook.com
--- Comment #3 from nttkde ---
I took a quick look into this couple of months ago, and as far as I understand
it is indeed related to recycling of the placesitemlistwidget objects (which
happens only when part of the places panel is hidden - the scrollbar is there).
Take this with a grain of salt but hopefully it's at least somewhat
readable/helpful. (Zren has mostly seen this already.)
The capacity bar state (m_freeSpaceInfo & m_drawCapacityBar) is stored inside
placesitemlistwidgets and when the widget gets "recycled" into an other index
it still carries the old data with it. ResetCapacityBar() is not called during
recycling.
Other widget parameters are normally reset from
kitemlistview::updateWidgetProperties()
(or initializeItemListWidget) when recycle/reuse happens in
kitemlistview::doLayout().
(doLayout->createWidget->create->popRecycleableWidget and doLayout()
reusableitems [line 1761])
The setData() call in updateCapacityBar() resets widgets' other data but of
course doesn't affect the m_freeSpaceInfo/m_drawCapacityBar since those are
stored in the widget object.
((IIRC for testing purposes, if you create a method in *itemlistwidget classes
that gets called from updateWidgetProperties(), and overload it in
placesitemlistwidget so that it calls resetCapacityBar(), it should fix the
bug.))
First paint will use the wrong data but the next repaint after
updateCapacityBar makes the bar go away
except...
The more annoying aspect is that I can reproduce it on the disk devices too,
and when it appears on an unmounted device the bar won't go away at all in a
following repaint since then url.isEmpty() in placesitemlistwidget.cpp:60 just
returns without recalculating the bar.
('url' is stored in the "model" data externally, and becomes empty for an
unmounted device. 'udi' above exists for unmounted devices too).
Scrolling may make it go away if a different widget gets recycled on its place.
Thus moving the updateCapacityBar() call to the beginning of paint() won't fix
the bug for the disk device items.
If MVC model is to be followed, the placesitemlistwidget (kind of part of the
"view" here, isn't it?) has some tasks that should maybe be rather divided into
the model or controller.
If m_freeSpaceInfo and m_drawCapacityBar could be read and updated from data()
or something similar (from the model that doesn't get recycled) as eg. the url
is read, that would solve the problems,
but currently there doesn't seem to be a way to access the model directly from
the placesitemlistwidget.
PlacesItemListWidget can only read data() and it's copied from the model to the
widget every time it's recycled/reused in the
updateWidgetProperties()->setData().
--
You are receiving this mail because:
You are watching all bug changes.
