> Ialso found KCalendarSystem is pretty > well designed but it's in kdelibs4support and I can't found the successor. > I also write down my thoughts here and feel free to check it out and let > me know what you think. (
To provide some background. KCalendarSystem was what we had, whilst Qt had nothing. Because Qt gained support, we dropped ours. >Yeah, and also, the QCalendar class doesn't come with chinese lunar calendar system support, so if subclassing QCalendarBackend (private API) is not acceptable Use of Qt private API in Plasma code is problematic. Undoubtedly, the best thing long term is to get it into Qt. You're right that it means a delay for users, but if we start talking short-term solutions first, we'll end up maintaining an entire new calendar framework forever. We can then revisit the Plasma side. It's a very different story to talk about use of private API or introducing extra layers if we know they will be temporary and are sure we can drop it in Plasma 6. >So I suggest we can create a plugin API to add alternate calendar support Creating a new library is one thing, the challenge is updating everything to use it. We can change things like the plasma clock popup easily, what's much harder is the wider world of applications formatting calendar strings if we're introducing things laer. David
