[Development] Qt Quick Controls Calendar

[Martin Klapetek]

On Fri, Dec 6, 2013 at 3:08 PM, Mark Gaiser <markg85 at gmail.com> wrote:

>
> 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.
>

nextMonth/prevMonth totally agreed. For years, that depends on the UI imho,
so that the header is not too cluttered with different arrows. I can
imagine a fading up/down arrows above/below the year, not sure how much
would that work in practice though...


> * Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
> the ability to change the name to shorter/longer variants.
>

What would be the usecase for longer variants? Full screen/huuge calendars
I assume? Here's an important question imho - should the days be
capitalized or not? Qt's locale follows, well, the locale and for example
the Czech weekday names are not capitalized because we do not capitalize
them, like for example Friday in English is. However, when it's put
standalone, I think it should always be capitalized. It simply looks better.


> * Controls for the weeknumbers that are shown in the grid.
>

Optional with default off. But if the visual side is made good enough
looking, it might work. But in 76% of times you don't need to know the week
number, then it just clutters the grid.


> As far as i understand the QML code, all but the weeknumbers are in.
>

Yup, but it's made as one single component (for consumers) iirc.


> -- 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.
>

I already posted it before, but for the sake of completeness, QDate starts
weekdays and months with 1 while JS Date object starts both with 0, so eg.
QDate weekday value 7 is Sunday while JS Date would give you "undefined"
for 7.


> -- 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
>

You mean like 31, 28 etc? Or what would this property be for? The selected
day? Then let's name it properly.


> * 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.
>

"isCurrentMonth" implicates "is this the month that currently really is",
eg. QString("January").isCurrentMonth() = true;. If it's supposed to be the
month currently in the view, let's name it "isCurrentlyDisplayedMonth" or
something.


> * containsEvents -- true if the day contains events, false otherwise
>

How would one then retrieve the events for the given day? Also, wouldn't it
be better to have a model role returning this?


>
> "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.
>

What would it store? I mean what events would be in the simple calendar? If
you want that to be a base class for other people implementing calendar
events backend, I think the Abstract class is enough? Or is that meant just
as an basic example? Then it can go to qt's examples and use whatever is
the easiest. Imho.


> 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.


How would that be filled with data if it returns boolean? I mean, what do
you want to fill where? :)


Overall I like the real model backend, however I think your proposal also
could use definition of roles for the model and what would be returned for
those roles (what comes to mind is single vs. multiple events in one day,
would it always return a list or a string in one case and list in other
case...etc).

Cheers
-- 
Martin Klapetek | KDE Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140107/5fc2c0d5/attachment.html>