[Development] Qt Quick Controls Calendar

Sun Dec 22 12:41:12 UTC 2013

Please keep plasma-devel in cc.

On Sun, Dec 22, 2013 at 5:51 AM, Konstantin Ritt <ritt.ks at gmail.com> 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.

As far as i know that is the intention anyway.

Can you be more specific about the bugs?
Before we turn this into "bug reporting", i'd really like feedback on
the proposed ideas. I simply can't imagine that my suggestion is spot
on..

>
> Regards,
> Konstantin
>
>
> 2013/12/21 Mark Gaiser <markg85 at gmail.com>
>>
>> On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis <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>
>> >> 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
>> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>