> On May 23, 2014, 6: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 :)
> 
> Mark Gaiser wrote:
>     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.

> So the dataengine fires a timer every 30 seconds.. that is 86400 (seconds in 
> a day) / 30 = 2880 timer fires for what exactly?

To update your clock applet every minute ;)


- Martin


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


On May 23, 2014, 5: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, 5: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
> 
>

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to