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