Review Request 125817: Add plugin system for Calendar events

[Martin Klapetek]

> On Oct. 28, 2015, 10:15 a.m., Marco Martin wrote:
> > not much a fan of adding a public library there, but i guess there aren't many other ways. Could it be put into plasma-workspace instead?
> 
> Daniel Vrátil wrote:
>     Please don't, unless you want to have Akonadi dependency in plasma-workspace. This way we in KDE PIM can provide our own plugin, because having a dependency on plasma-framework is not a big problem for us (unlike having a PIM dependency in plasma-workspace I imagine).
> 
> Luca Beltrame wrote:
>     +1 to what Dan said. As a contributor and a packager: plase *don't* have things depend on workspace. It was a mess already in 4.x times, and caused all sorts of headaches down the way.
> 
> Marco Martin wrote:
>     the idea was that akonadi plugin would have resided in workspace as well (i think an akonadi dependency in plasma-workspace is fine, like an akonadi-integration under workspace/)
>     If that can't be done, ok for adding it in plasma-framework(i would already prefer a separed framework on its own tough), I'm just very very stingy in adding new and forever frozen symbols, especially frozen since its first release
> 
> Daniel Vrátil wrote:
>     Note that we don't have any PIM frameworks yet, so you would create Plasma -> Applications dependency. At this point it's easier for PIM team to maintain PIM integration stuff in PIM repositories.
>     
>     Since the only two users at the beginning will be the Holiday plugin and PIM, I think that marking the library as "experimental" without and ABI/API guarantees is perfectly fine for the first X releases, and once we see that it works well for both, it can be moved to "stable".
> 
> Martin Gräßlin wrote:
>     Overall that sounds like we need a weird repo somewhere in between which can depend on both the workspace and the applications.
>     
>     I totally see Marco's point of it's not optimal to have a new always frozen lib in Plasma Frameworks and I also see that it's a no-go to have Workspace depend on Apps and also Apps depend on Workspace. We have three possible ways and all are kind of broken ;-) Interesting things can happen.

I wasn't sure where to put it, but unless we put it in its own repo, plasma-framework seems like the best-of-the-bad place, so I went with that.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125817/#review87564
-----------------------------------------------------------


On Oct. 27, 2015, 10:10 p.m., Martin Klapetek wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125817/
> -----------------------------------------------------------
> 
> (Updated Oct. 27, 2015, 10:10 p.m.)
> 
> 
> Review request for Plasma and Daniel Vrátil.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> -------
> 
> This adds a simple plugin interface that can be subclassed
> and provide events integration with Plasma Calendar applet.
> 
> It's asynchronous and I've kept it deliberately simple.
> For now the Calendar tells the plugins which date range
> is being displayed, the plugins load the data and then
> emit the dataReady() signal containing the events.
> 
> The events are stored in a multihash for quick access
> by the Calendar's agenda part but also for overall
> easy-to-use (eg. in teh model data()).
> 
> The event data is stored in EventData class, which has
> a pretty self-explanatory members, except perhaps the
> "isMinor" one. The intention with this is to support
> namedays, where in some countries the calendars have
> different name every day. This is just a minor holiday
> and as such should not mark the calendar grid, otherwise
> the whole grid would be in a different color.
> 
> Putting the interface here might raise the question of
> depending on plasma-framework, but plugins provided by
> KDE can go to plasma-workspace and other 3rd party ones
> would just have to live with it. I don't think it will
> be a problem but if it turns out it is, we can rethink
> the placement.
> 
> 
> Diffs
> -----
> 
>   src/declarativeimports/calendar/CMakeLists.txt 40ead91 
>   src/declarativeimports/calendar/calendarplugin.cpp bafe80c 
>   src/declarativeimports/calendar/daysmodel.h a5bdac9 
>   src/declarativeimports/calendar/daysmodel.cpp 2d059a8 
>   src/declarativeimports/calendar/eventdatadecorator.h PRE-CREATION 
>   src/declarativeimports/calendar/eventdatadecorator.cpp PRE-CREATION 
>   src/declarativeimports/calendar/plasmacalendarintegration/CMakeLists.txt PRE-CREATION 
>   src/declarativeimports/calendar/plasmacalendarintegration/PlasmaCalendarIntegrationConfig.cmake.in PRE-CREATION 
>   src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.h PRE-CREATION 
>   src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125817/diff/
> 
> 
> Testing
> -------
> 
> I have a simple KHolidays based plugin written (patch should be up later today)
> and patches in the Calendar applet.
> 
> Everything works as expected:
> * the days are marked as containing an event
> * the agenda part displays details of that event (name)
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20151028/0ce34491/attachment-0001.html>