[Development] Qt Quick Controls Calendar

Konstantin Ritt ritt.ks at gmail.com
Thu Jan 2 22:41:05 UTC 2014


I've missed that, sorry. Can we discuss the code right in the
https://codereview.qt-project.org/#change,73340 's diff?

Regards,
Konstantin


2014/1/2 Mitch Curtis <mitch.curtis at digia.com>

> On 12/22/2013 05:51 AM, Konstantin Ritt wrote:
>
>> During the testing, we've found a bunch of bugs and other issues. I'd
>> suggest uploading this WIP branch to codereview, like we do for any
>> other stuff.
>>
>> Regards,
>> Konstantin
>>
>
> It has been on gerrit in a WIP branch since I sent the email you replied
> to; it's all there in the original email.
>
>
>> 2013/12/21 Mark Gaiser <markg85 at gmail.com <mailto:markg85 at gmail.com>>
>>
>>
>>     On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis <mitch.curtis at digia.com
>>     <mailto:mitch.curtis at digia.com>> wrote:
>>     > 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 <mailto: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
>>
>>     Bump.
>>
>>     I hope some of the plasma folks can provide some feedback on the ideas
>>     proposed in this thread.
>>     _______________________________________________
>>     Development mailing list
>>     Development at qt-project.org <mailto:Development at qt-project.org>
>>     http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140103/1b826be9/attachment-0001.html>


More information about the Plasma-devel mailing list