[Kde-pim] Implementation of KHolidays in Calendar

[Mark]

On Wed, Jul 31, 2013 at 11:25 AM, John Layt <john at layt.net> wrote:

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

I don't fully know that either, but heres as far as i understand it. Heena
has been tasked (or given herself the task?) to rewrite some plasmoids in
QML. The clock applet is one of them. There Heena has to have a calendar +
events which my components make very easy to do. I have absolutely no clue
if that's how it should be done for a port to QML and if it would be
accepted by the plasma folks at all.

As for using plasma DataEngines. Those only give you calendar events, no
full calendar or the structure of it anyway so just using the DataEngines
won't cut it.

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

I guess the change of that architecture is slowly going to depend on the
availability of akonadi stuff through actual QML components. Up till this
moment they had nothing to choose because there was nothing available, now
the QML Calendar Components are really beginning to take shape so it might
be interesting to discuss this again. Now those components still don't
provide the wealth of complexity that the kdepim apps provide, but editing
and adding events (in a simple manner) is certainly going to be possible.
(where editing already is)

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


Actually, i'd like to sit down with you and a few other PIM folks at the
next kdepim sprint (whenever that is) and make this happen - in code -
during that sprint. The brain power is certainly there during those days
and if the right people help we can probably hack a simple working version
within the sprint duration. What's your opinion on that?

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

That actually sounds better :) Yeah, i'm easily convinced ;)

>
> 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/
>
_______________________________________________
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/