Undoubtedly, the best thing long term is to get it into Qt.
Totally agree :)
but if we start talking short-term solutions first, we'll end up maintaining an entire new calendar framework forever.
Actually we might not need an entire new framework dedicated to calendar system, since adding *alternate calendar* feature support only requires a sub part of features from a calendar system, only very few APIs will be needed for an *alternate calendar* plugin system. There are some difference between a dedicated calendar system API (QCalendar, KCalendarSystem, etc) and an alternate calendar plugin system. The calendar system API might dedicated on date calculating and also provides some other generic information about the calendar system, and the alternate calendar plugin system will take care about what to display if the main calendar system is A and alternate calendar system is B. Also there are something missing from QCalendar, for example it seems we are not able to know if the current month is a leap month, and QCalendar also didn't provide a way to get the localized day name (e.g. 2nd day of a month names "初二" in lunar calendar). I guess maybe I can discuss these on the Qt devel mailing list?
Creating a new library is one thing, the challenge is updating everything to use it.
Currently most project with a calendar view doesn't comes with alternate calendar display support, so I guess whatever we made a library for this need or extending QCalendar to make it also suitable for this need, we still need those project to work on the support of alternate calendar display feature. I'm not sure about which way is better, creating another library as a QCalendar alternative is clearly not the best way to do, so I guess a plugin system for alternate calendar feature would be okay. --------------- I guess I could also provide some use case about how alternate calendar feature will be like: 1.The month view will still shows the same layout as its used to be, using the main calendar system's weekday preferences and etc. 2.The alternate calendar system's day name will be displayed near the main calendar's day name/number. The name of the day would be a localized string. As mentioned above, the second day of a month in Chinese lunar calendar will be display as "初二" instead of a number "2". 3.Since the month view is depends on the main calendar system, user will need to know the related month name in alternate calendar system. The first day of the alternate calendar month will display the month name in the alternate calendar day name grid. 4.If there are holiday/festival event, the alternate calendar day name can display a festival event name instead of alternate calendar day name, for example it will display "圣诞节" ( Christmas) instead of "十一"(it's the localized string of the 11th day of the month in Chinese lunar calendar. In 12/25/2020). 5.For a feature-rich calendar application, it can display more detailed calendar information from the app, like the localized year name, month and day name. For the first one, we don't need to do any thing. For the 2nd one, it will require the calendar view be able to display text for alternate calendar day names. It will also requires the calendar system API be able to get the localized name of the day in the choosen alternate calendar system. (QCalendar doesn't support it right now). For the 5th one, I guess QCalendar can already handle this need. The 3rd and 4th one could be a part of the logic in a generic alternate calendar support implementation, but I'm not sure if it's really the generate way to display alternate calendar date other than Chinese lunar calendar. If it isn't, I guess that's what the alternate calendar plugin system should take care of.
