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 <mitch.cur...@digia.com
<mailto: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> <mailto: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>
<mailto: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>
<mailto: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/__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
developm...@qt-project.org <mailto:developm...@qt-project.org>
<mailto:Development@qt-__project.org
<mailto:developm...@qt-project.org>>
http://lists.qt-project.org/__mailman/listinfo/development
<http://lists.qt-project.org/mailman/listinfo/development>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
