On Fri, 2012-04-13 at 10:20 -0400, Chris Lumens wrote:
> > I think that majority of users will set time only once (in one "run of
> > clicking the up/down buttons") and after setting it as system time it is
> > extremely easy to update the displayed time. You can, for example, just
> > set environment variable $TZ to some timezone and the displayed time
> > gets automatically adapted and updated. I see it as a good trade-off.
>
> I agree.
>
> > Comments are, of course, welcome. If anybody sees any major problem in
> > it (I can imagine e.g. weird times in logs, but do not consider this
> > major), I can rewrite it and update the displayed time in a more
> > complicated way while preserving system time until apply method is
> > invoked.
>
> Well, my concern was that it looked like the original patch was setting
> the system time over and over again in a callback as the time changed.
> Perhaps I am reading it wrong?
My intention was (and I've tested that the proposed code was working
this way), that system time is updated 2 seconds after the last click on
one of the {hours|minutes}{up|down} buttons, not after each click.
The proposed code use 2 timers -- one for updating the displayed time
and another one for setting the system time only after 2 seconds of
inactivity on the time-setting buttons.
Time-setting buttons' callbacks:
1) stop timer for updating the displayed time
2) stop timer for setting the system time
3) start a new timer for setting the system time (that happens 2 seconds
later iff no time-setting button's callback is invoked) which then
starts a new timer for updating the displayed time
So once the user stops clicking the time-setting buttons for 2 seconds,
system time is set and a new timer is started for updating the displayed
time. This way we get advantages mentioned in the previous email, but we
don't update system time every time the user clicks on one of the
time-setting buttons. I think that majority of users will set their time
(if not using NTP) in "one run of clicking the buttons" (without a 2
seconds long idle) that would mean setting system time once. In other
cases we update system time after each of those "runs" which, I believe,
won't be many times. Does this seem reasonable? If so, I'd like to push
those patches (properly squashed). Maybe I could add some
better-explaining comment to the code.
The other thing is that we should update the *HW clock* only when the
user gets after the "point of no return" so that it is preserved in case
that installation fails before this point (don't know how this was
handled in the old code).
--
Vratislav Podzimek
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
