Soroush Rabiei > Sorry for being noisy on this list, but I think we have several issues > needed discussion before going further.
I should note that Lars still holds to the view that we should keep this out of QDate: which seems to imply roughly just upstreaming KCalendarSystem, albeit with the opportunity to make any improvements we want in the process. > First we have a design decision to make, the minimal set of > assumptions on calendaring systems. According to my minute research we > can assume following facts on every calendar that is in-use: > > 1. All calendaring systems, show dates in three levels: Year, Month and Day > 2. The week is 7 days. It may start at any of these days. French revolutionary calendar: https://en.wikipedia.org/wiki/French_Republican_Calendar Not that I propose supporting it ! However, it would be best to design a system which doesn't preclude someone else implementing it. If we can avoid hard-coding the assumption of a seven-day week, so much the better. > 3. Number of months in all years are fixed. Is there no lunar calendar with occasional extra months ? > Please let me know about any problem. > > Second issue is on CLDR data. I was all mistaken about CLDR. The new > versions (including v29) include month name data for many calendars > (Gregorian, Buddhist, Chinese, Coptic, Dangi, Ethiopic, Hebrew, > Indian, Islamic, Japanese and Persian). I managed to modify the > scripts (cldr2qlocalexml.py and qlocalexml2cpp.py) to prepare data for > Jalali calendar (named as Persian in CLDR terminology). On the other > hand, QLocale integration is completed. Now there is `months_data_per' > array in qlocale_data_p.h and it's working well. > > The problem however, is that this data is bigger than what I had in > mind. Apparently there are many communities using Jalali calendars. > There are strange month names for Korean, Russian, Turkish and several > more. (I was expecting data only for Persian and Afghani languages, > maybe Tajik too...) The array containing month names is 2419 bytes. > There is also another 6*2=12 bytes per locale in locale's index table. > considering number of supported locales in qt, we will have 552 * 12 = > 6624 bytes there and as a result the overhead in Qt's binary, will be > 9.043 KB only for Jalali calendar. Islamic civil calendar is almost > three times bigger if I'm not much mistaken, and I have no idea about > other calendars. I guess adding five calendars will blow QtCore up to > 5~7 Megabytes. Not something we want to impose on all users of Qt. > I have changed qlocalexml2cpp.py such that it generates data for each > calendar in a separate array. So it can be excluded by preprocessor > directives. My suggestion is to make calendaring support, > configurable, and provide data only for Gregorian calendar by default. > And also we can give users the option to choose among locales they > want to include in their builds: > > ./configure -developer-build -opensource -confirm-license -debug > -calendars gregorian,persian,islamic_civil That sounds reasonable. Another approach might be to design a plugin-based architecture - with similar config, but controlling which plugins get built. This would make life easier for anyone who wants to add a calendar system we don't support: they'd just need to add their plugin to wherever we put ours. Eddy. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development