QML Calendar components for Akonadi in scratch repo

Mark markg85 at gmail.com
Sun Jul 14 16:31:11 UTC 2013


On Sun, Jul 14, 2013 at 6:12 PM, Kevin Krammer <krammer at 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..


More information about the Plasma-devel mailing list