Adding non-date-aligned computable mass events to calendars (le.g. astronomical events)

Friedrich W. H. Kossebau kossebau at kde.org
Wed Jul 28 18:26:33 BST 2021


Hi,

I would like to implement what is needed to have the option to see 
environmental/astronomical events (as useful for outdoor activities of all 
kinds, but also infotainment) directly in calendar views. E.g.
* sunrise/sunset
* moon phases
* sun/moon eclipses
* other artificial and natural sky objects events (satellites, asteroids, 
planets, ...)
* (weather forecast, but that is a different challenge, with less but dynamic 
data, to be discussed separately once I work on it)


How do I do an Akonadi resource providing such astronomical event data?


MOTIVATION

Right now e.g. lunar phase events are added as frontend-specific addons only:
* Plasma calendar applet: custom extension, injects moon phase events as
  calendar entries -> https://phabricator.kde.org/D12433
* KOrganizer decoration plugin (revival up as MR now)
  -> https://invent.kde.org/pim/kdepim-addons/-/merge_requests/12

So e.g. Calindori, Kalencar or any other front-end again has to have their 
custom add-ons again, both for injecting the data into the data model as well 
as for any custom data-specific display.

I would imagine it makes sense to provide such events in a generic way via 
Akonadi to any calendaring UI instead. Because usually if one has interest in 
such events (and their effects, like natural brightness) for planning related 
activity events that information is wanted everywhere, if only as context or 
reference.

And while certain event data surely benefits from custom display, having data 
provider and frontend rendering decoupled opens the option for more 
reusability (e.g. render type for sunrise/sunset events could be reused for 
other types of events where same display, e.g. a fine line, is useful as well 
or switching data backends when suited without the need to adapt the 
rendering, think someone doing a kstars-engine-powered super-backend).


QUESTIONS

I have little if any clue of Akonadi currently. 

With that, i guessed I would do a resource for lunar phases for the start. And 
later one for sunrise & sunset. And then see what else I fancy at the time. 
People could then add that resource with respective config (e.g. hemisphere/
location) to their calendar view. And later there could be plugins to give 
those events some special UI/rendering, instead of showing just a "normal" 
event. Like contact birthdays are also fed as events through Akonadi and get 
some special UI.

For now I created a new resource project from the Akonadi resource template. 
But when starting to look into the API of Akonadi::ResourceBase to 
reimplement, I have no idea yet how to map the mass event data representing 
e.g. lunar phases, which could be any dates where the computation algorithm is 
valid in past & future, onto the data structures and method calls.
For what I understand I feed items of type KCalendarCore::Event best, as this 
is the data type KOrganizer & other calendaring front-ends use when 
unmarshalling data from Akonadi. I see that KCalendarCore::Event has a concept 
of recurrency, but that one seems to only operate in non-fractional multiples 
of date units? I would guess that having more complex recurrence calculation 
also need a way to be expressed, so the formula can be passed on to consumers 
and processed by them, and most human-oriented use cases do not need that, so 
it is not supported/part of design.
At the same time Akonadi expects that the number of items in a collection is 
known and available in one set, right? At least a method to implement like 
Akonadi::ResourceBase::retrieveItems(const Akonadi::Collection&  collection) 
suggest that one should be always able to unconditionally deliver all items. 
Which obviously is nothing we want to do for any lunar phase events in the 
past and future ;)

So, how could one express events which are part of a insanely big number 
(exact number could be estimated by first/last date supported by backend) and 
ideally are only calculated on the fly for windows/views of interest or other 
filter types (like a certain time span)? Is that a concept supported by 
Akonadi in some way? What might be a good similar sample to look at (only saw 
the kdepim-runtime ones for now, which were less similar)? 

Cheers
Friedrich




More information about the kde-pim mailing list