From kde-panel-devel Fri Aug 31 19:22:47 2007 From: "Aaron J. Seigo" Date: Fri, 31 Aug 2007 19:22:47 +0000 To: kde-panel-devel Subject: Re: [Panel-devel] dataengines and timing revisited Message-Id: <200708311322.47621.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=118858821809858 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1637104592==" --===============1637104592== Content-Type: multipart/signed; boundary="nextPart3803572.TFguhiMh3Q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart3803572.TFguhiMh3Q Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 31 August 2007, Michael Olbrich wrote: > On Wed, Aug 29, 2007 at 08:40:58PM -0600, Aaron J. Seigo wrote: > > setUpdateFrequency(int) and int updateFrequency() const > > provides a built in timer for the engine (using timerEvent()) and > > cooperates with minUpdateFrequency(), so if an applet kicks an update f= or > > a source this won't cause a second update to that source > > So in a combination of U(2) and A(1) the applet receives updates with > this update frequency if the engine has an update frequency, yes. otherwise if there is no update= =20 frequency set in the engine (or it doesn't supply its own timer), then the= =20 applet will get one updated call only. otherwise, yes. > (minus any skipped updates when the data didn't=20 > change), right? i'm not strictly handling "when the data doesn't change" yet. if the engine= =20 calls setData we trust it knows what it is doing and that the data has=20 changed. so if we make "data didn't change" equivalent to "engine doesn't=20 call setData" then yes =3D) > > connectSource and connectAllsources now take an optional update > > frequency, much as in Michael's patch > > > > the code then works something like this: > > > > connectSource will connect the applet to the DataContainer's updated() > > signal if the updateFrequency < 1. otherwise we round updateFrequency to > > a sane number and create a QObject that stands in and emits the signal > > every qMin(updateFrequency, minimumUpdateFrequency()). > > This sounds wrong. I would expect a possible call to updateSource and an > update of the applet with the (sanitized) updateFrequency. the possible call to update source happens in requestSource; otherwise it=20 needs to wait for the next triggered update. connecting to a source shouldn= 't=20 demand an update, as that really doesn't make any sense for many engines,=20 particularly of type U(1) and for many C(2) situations. when the source get= s=20 updated in due time, an update of the applet will naturally happen. > "possible call to updateSource" means the same check timerEvent() > performs to prevent second updates. well, of course, and since that check needs to be in updateSource to ensure= =20 it's always checked it's not a problem. =3D) > > care needs to be taken to ensure that: > > [...] > > > - DataContainers are auto-removed appropriately > > This does not work right now. The problem is that disconnectNotify() is > only called for expicit disconnects and not when the receiver is > deleted. Atached is a patch that uses a different method to detect > unused DataContainers. > It also adds the actual deletion of the DataContainer. Currently the > memory is leaking. it should still listen disconnectNotify events: an object may disconnect=20 without being deleted, and i don't trust that the only place that will ever= =20 happen is in disconnectSource. having to use invokeMethod (to queue the call for later) shows how ugly thi= s=20 approach is, actually. there is the issue of items calling query() on a=20 source that isn't connected to anything else (and so gets created and then= =20 just hangs out), but i'm really not very comfortable with the usage of=20 invokeMethod there. the rest of the patch looks fine > > this is obviously more complicated than what is there right now but i > > think it is a bit more straight forward than Michael's original patch, > > introduces fewer classes and doesn't introduce regressions in behaviour > > AFAICS. if there are no objections to this approach, i will be finishing > > this up and committing it tomorrow. > > It's not commited yet is it? When I saw that line earlier today I wanted > to comment on the actual code but I couldn't find it. no, something came up yesterday that demanded my immediate attention. > > [2] nearest 50ms? that gives up to 20 updates a second. should be enoug= h? > > I think you missed the "[2]" in the body of the mail... :-) ah, that should've been referenced from "we round updateFrequency to a sane= =20 number" =2D-=20 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 --nextPart3803572.TFguhiMh3Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG2GqH1rcusafx20MRArWRAKCbbuQ/rflzhmLOwXu1p3v55hJnVQCdGa3q C7TpqwnjPCR8Zkv3aOYZsRw= =B55g -----END PGP SIGNATURE----- --nextPart3803572.TFguhiMh3Q-- --===============1637104592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Panel-devel mailing list Panel-devel@kde.org https://mail.kde.org/mailman/listinfo/panel-devel --===============1637104592==--