[Development] Qt Quick Controls Calendar

[Mitch Curtis]

On 12/06/2013 03:08 PM, Mark Gaiser wrote:
> On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis <mitch.curtis at digia.com> wrote:
>> Hello.
>>
>> At the beginning of this year I started work on a Calendar for Qt Quick
>> Controls as a sort of side project. After removing the "WIP" from the
>> commit message, I got some feedback from developers who either a) had
>> also wrote a Calendar for KDE stuff or b) suggested I ask for feedback
>> from plasma-devel. Rather than add to the already massive list of patch
>> sets for that change, I thought it would be better to truly open up the
>> Calendar for contributions before it goes in by creating a WIP branch
>> for it in the Qt Quick Controls repo [1]:
>>
>> wip/calendar
>>
>> It'll be a throwaway branch, so every commit must be atomic and follow
>> all of the normal Qt commit policies [2][3]. At the end, we'll resubmit
>> every individual change to qtquickcontrols' dev branch.

I've been told that this is incorrect; the correct statement is:

"even though this is a throw-away branch (whose commits will be 
re-submitted to dev individually), the usual policies should be followed"

>> Please feel free to submit patches or provide feedback on what's already
>> there. For example, it has already been suggested that there should be a
>> C++ backend for the models, dates, etc.
>>
>> Cheers.
>>
>> [1]
>> https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a
>> [2] http://qt-project.org/wiki/Branch-Guidelines
>> [3] http://qt-project.org/wiki/Commit_Policy
>
> Hi Mitch,
>
> It's awesome that you pull in the KDE plasma folks. I wonder who gave
> you that idea? ;)
>
> Below is my "feature" list that i'd like to have in that calendar.
> Since i have some experience in that area i will try to help out as
> much as i can.
>
> -- QML part --
> * Controls for the calendar grid
> * Controls for next/forward or just a few functions. This should at
> least have a nextMonth/previousMonth. Perhaps also nextYear and
> previousYear for convenience.
> * Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
> the ability to change the name to shorter/longer variants.
> * Controls for the weeknumbers that are shown in the grid.
>
> As far as i understand the QML code, all but the weeknumbers are in.

Yep.

> -- Locale --
> In KDE there was already an issue with differences between the
> JavaScript date object and the QDate object. I don't know the fine
> details here, someone else will probably fill that in i hope. I know
> there where issues, just not what exactly.

 From the testing that I did with it [1], it has some differences when 
it's a negative year, so the current implementation of the Calendar only 
allows positive years, up to the year 275759; a significantly smaller 
range than QDate [2].

> -- C++ part --
> This is the part where i really would like some feedback. I have a
> general idea of how it should be done, but i don't know the details or
> implications it might have.
> It is my hope that calendar controls like Mitch is proposing now will
> be extensive enough to simply swap the models to another backend.
> Akonadi comes to mind. However, there should obviously be a
> non-akonadi based version for default Qt usage.
>
> My idea on that is as follows. Again, i don't know the implications of
> it or if it's really viable to take this route. Feedback is very much
> welcome here!
> The calendar model should be based on a new model that provides some
> default functionality and properties. I would say:
> QAbstractCalendarModel : public QAbstractListModel { ... }
> This model should provide the default - should be implemented - properties:
> * day -- INT number of the day in a current month
> * isCurrentMonth -- returns true for the current month (aka, the month
> you are viewing in the calendar). Returns false for the days before
> and after the currently viewing month. Based on the position in the
> grid you can then calculate if the entry where "isCurrentMonth"
> returns false is before or after the current month.
> * containsEvents -- true if the day contains events, false otherwise
>
> "day" and "isCurrentMonth" should be convenience implemented in the
> QAbstractCalendarModel.
>
> Next there should be a model for core Qt calendar usage. Or in other
> terms: no akonadi dependency.
> That would be a class like:
> QSimpleCalendarModel : public QAbstractCalendarModel { ... }
>
> That class should probably have some basic storage in json files
> somewhere? Or ini or sqlite or..? Just something so that it can be
> used out of the box without any other requirements beyond Qt.
> Till this point is what would probably go in Qt. Everything after this
> line becomes Akonadi specific and should not be in Qt.
>
> If a structure like the above is approved then Akonadi can be very
> easily used in KDE with the Qt calendar components.
> We'd just have to make out own QAbstractCalendarModel implementation
> that uses akonadi data. That would be a class like:
> (K)AconadiCalendarModel : public QAbstractCalendarModel { ... }
>
> It can still use the base QAbstractCalendarModel implementation for
> it's grid stuff and re-implement the "containsEvents" property to be
> filled with data from akonadi.

As you may know, John Layt has some calendar stuff in the works for 5.3 
[3]. It would be great to get his feedback, although I know he's quite busy.

>
> Well, that's it for my idea thus far. I'm looking forward to some
> opinions on this.
>

[1] 
https://codereview.qt-project.org/#patch,sidebyside,73340,1,src/controls/Private/qquickrangeddate.cpp
[2] http://doc-snapshot.qt-project.org/qt5-stable/qdate.html#details
[3] http://qt-project.org/wiki/Qt-5-ICU#955c0120c32f7991db7d55a94df808c2