[Development] Calendar Systems proposal

[Hamed Masafi]

> That shall complement Soroush Rabiei's work on the C++ side:
Yes, that's right. I'm trying to port Soroush's calendar mechanism to qml
side of Qt.

> 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.
I'm not sure we can add an global type to script engine that are not in
ecma script.

> 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.
No; in this case Qt.JalaliCalendar is a QEnum and not an object (my
suggestion explained below)

> 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.
My prefer option is form (3)
We can add an enumeration to global space.
var date = new Date;
var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd");

> Have you considered whether Date.prototype.toLocaleDateString could be
> of use for this? See:
>
http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring
Date.prototype.toLocaleDateString is used to converting date to a string
bases on a Locale. we can use this function for accepting an CalendarType
(CalendarType is a QEnum that contains list of calendar types like;
gregorian, jalali, hindi or etc)
date.toLocaleString(format);
date.toLocaleString(CalendarType, format);
date.toLocaleString(locale, format);
date.toLocaleString(CalendarType, locale, format);

But there are some bugs related to this prototype, We have to solve that
within this process.
https://bugreports.qt.io/browse/QTBUG-32492
https://bugreports.qt.io/browse/QTBUG-41712

> var out = date.toString("yyyy/MM/dd", Qt.JalaliCalendar); // Is
> this possible?
This is my choice too. And answer is "yes". This is possible. But for that
we must conclusion below paragraph [*]:

> There are differences between those concepts that are implemented as
> plugins and calendars. A calendar system is not an image format nor a
> database implementation. There will be no new calendar (at least, it's
> unlikely to have a brand new calendar) and there will be no newer
> versions of existing calendars. What is the point of having calendars
> as plugins? And we have to keep QGregorianCalendar everywhere after
> all... And we will have the problem of instantiation. While plugins
> have no public header, then how we are supposed to use them in code?
> Like this:
[*]: I'm agree with Soroush. Calendar system must bot be pluginable. Due
the facts that soroush said.

I think to continue we must conclusion on that calendar types must be
plugin or not?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170130/3375dc31/attachment.html>