'Re: [Development] Qt Quick Controls Calendar'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [Development] Qt Quick Controls Calendar
From:       Mitch Curtis <mitch.curtis () digia ! com>
Date:       2014-01-03 10:34:58
Message-ID: 52C69252.6020006 () digia ! com
[Download RAW message or body]

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.curtis@digia.com
> <mailto:mitch.curtis@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 <markg85@gmail.com
> <mailto:markg85@gmail.com> <mailto:markg85@gmail.com
> <mailto:markg85@gmail.com>>>
> 
> 
> On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis
> <mitch.curtis@digia.com <mailto:mitch.curtis@digia.com>
> <mailto:mitch.curtis@digia.com
> <mailto:mitch.curtis@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.curtis@digia.com <mailto:mitch.curtis@digia.com>
> <mailto:mitch.curtis@digia.com <mailto:mitch.curtis@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
> Development@qt-project.org <mailto:Development@qt-project.org>
> <mailto:Development@qt-__project.org
> <mailto:Development@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

[prev in list] [next in list] [prev in thread] [next in thread] 