[Development] Calendar Systems proposal

[Edward, Welbourne]

Hamed Masafi (30 January 2017 08:59):
> I'm working on qml support of calendar system,

That shall complement Soroush Rabiei's work on the C++ side:
https://codereview.qt-project.org/182341
http://bugreports.qt.io/browse/QTBUG-58404
Prior discussion:
http://lists.qt-project.org/pipermail/development/2016-December/028125.html
http://lists.qt-project.org/pipermail/development/2017-January/028234.html

> for porting this mechanism to qml we have two option:
>
> 1)
> Add a global object to jsengine?
> Somthing like that :
>
> var date = new Date;
> var cal = new JalaliCalendar;
> var out = date.toString(cal, "yyyy-MM-dd");
>
> In this case JalaliCalendar is a new global object type (like date,
> string, regex, array and etc).

If I understand Lars correctly, he prefers an API where the calendar
object carries methods that act on a date and any further arguments it
may need (similar to QLocale), so cal.toString(date, "yyyy-MM-dd") is
more likely (although I personally like the style of API you give above,
where the date object has the calendar-aware methods; too many of the
details are the same between calendar systems).  Aside from that, this
is roughly the shape the C++ API shall have, making it a natural model
for the QML to follow.

That C++ API is designed, however, with an eye on the long tail of less
widely used calendars - we aim to let their users be able to add a C++
class, possibly via a plugin, whose instances implement their calendar.
With this model for QML's API, that would require them to *also* add a
QML aspect of their C++ class.  I'm not sure how easy that is, or how
pluggable.

> 2)
> Or another option may be adding calendar() to global Qt function, the
> usage example can be like that:
>
> var date = new Date;
> var out = date.toString(Qt.calendar('jalali'), "yyyy-MM-dd");

This would require some infrastructure behind Qt.calendar() that would
let authors of calendar system classes register them so that it knows
how to instantiate them.  If that's easier than whatever it takes to add
a global object to QML (or an property of the Qt object), it might be a
good way to make life easier for calendar system implementors.

> ​3)
>
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd");
>
> In this method Qt.calendar like Qt.locale initialize with a string.

Not sure what you're proposing here - you don't mention Qt.calendar in
the code example, which looks more like 1) with JalaliCalendar moved to
the Qt object - which may indeed be a better place for it than as a
naked global object.

> Now question is that: witch form is preferred? Will be case (1) break
> Qt rules?

I don't know what rules QML might impose.  Each of these would, in one
way or another, require the calendar system code to register itself in
some way with QML, associated with the name by which QML is to refer to
it.  The details of whether that name is in the namespace of some
visible object (the ECMAScript global object or the Qt object) or in
some internal mapping (for 2) are a matter of what's practical or
convenient - someone with more QML fu than I can claim can advise you
better there.

	Eddy.