Review Request 118277: [1/2] Make sure we update the calendar on date change

[Mark Gaiser]

> On May 23, 2014, 4:02 p.m., Mark Gaiser wrote:
> > Hi Martin,
> > 
> > I would like to suggest a different approach.
> > 
> > 1. You want to know the current day (which the model and calendar component don't expose).
> > 2. You want the daysModel data to update when the clock ticks over 12.00 PM into the next day.
> > 
> > My suggestion for 1 is the following:
> > Expose the _index_ from the daysData model that represents the current day. Note, that index is almost always going to be higher then "today" in the current month. So May 23 will not return 23 due to the last 4 days of april also being in the model. This differs per month obviously so your return index should be <daynumber> + n of last month where n = 4 in this case.
> > 
> > My suggestion for 2 is the following:
> > Upon Calendar constructing start a timer (in the C++ side) to update the model at midnight. The timer should then call Calendar::updateData which will update everything.
> > 
> > What are your thoughts on this?
> 
> Mark Gaiser wrote:
>     Added note: I can implement it to the C++ side if you want.
> 
> Martin Klapetek wrote:
>     Thanks for the suggestions
>     
>     I specifically didn't want to add a timer as there's already a dataengine providing the current date and that's being updated every 30 secs, so adding another timer is just a waste. However this solution is general enough that if you reuse this component, you can replace the dataengine with a timer.
>     
>     As for exposing index...well, the approach I took here seems more simple and obvious...I'm not sure I want to mess with indexes and do unnecessary computations. We already have a property that's being updated (the dataengine's ["Date"]) and all we need is to hook the rest to it. Which is precisely what I did here :)

It would be my suggestion to remove the dataengine from this code path and let everything be contained in the Calendar component :)

So the dataengine fires a timer every 30 seconds.. that is 86400 (seconds in a day) / 30 = 2880 timer fires for what exactly? Against just 1 when done in the Calendar c++ side :)

It's your call. If you want to get rid of the dataengine then i will implement those two suggestions for you. Otherwise ship this review request.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118277/#review58362
-----------------------------------------------------------


On May 23, 2014, 3:22 p.m., Martin Klapetek wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118277/
> -----------------------------------------------------------
> 
> (Updated May 23, 2014, 3:22 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> -------
> 
> This is the first part of a fix for updating the calendar properly when date changes (after midnight).
> 
> It introduces new property on MonthView - "today". This property is updated by dataengine (or can be a timer too, but we already get signals from dataengine every 30 seconds) and is never updated by the code itself. Furthermore, the DayDelegate is now bound to it, so when "today" changes, the selection rectangle in the calendar should also change. And finally, the selected item in the grid is cleared if MonthView's date property is cleared (which is second part of this patch, to the applet itself).
> 
> 
> Diffs
> -----
> 
>   src/declarativeimports/calendar/qml/DayDelegate.qml 552769c 
>   src/declarativeimports/calendar/qml/DaysCalendar.qml 6054a9d 
>   src/declarativeimports/calendar/qml/MonthView.qml e064f01 
> 
> Diff: https://git.reviewboard.kde.org/r/118277/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140523/7be1e8af/attachment.html>