On 12/06/2013 03:08 PM, Mark Gaiser wrote:
On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis <mitch.cur...@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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to