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