On 12/06/2013 03:08 PM, Mark Gaiser wrote: > On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
