On Sun, Jul 14, 2013 at 6:12 PM, Kevin Krammer <kram...@kde.org> wrote: > On Friday, 2013-07-12, Aaron J. Seigo wrote: >> On Friday, July 12, 2013 14:20:37 Mark wrote: >> > This is also one of the questions i have, where should i put this, >> > kdepim-runtime or kde-runtime? >> >> that entirely depends on the dependencies. >> >> what would be optimal is: >> >> * QML calendar widgetry with no akonadi integration in kde-runtime >> * akonadi integration for the calendar in kdepim-runtime >> >> looking at the documentation on the wiki, this seems like it should be >> possible. >> >> if it is not possible to separate out the akonadi support, then it will >> need to go into kdepim-runtime .. but you will need to check with the >> kdepim developers first as they maintain those modules, not us here on >> plasma-devel :) > > From a PIM point of view my take would be kdepimlibs, unless it also depends > on Plasma entities not available at that level (kdelibs/frameworks). > > At least it sounds a lot like QML facing API and related UI controls, similar > to how we have specialized widgets in kdepimlibs like a contact editor widget. > > Cheers, > Kevin
Hi Kevin, kdepimlibs doesn't have any QML components at this moment (didn't found any thus far). kdepim-runtime has. I can see both to be possible places to include these components. kdepim-runtime "seems" to be the logical one since it already has components including some for akonadi. If the calendar components are going to be moved to kdepimlibs, should the already available akonadi components be moved as well? Since it would seem very confusing to have some akonadi components in kdepim-runtime and some "pim calendar" components (which actually are akonadi components as well from a technical point of view) in kdepimlibs.. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
