[Kde-pim] Implementation of KHolidays in Calendar

[John Layt]

On Monday 29 Jul 2013 22:51:00 Mark wrote:
> Hi john,
> 
> you're talking about the current way to use KHolidays in plasmoids, but
> that's not what this is about. The project Heena is doing is re-creating
> the calendar popup in QML. For that she needs to use my components that
> expose calendar events in QML through a few special QML components (the
> ones we worked on during the last KDEPIM meeting).
> 
> As we also discussed back then, it would be ideal if KHolidays could also
> be fetched from Akonadi as a special type of calendar events perhaps. That
> is exactly what this stuff is about and how it should be implemented.
> 
> I think those events should just be returned by akonadi when events are
> fetched. Calendar events should probably just be part of the event stream.
> 
> But that's what this is about. I don't know akonadi well enough to know how
> this should be implemented so i hope you folks could discuss this and give
> your view on how to best implement this.
> 
> Big note: Only rewriting the calendar popup in a feature parity manner is
> already big enough for a GSoC project, adding in KHolidays is probably also
> big enough for a GSoC project so i'm not really sure if it's fair to let
> Heena do all of this. It might be simply too much for one GSoC.
> 
> Note 2: about your top 1 feature request for adding/editing calendar
> events. The editing part just became possible in my components about 2 days
> ago. Thus far it can only edit the summary and description, but the heavy
> work is done. The rest is simply exposing functions and properties.

Hi Mark,

I'm still not clear on exactly what Heena's project is here, is she writing 
QML Plasmoids for use in Plasma, or is she writing QML Components for general 
use in KDEPIM and othe places?  If Heena is recreating the official Plasma 
Calendar with the same functionality, using Plasma classes, which lives in 
Plasma and is only used by Plasma, then surely she should be using the official 
Plasma way of accessing data, i.e. the DataEngines?  If the intention is to 
use it as a generic QML componant in places like KDEPIM then that's a different 
story and it shouldn't be called a Plasmoid or use Plasma classes or resources 
or be living in Plasma.

This is a very old discussion we've had with the Plasma guys a few times: 
where to draw the line between Plasma and Akonadi and KDEPIM, and between KDE 
Widgets and Plasma Widgets in general.  The concensus has been for the 
Plasmoids to provide a basic level of functionality via the DataEngines which 
wrap Akonadi.  More advanced functions require duplicating too much api and 
widgets (like the recurrence editor) that the Plasma guys don't want to do and 
are unlikely to get right.  For advanced features that's what the main KDEPIM 
apps and widgets are for.  If that architecture is being changed then that's 
something we need to discuss again.

As we discussed at the sprint the plan is to make KHolidays an Akonadi 
resource, but this was part of the plan for KHolidays2 in KDEPIM 5 which 
includes a new file format, a new generic low-level library with a new api, and 
the Akonadi resource.  That's an entire GSoC project in it's own right.  Heena 
could use the existing library to write an Akonadi resource, but I'm not sure 
how much work is involved.  Volker could probably comment on that.  See the 
tutorial at http://techbase.kde.org/Development/Tutorials/Akonadi/Resources

There's good reasons for having the holidays as a separate Akonadi resource 
with separate collections per holiday file, rather than just included with the 
standard events resource. Mostly it allows the user flexability in choosing 
what holiday regions to display per plasmoid, instead of it being fixed by 
whereever the events have been configured.

Cheers!

John.

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/