[Development] Qt Quick Controls Calendar

Mitch Curtis mitch.curtis at digia.com
Fri Jan 3 10:34:58 UTC 2014


On 01/02/2014 11:41 PM, Konstantin Ritt wrote:
> I've missed that, sorry. Can we discuss the code right in the
> https://codereview.qt-project.org/#change,73340 's diff?
>
> Regards,
> Konstantin

Sure.

>
> 2014/1/2 Mitch Curtis <mitch.curtis at digia.com
> <mailto: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> <mailto: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>
>              <mailto: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>
>         <mailto: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/__4c3196c979d9a7f46b3f37b1414002__6dd74bf79a <https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a>
>              >>> [2]http://qt-project.org/wiki/__Branch-Guidelines
>         <http://qt-project.org/wiki/Branch-Guidelines>
>              >>> [3]http://qt-project.org/wiki/__Commit_Policy
>         <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 <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
>         <http://doc-snapshot.qt-project.org/qt5-stable/qdate.html#details>
>              >
>         [3]http://qt-project.org/wiki/__Qt-5-ICU#__955c0120c32f7991db7d55a94df808__c2
>         <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>
>         <mailto:Development at qt-__project.org
>         <mailto:Development at qt-project.org>>
>         http://lists.qt-project.org/__mailman/listinfo/development
>         <http://lists.qt-project.org/mailman/listinfo/development>
>
>
>


More information about the Plasma-devel mailing list