the previous fix, which i accidentally reverted while cleaning up this code,
was actually wrong (so in a way i'm glad i caught it): the signal MUST be emitted
AFTER the item is removed from the collection otherwise any code that checks to
see if that source exists will see that it does still exist even though it was
just signaled as being removed. order sometimes really matters :)
CCMAIL:kde@rusu.info
BUG:287795
the previous fix, which i accidentally reverted while cleaning up this code,
was actually wrong (so in a way i'm glad i caught it): the signal MUST be emitted
AFTER the item is removed from the collection otherwise any code that checks to
see if that source exists will see that it does still exist even though it was
just signaled as being removed. order sometimes really matters :)
CCMAIL:kde@rusu.info
BUG:287795
=6 0x00007f34dd379ab5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
=7 0x00007f34dd37afb6 in abort () at abort.c:92
=8 0x00007f34df37d208 in qt_message_output (msgType=QtFatalMsg,
buf=0x158b628 "ASSERT: \"item_exists()\" in file
/home/kde/include/QtCore/qhash.h, line 1037") at global/qglobal.cpp:2255
=9 0x00007f34df37d384 in qt_message(QtMsgType, const char *, typedef
__va_list_tag __va_list_tag *) (msgType=QtFatalMsg, msg=0x7f34df542188
"ASSERT: \"%s\" in file %s, line %d", ap=0x7fff4835b7e0) at
global/qglobal.cpp:2301
=10 0x00007f34df37dbf2 in qFatal (msg=0x7f34df542188 "ASSERT: \"%s\" in
file %s, line %d") at global/qglobal.cpp:2484
=11 0x00007f34df37cdbb in qt_assert (assertion=0x7f34d5cc7311
"item_exists()", file=0x7f34d5cc72f0 "/home/kde/include/QtCore/qhash.h",
line=1037) at global/qglobal.cpp:1999
=12 0x00007f34d5b109ef in QMutableHashIterator<QString,
Plasma::DataContainer*>::key (this=0x7fff4835b920) at
/home/kde/include/QtCore/qhash.h:1037
=13 0x00007f34d5b0db4a in Plasma::DataEngine::removeAllSources
(this=0x1007a90) at /home/kde/work/kdelibs/plasma/dataengine.cpp:335
=6 0x00007f34dd379ab5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
=7 0x00007f34dd37afb6 in abort () at abort.c:92
=8 0x00007f34df37d208 in qt_message_output (msgType=QtFatalMsg,
buf=0x158b628 "ASSERT: \"item_exists()\" in file
/home/kde/include/QtCore/qhash.h, line 1037") at global/qglobal.cpp:2255
=9 0x00007f34df37d384 in qt_message(QtMsgType, const char *, typedef
__va_list_tag __va_list_tag *) (msgType=QtFatalMsg, msg=0x7f34df542188
"ASSERT: \"%s\" in file %s, line %d", ap=0x7fff4835b7e0) at
global/qglobal.cpp:2301
=10 0x00007f34df37dbf2 in qFatal (msg=0x7f34df542188 "ASSERT: \"%s\" in
file %s, line %d") at global/qglobal.cpp:2484
=11 0x00007f34df37cdbb in qt_assert (assertion=0x7f34d5cc7311
"item_exists()", file=0x7f34d5cc72f0 "/home/kde/include/QtCore/qhash.h",
line=1037) at global/qglobal.cpp:1999
=12 0x00007f34d5b109ef in QMutableHashIterator<QString,
Plasma::DataContainer*>::key (this=0x7fff4835b920) at
/home/kde/include/QtCore/qhash.h:1037
=13 0x00007f34d5b0db4a in Plasma::DataEngine::removeAllSources
(this=0x1007a90) at /home/kde/work/kdelibs/plasma/dataengine.cpp:335
in DataEnginePrivate::connectSource, if it's an immediate call, and QMetaObject::invokeMethod(visualization, "dataUpdated" is called, means the datacontainers' dirty bit must be set to false, otherwise we will get two subsequent dataUpdated
can it have countereffects?
CCMAIL:plasma-devel@kde.org
make save and restore methods of datasource private for now
pu this early so performance/disk usage etc can be tested
svn path=/trunk/KDE/kdelibs/; revision=1181650
* only check for stored data if the DataContainer is thusly marked; removes a huge bottleneck for non-storage-backed engines; currently this probably breaks storage support (since marking the source as storage related probably happens after it is created and so this doesn't get calle?) but there is a FIXME note there that states what the fix should be
* some code clean ups
CCMAIL:batenkaitos@gmail.com
svn path=/trunk/KDE/kdelibs/; revision=1150416
