Alternate calendar in plasma - feature request discussion

[Gary Wang]

> 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.