Something I'm unsure about is the usage of std::vector in public API. We never really did that, but given Qt6 is ahead we might want to consider doing it from now on

I'd go for a QVector for now. Arguing with Qt6 doesn't sound convincing to me, since Qt6 will take another>=1 year(s). So why try this experiment in public API now? :)

Plan makes sense.

Thanks for working on this! Some general thoughts:

• Is KDeclarative is the right place for this? It's a module on the way out in KF6, it is hard to build for Android due to its dependency chain (which isn't even needed for this), while at the same time forcing ABI stability on this basically immediately without much chance for battle testing this.
• This currently represents a flat list of calendars, which matches Android IIRC, but not Akonadi (which treats calendars as folders and thus hierarchical). That might not be a problem as long as we treat Akonadi as a single calendar and don't expose the different backends on this level at all, but IIUC @dvratil was argueing to move away from that approach.

In D24443#543140, @vkrause wrote:

• Is KDeclarative is the right place for this? It's a module on the way out in KF6, it is hard to build for Android due to its dependency chain (which isn't even needed for this), while at the same time forcing ABI stability on this basically immediately without much chance for battle testing this.

Uh, where did I get the idea from that this is in KDeclarative? So that part of the comment is obviously nonsense. The concern about committing to ABI too quickly remains though.

• I would add name property to the CalendarEntry
• I would add color property to the CalendarEntry, so that calendar that is e.g. green in KOrganizer would show up green in the Plasma applet, too.

The Akonadi plugin for this will need to expose a list of multiple calendars, otherwise the user would only be able to toggle all-or-nothing, but not to toggle individual calendars. In Akonadi, we can have a tree of calendar folders, but realistically what you usually see is only the account folder with calendar subfolders, without any deeper nesting. I wonder if maybe we could have some system of "groups", so e.g. all different plugins that provide some holidays calendars would make the calendars members of "holidays" group, the Akonadi calendars could be groupped by the account name they belong to...this could be then shown nicely in the (QML) UI.