[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] KO & date box not updating at midnight
From:       Adriaan de Groot <adridg () cs ! kun ! nl>
Date:       2002-09-20 9:35:11
[Download RAW message or body]

On Friday 20 September 2002 10:08, Guenter Schwann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 01 October 2002 02:03, Adriaan de Groot wrote:
> > Whatever I committed this afternoon looked convincing to me, but really
> > wasn't. I've been working on a more definitive fix, which ends up in
> > KDateNavigator and extends that class with signals dayPassed(QDate) and
> > monthPassed(QDate) just in case you want to be watching that. I
>
> I thought to have this fixed already...
> Have a look at korganizer/calandar.cpp line 217-224

Aha. I would have expected the bug to have been closed then. I get the feeling 
bugzilla updates very very slowly wrt. the status of bugs.

<grump mode on>
I can see two technical and one design problem with your approach, though:

- Very long timer intervals (we're talking up to 86000000 msec here) are 
suceptible to clock drift, pauses, whatnot. Phalynx convinced me on IRC that 
having a timer go off every ten minutes or so was not a large overhead and 
considerably more accurate.

- You calculate the interval _once_, in the constructor of the CalendarView 
object. Then you single-shot the timer, which means that only one midnight 
crossing is detected. In cases of very long idle time with mutiple rollovers 
this isn going to work either.

[Gosh, I just stumbled across CalendarView::setupRollover() with a comment in 
it that it doesn't work properly, but that's apparently yet another attempt 
at fixing this bug. So now there are two fixes at the CalendarView level and 
one at the DateNavigator level.]

- My non-technical point goes like this: it about code reuse. I think that the 
KDateNavigator class is more reusible than a whole CalendarView. I don't know 
if it's actually reused anywhere -- and it's obviously different from the 
KDatePicker widget used in KControl->Date&Time -- but it could be. Probably 
anything displaying a date navigator will want a rollover mechanism as well. 
So implementing rollover in the CalendarView is too high-level. You want to 
be able to _detect_ rollovers at the CalendarView level -- for example 
because the DateNavigator emits a signal so you can adjust the view 
accordingly -- but programming it at that level means it'll have to happen 
all over again in other applications reusing KDateNavigator.

As behooves the father of the code, I think my solution is better because it 
solves multi-day and monthly rollovers, you can use

	connect(mDateNavigator,SIGNAL(dayPassed(QDate)),
		this,SLOT(updateView())) 

to get the behavior setup by both setupRollover() and lines 217ff, and it's 
more reusable. However, I realise that the current implementation has its 
weaknesses:

- You _always_ get the advance-today behavior. There's no way to turn it off. 
I think adding a enableRollover(bool) method to KDateNavigator to setup the 
timer is the thing to do here. Just delete the timer if rollover is disabled. 
No timer, no call to the possiblyPastMidnight() slot.

- It might be hard to connect the dayPassed() or monthPassed() signals to a 
higher-level app in a sensible way. Actually, I see that 
CalendarView::updateView() uses mDateNavigator->selectedDates() to find out 
what to display, and the only time the selection changes due to dayPassed() 
is when the month changes too (since I choose to display the next month 
then). In such a case, updateView() would suddenly change the viewed date 
from, say, sept. 20th to oct. 14th, since the selected chunk of the month 
stays the same while the month changes "out from under it".

- Clicking next month or previous month gives me pretty much random selections 
and dates highlighted asif they are "today". I don't _think_ that's my fault, 
but I'll look into it. I hope I didn't mangle KODayMatrix::updateView() too 
badly.




-- 
http://freebsd.kde.org/
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]