Configuring time and date from context menu of digital-clock applet
sebas at kde.org
Fri May 29 00:45:50 CEST 2009
On Thursday 28 May 2009 21:10:07 Aaron J. Seigo wrote:
> On Thursday 28 May 2009, Chani wrote:
> > On May 28, 2009 11:09:08 Aaron J. Seigo wrote:
> > > On Thursday 28 May 2009, Chani wrote:
> > > > > > PS: By the way, there is a bug about time configuration. By
> > > > > > default, update interval of digital-clock plasmoid is 60 seconds
> > > > > > when showSeconds is false, and 1 second if it's true. If you
> > > > > > change time from clock kcm and showSeconds is false,
> > > > > > digital-clock applet refreshes itself 1 minute later. Maybe
> > > > > > updateInterval should be hardcoded as 1 second regardless of
> > > > > > showSeconds variable.
> > > > >
> > > > > waking up 60x more often than necessary is a really good way to
> > > > > reduce battery life. the clock doesn't update once a minute just
> > > > > because it's lazy ;)
Yeah, that's definitely a bad idea.
> > > > > as Daniel points out, the correct solution is a dbus signal
> > > > > (probably from kded4) that we can listen to.
> > > >
> > > > I'd like to see any time-jump give all the dataengines a kick,
> > > > actually.
> > >
> > > "any time jump" isn't possible without polling afaik. which isn't an
> > > option.
> > lame. there's no way to get notified when the system time is changed?
We can at least emit such a thing when the system time is changed through a
KDE configuration thing, that'll catch most of the cases I guess (even I
change the time in that way). Other cases I can come up with are timezone
changes (which are per clock anyway and working already), and indeed suspend,
in which case we need a signal (also for example to rescan for wireless
networks, which networkmanager actively prevents, but that's another story).
> not that i've been able to find, and i've looked. every solution i've seen
> on the 'net so far requires polling. nothing from the kernel, nothing from
> ntp, nothing in posix ... meh.
> maybe we should write and ship a custom linux kernel module :P
Android has an in-kernel IPC actually. I'm not being serious about using this.
ntpd (the daemon) is designed to not make big jumps, so there it's probably
less relevant to update the clock, and ntp for a one-off update is called from
KDE code, in which case we can emit this signal again.
Not a complete solution, but reducing the cases in which this fails at least.
> > > > we still (afaik) have the problem that coming out of suspend doesn't
> > > > update the clock until the minute changes, and so on. I have an
> > > > amusing screenshot of the clock and its tooltip disagreeing on the
> > > > time. :)
> > > suspend is a different matter, however. we could do a forced "check
> > > your timing" of all engines when we come out of suspend if the power
> > > manager has such a signal for us to listen to.
> > yeah, that'd probably do.
> > there must be such a signal... right?
> iirc there isn't right now. :( but hopefully we can add one for 4.4.
> *fingers crossed*
Shouldn't be hard to do, it might even qualify for 4.3. I'd consider the clock
displaying the wrong time for up to a minute a rather visible bug, while the
impact of the fix seems trivial (adding a D-Bus signal in powerdevil or Solid,
catching it in libplasmaclock and calling update()).
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090529/8c69b163/attachment-0001.sig
More information about the Plasma-devel