fix bug where one signalrelay requests an update right after another and gets nothing

svn path=/trunk/KDE/kdebase/workspace/libs/plasma/; revision=764821
This commit is contained in:
Chani Armitage 2008-01-22 17:03:34 +00:00
parent e8b62a6ceb
commit 17ddc75c3a
4 changed files with 27 additions and 3 deletions

View File

@ -90,9 +90,19 @@ int DataContainer::timeSinceLastUpdate() const
bool DataContainer::hasUpdates() const bool DataContainer::hasUpdates() const
{ {
if (d->cached) {
//some signalrelay needs us to pretend we did an update
d->cached = false;
return true;
}
return d->dirty; return d->dirty;
} }
void DataContainer::setNeedsUpdate(bool update)
{
d->cached = update;
}
void DataContainer::checkUsage() void DataContainer::checkUsage()
{ {
if (d->relays.count() < 1 && if (d->relays.count() < 1 &&

View File

@ -91,6 +91,16 @@ class PLASMA_EXPORT DataContainer : public QObject
**/ **/
bool hasUpdates() const; bool hasUpdates() const;
/**
* Indicates that the data should be treated as dirty the next time hasUpdates() is called.
*
* why? because if one SignalRelay times out just after another, the minimum update
* interval stops a real update from being done - but that relay still needs to be given
* data, because it won't have been in the queue and won't have gotten that last update.
* when it checks hasUpdates() we'll lie, and then everything will return to normal.
**/
void setNeedsUpdate(bool update = true);
public Q_SLOTS: public Q_SLOTS:
/** /**
* Check if the DataContainer is still in use. * Check if the DataContainer is still in use.

View File

@ -32,7 +32,7 @@ class DataContainer::Private
{ {
public: public:
Private() Private()
: dirty(false) : dirty(false), cached(false)
{} {}
QObject* signalRelay(const DataContainer* dc, QObject *visualization, QObject* signalRelay(const DataContainer* dc, QObject *visualization,
@ -43,6 +43,7 @@ public:
QMap<uint, SignalRelay *> relays; QMap<uint, SignalRelay *> relays;
QTime updateTs; QTime updateTs;
bool dirty : 1; bool dirty : 1;
bool cached : 1;
}; };
class SignalRelay : public QObject class SignalRelay : public QObject
@ -157,6 +158,7 @@ QObject* DataContainer::Private::signalRelay(const DataContainer* dc, QObject *v
QMap<uint, SignalRelay *>::const_iterator relayIt = relays.find(updateInterval); QMap<uint, SignalRelay *>::const_iterator relayIt = relays.find(updateInterval);
SignalRelay *relay = 0; SignalRelay *relay = 0;
//FIXME what if we have two applets with the same interval and different alignment?
if (relayIt == relays.end()) { if (relayIt == relays.end()) {
relay = new SignalRelay(const_cast<DataContainer*>(dc), this, updateInterval, align); relay = new SignalRelay(const_cast<DataContainer*>(dc), this, updateInterval, align);
relays[updateInterval] = relay; relays[updateInterval] = relay;

View File

@ -252,9 +252,11 @@ void DataEngine::internalUpdateSource(DataContainer* source)
if (d->minUpdateInterval > 0 && if (d->minUpdateInterval > 0 &&
source->timeSinceLastUpdate() < d->minUpdateInterval) { source->timeSinceLastUpdate() < d->minUpdateInterval) {
// skip updating this source; it's been too soon // skip updating this source; it's been too soon
//TODO: should we queue an update in this case? return to this
// once we see the results in real world usage
//kDebug() << "internal update source is delaying" << source->timeSinceLastUpdate() << d->minUpdateInterval; //kDebug() << "internal update source is delaying" << source->timeSinceLastUpdate() << d->minUpdateInterval;
//but fake an update so that the signalrelay that triggered this gets the data from the
//recent update. this way we don't have to worry about queuing - the relay will send a
//signal immediately and everyone else is undisturbed.
source->setNeedsUpdate();
return; return;
} }