[Panel-devel] Applet updating

Aaron J. Seigo aseigo at kde.org
Sun Sep 16 19:19:36 CEST 2007


On Sunday 16 September 2007, Petri Damsten wrote:
> On Sunday 16 September 2007 18:43:13 Aaron J. Seigo wrote:
> > On Sunday 16 September 2007, Petri Damsten wrote:
> > > Trying to get applet update behave similarly whether data is ready in
> > > DataEngine::updateSource() or not. After all applet writer should not
> > > have to know how engine gets it's data.
> >
> > what's the use care for where it matters?
>
> I try to solve the issue that news applet doesn't work at all at the moment
> and would like to see updated called similarly whether engine has the data
> or has to wait for it.
>
> > > 1. Data might not be ready yet so don't call update yet. It gets called
> > > when engine calls setData.
> >
> > which breaks every call to connectSource to existing data sources. this
> > part of the patch is wrong.
>
> OK, didn't thought that. Well it's just one extra updated call if data
> isn't ready.
>
> > > 2. Call source with createWhenMissing true so DataContainer gets
> > > created even if setData is not called in DataEngine::updateSource()
> >
> > this is incorrect; if the engine rejects the source request (returns
> > false) the source should not be created.
>
> But if sourceRequested returns false it doesn't get to the source call (the
> second one)?

right; so this would be for buggy engines that don't create the source in 
sourceRequested. the engine should be fixed in this case (to return false, or 
create the source). working around that bug in a given engine would mean that 
we'd be breaking the internal semantics of DataEngine (that sourceRequested 
is where the source gets created on demand, if at all).

for now, i'd prefer to leave it the way it is.

> > > 3. queue to true so updated gets called after first setData
> >
> > hm.. doesn't it already? or is this a side effect of not calling updated
> > immediately as per point #1?
>
> Yes for engines which setData in updateSource but not for the engines that
> has to wait for the data. If #1 call is there I guess it could be:
> if (!dc->hasUpdates()) {
> 		m_queued = true;
> }

this is exactly what happens in the timerEvent though... aha, i see what 
you're running up against! 

when you connect to a source that exists (or just won't get data filled in for 
a while) then the visualization won't get an update until the next time 
timerEvent is executed, which in the case of an RSS feed would likely be 
quite long (10-30 minutes or more) ... ok, so the *real* solution here is to 
run timerEvent immediately.

does the attached patch work for you? (i can't test right now as my libplasma 
is not in a compilable state atm)

-- 
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: signalrelay_immediatetimerevent.diff
Type: text/x-diff
Size: 616 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20070916/c55dfaa0/attachment.bin 
-------------- 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/20070916/c55dfaa0/attachment.pgp 


More information about the Panel-devel mailing list