<div dir="ltr">I've missed that, sorry. Can we discuss the code right in the
<a href="https://codereview.qt-project.org/#change,73340">https://codereview.qt-project.org/#change,73340</a> 's diff?<br></div><div class="gmail_extra"><br clear="all"><div>Regards,<br>Konstantin</div>
<br><br><div class="gmail_quote">2014/1/2 Mitch Curtis <span dir="ltr"><<a href="mailto:mitch.curtis@digia.com" target="_blank">mitch.curtis@digia.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 12/22/2013 05:51 AM, Konstantin Ritt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
During the testing, we've found a bunch of bugs and other issues. I'd<br>
suggest uploading this WIP branch to codereview, like we do for any<br>
other stuff.<br>
<br>
Regards,<br>
Konstantin<br>
</blockquote>
<br></div>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2013/12/21 Mark Gaiser <<a href="mailto:markg85@gmail.com" target="_blank">markg85@gmail.com</a> <mailto:<a href="mailto:markg85@gmail.com" target="_blank">markg85@gmail.com</a>>><div class="im"><br>
<br>
On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis <<a href="mailto:mitch.curtis@digia.com" target="_blank">mitch.curtis@digia.com</a><br></div><div class="im">
<mailto:<a href="mailto:mitch.curtis@digia.com" target="_blank">mitch.curtis@digia.com</a><u></u>>> wrote:<br>
> On 12/06/2013 03:08 PM, Mark Gaiser wrote:<br>
>><br></div>
>> On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis <<a href="mailto:mitch.curtis@digia.com" target="_blank">mitch.curtis@digia.com</a> <mailto:<a href="mailto:mitch.curtis@digia.com" target="_blank">mitch.curtis@digia.com</a><u></u>>><div>
<div class="h5"><br>
>> wrote:<br>
>>><br>
>>> Hello.<br>
>>><br>
>>> At the beginning of this year I started work on a Calendar for Qt Quick<br>
>>> Controls as a sort of side project. After removing the "WIP" from the<br>
>>> commit message, I got some feedback from developers who either a) had<br>
>>> also wrote a Calendar for KDE stuff or b) suggested I ask for feedback<br>
>>> from plasma-devel. Rather than add to the already massive list of patch<br>
>>> sets for that change, I thought it would be better to truly open up the<br>
>>> Calendar for contributions before it goes in by creating a WIP branch<br>
>>> for it in the Qt Quick Controls repo [1]:<br>
>>><br>
>>> wip/calendar<br>
>>><br>
>>> It'll be a throwaway branch, so every commit must be atomic and follow<br>
>>> all of the normal Qt commit policies [2][3]. At the end, we'll resubmit<br>
>>> every individual change to qtquickcontrols' dev branch.<br>
><br>
><br>
> I've been told that this is incorrect; the correct statement is:<br>
><br>
> "even though this is a throw-away branch (whose commits will be re-submitted<br>
> to dev individually), the usual policies should be followed"<br>
><br>
><br>
>>> Please feel free to submit patches or provide feedback on what's already<br>
>>> there. For example, it has already been suggested that there should be a<br>
>>> C++ backend for the models, dates, etc.<br>
>>><br>
>>> Cheers.<br>
>>><br>
>>> [1]<br>
>>><br>
>>><a href="https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a" target="_blank">https://qt.gitorious.org/<u></u>qt/qtquickcontrols/source/<u></u>4c3196c979d9a7f46b3f37b1414002<u></u>6dd74bf79a</a><br>
>>> [2]<a href="http://qt-project.org/wiki/Branch-Guidelines" target="_blank">http://qt-project.org/wiki/<u></u>Branch-Guidelines</a><br>
>>> [3]<a href="http://qt-project.org/wiki/Commit_Policy" target="_blank">http://qt-project.org/wiki/<u></u>Commit_Policy</a><br>
>><br>
>><br>
>> Hi Mitch,<br>
>><br>
>> It's awesome that you pull in the KDE plasma folks. I wonder who gave<br>
>> you that idea? ;)<br>
>><br>
>> Below is my "feature" list that i'd like to have in that calendar.<br>
>> Since i have some experience in that area i will try to help out as<br>
>> much as i can.<br>
>><br>
>> -- QML part --<br>
>> * Controls for the calendar grid<br>
>> * Controls for next/forward or just a few functions. This should at<br>
>> least have a nextMonth/previousMonth. Perhaps also nextYear and<br>
>> previousYear for convenience.<br>
>> * Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And<br>
>> the ability to change the name to shorter/longer variants.<br>
>> * Controls for the weeknumbers that are shown in the grid.<br>
>><br>
>> As far as i understand the QML code, all but the weeknumbers are in.<br>
><br>
><br>
> Yep.<br>
><br>
><br>
>> -- Locale --<br>
>> In KDE there was already an issue with differences between the<br>
>> JavaScript date object and the QDate object. I don't know the fine<br>
>> details here, someone else will probably fill that in i hope. I know<br>
>> there where issues, just not what exactly.<br>
><br>
><br>
> From the testing that I did with it [1], it has some differences when it's a<br>
> negative year, so the current implementation of the Calendar only allows<br>
> positive years, up to the year 275759; a significantly smaller range than<br>
> QDate [2].<br>
><br>
><br>
>> -- C++ part --<br>
>> This is the part where i really would like some feedback. I have a<br>
>> general idea of how it should be done, but i don't know the details or<br>
>> implications it might have.<br>
>> It is my hope that calendar controls like Mitch is proposing now will<br>
>> be extensive enough to simply swap the models to another backend.<br>
>> Akonadi comes to mind. However, there should obviously be a<br>
>> non-akonadi based version for default Qt usage.<br>
>><br>
>> My idea on that is as follows. Again, i don't know the implications of<br>
>> it or if it's really viable to take this route. Feedback is very much<br>
>> welcome here!<br>
>> The calendar model should be based on a new model that provides some<br>
>> default functionality and properties. I would say:<br>
>> QAbstractCalendarModel : public QAbstractListModel { ... }<br>
>> This model should provide the default - should be implemented -<br>
>> properties:<br>
>> * day -- INT number of the day in a current month<br>
>> * isCurrentMonth -- returns true for the current month (aka, the month<br>
>> you are viewing in the calendar). Returns false for the days before<br>
>> and after the currently viewing month. Based on the position in the<br>
>> grid you can then calculate if the entry where "isCurrentMonth"<br>
>> returns false is before or after the current month.<br>
>> * containsEvents -- true if the day contains events, false otherwise<br>
>><br>
>> "day" and "isCurrentMonth" should be convenience implemented in the<br>
>> QAbstractCalendarModel.<br>
>><br>
>> Next there should be a model for core Qt calendar usage. Or in other<br>
>> terms: no akonadi dependency.<br>
>> That would be a class like:<br>
>> QSimpleCalendarModel : public QAbstractCalendarModel { ... }<br>
>><br>
>> That class should probably have some basic storage in json files<br>
>> somewhere? Or ini or sqlite or..? Just something so that it can be<br>
>> used out of the box without any other requirements beyond Qt.<br>
>> Till this point is what would probably go in Qt. Everything after this<br>
>> line becomes Akonadi specific and should not be in Qt.<br>
>><br>
>> If a structure like the above is approved then Akonadi can be very<br>
>> easily used in KDE with the Qt calendar components.<br>
>> We'd just have to make out own QAbstractCalendarModel implementation<br>
>> that uses akonadi data. That would be a class like:<br>
>> (K)AconadiCalendarModel : public QAbstractCalendarModel { ... }<br>
>><br>
>> It can still use the base QAbstractCalendarModel implementation for<br>
>> it's grid stuff and re-implement the "containsEvents" property to be<br>
>> filled with data from akonadi.<br>
><br>
><br>
> As you may know, John Layt has some calendar stuff in the works for 5.3 [3].<br>
> It would be great to get his feedback, although I know he's quite busy.<br>
><br>
><br>
>><br>
>> Well, that's it for my idea thus far. I'm looking forward to some<br>
>> opinions on this.<br>
>><br>
><br>
> [1]<br>
><a href="https://codereview.qt-project.org/#patch,sidebyside,73340,1,src/controls/Private/qquickrangeddate.cpp" target="_blank">https://codereview.qt-<u></u>project.org/#patch,sidebyside,<u></u>73340,1,src/controls/Private/<u></u>qquickrangeddate.cpp</a><br>
> [2]<a href="http://doc-snapshot.qt-project.org/qt5-stable/qdate.html#details" target="_blank">http://doc-snapshot.qt-<u></u>project.org/qt5-stable/qdate.<u></u>html#details</a><br>
> [3]<a href="http://qt-project.org/wiki/Qt-5-ICU#955c0120c32f7991db7d55a94df808c2" target="_blank">http://qt-project.org/wiki/<u></u>Qt-5-ICU#<u></u>955c0120c32f7991db7d55a94df808<u></u>c2</a><br>
<br>
Bump.<br>
<br>
I hope some of the plasma folks can provide some feedback on the ideas<br>
proposed in this thread.<br>
______________________________<u></u>_________________<br>
Development mailing list<br></div></div>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a> <mailto:<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-<u></u>project.org</a>><br>
<a href="http://lists.qt-project.org/mailman/listinfo/development" target="_blank">http://lists.qt-project.org/<u></u>mailman/listinfo/development</a><br>
<br>
<br>
</blockquote>
</blockquote></div><br></div>