[Development] Qt Quick Controls Calendar

[Mark Gaiser]

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.
>
> 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.

-- 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.

-- 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.

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