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