> 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?
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
