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.cur...@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 <mark...@gmail.com <mailto:mark...@gmail.com>> >> >> >> On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis <mitch.cur...@digia.com >> <mailto:mitch.cur...@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.cur...@digia.com <mailto:mitch.cur...@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 >> developm...@qt-project.org <mailto:developm...@qt-project.org> >> http://lists.qt-project.org/mailman/listinfo/development >> >> >>
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
