Question about way of adding timezones support to clock

Aaron J. Seigo aseigo at kde.org
Mon Mar 17 16:28:43 CET 2008


On Monday 17 March 2008, Sebastian Kuegler wrote:
> On Monday 17 March 2008 13:12:40 Rafał Miłecki wrote:
> > > Why don't you just connect to the dataSource for all the timezones you
> > > want? The requests should be bundled by the DataEngine anyway, and you
> > > get nice and clean data out of the DataEngine that way.
> >
> > Unfortunately, requests aren't bundled. I made little test: connected
> > two timezones to my object and then in void Clock::dataUpdated(...) I
> > put:
>
> This would need to be fixed in the DataEngine then. The way I understand
> it, the dataengine should bundle such requests (we don't want one wakeup
> per timezone per second / minute, but one per second / minute, telling us
> the time in all the timezones we've connected to.

that's what happens. however, the calls are serialized such that for each tz 
you get a call to your dataupdated.

bundling them all together would mean sending sth like QMap<QString, 
DataEngine::Data> where the qstring would be the source. then you'd need to 
iterate over it all. 

on the engine side we'd need to gather up all the data that is ready to go to 
any given visualization at that point in time. given that there may be 
multiple sources arriving at different times this would have to be done at 
each and every invocation of dataUpdated.

so this just isn't going to happen, nor should it be needed.

honestly, i've *never* liked how tooltips were handled. setting the tooltip 
before it's used is really suboptimal for something like plasma because:

* our tips are complex, they aren't just small bits of text
* they often require gathering up large amounts of information that we 
otherwise don't care about (as in this case)

doing it on demand, as i did it in kicker actually, would resolve all these 
problems. because then when you got a tip request, we'd ask for the tip to be 
filled and the clock could just send a bunch of query() requests to the 
engine and not care about actually connecting to the source.

-- 
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: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080317/f5e25cec/attachment.pgp 


More information about the Panel-devel mailing list