> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
