[Panel-devel] patch: dataengines and timing

[Michael Olbrich]

On Tue, Aug 07, 2007 at 06:12:16AM -0600, Aaron J. Seigo wrote:
> - i can see is that if one applet asks for 5s and another asks for 10s it will 
> be updated 1

hu?

> - boy does this make the code more complex. it really does make the code paths 
> a lot more circuitous. i'll try and think about this over the next few days 
> (i'm in a board meeting right now ... )

I know. That's why I said I'm not quite satisfied with it...

> - registering a set of global ticks that are shared between objects so if 
> there are N objects that click over at 10s they all share it; is this 
> actually possible with this design right now? as i'm reading it, it isn't. 

It's not. I'm sorry if that wasn't clear. I'm using the SignalManager
class for that too (that's why I used a separate class) but it's not
part of the patch. I don't have an argument for doing that yet and I
didn't want to mix too many things into the patch.

> - i don't like that the updated signal moved to the DataSignalObject subclass 
> of SignalObject. it makes it much harder to understand the design IMHO; what 
> should happen is IMHO that the SignalObject should simply emit a given signal 
> of the object it is associated with. this way the signal stays with the 
> object, so it can be used more conventionally as well without the signal 
> object. it also makes using the shared signaller more easily with other 
> classes. gets ride of the subclassing. it also gets rid of the 
> qobject_cast .. and ....... yeah. so much nicer that way imho. what do you 
> think?

But that means all applets get the same signal and therefore updates
with the same rate. I want to be able to do something like this (e.g.
with that new SignalPlotter widget):

void Foo::updated(const QString& source, const Plasma::DataEngine::Data &data)
{
	QList<double> list;
	list << data[I18N_NOOP("foo")].toDouble();
	list << data[I18N_NOOP("bar")].toDouble();
	myPlotter->addSample(list);
}

This breaks if I cannot rely on a constant update rate.

> some implementation issues:
> - deleteLater() helps solve the issue of objects being used after they are 
> deleted in slots they call.. use that instead of delete directly in those 
> situations.

"(*it)->deleteLater();" instead of "delete *it;" right?

> - DataContainer::createObject seems very superfluous

Not with the current patch. It is needed to provide a subclass with the
desired signal.

michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070807/90c58c0d/attachment.pgp