[Panel-devel] patch: dataengines and timing
Aaron J. Seigo
aseigo at kde.org
Tue Aug 7 14:12:16 CEST 2007
On Monday 06 August 2007, Michael Olbrich wrote:
> Hi,
>
> it's been a while since I brought up this topic. I have looked at the
> growing list of dataengines and this time I actually came up with some
> code.
>
> The attached patch adresses two issues I have seen in data engines.
>
> 1. Many engines create a timer with a more or less random timeout.
> Always the same code. The timer is created in the constructor,
> started when the first source is requested, but unfortunately never
> stoped.
> With this patch the engine specifies a default timeout and a slot
> that is called when necessary.
>
> 2. As I said in a previous thread different applets may require
> different timeouts.
i do like this.
some design issues:
- i can see is that if one applet asks for 5s and another asks for 10s it will
be updated 1
- 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 ... )
- 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.
- 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?
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.
- DataContainer::createObject seems very superfluous
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070807/b1f5f6d3/attachment.pgp
More information about the Panel-devel
mailing list