QML Calendar components for Akonadi in scratch repo

[Mark]

On Sun, Jul 14, 2013 at 7:58 PM, Kevin Krammer <krammer at kde.org> wrote:
> On Sunday, 2013-07-14, Mark wrote:
>> 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:
>
>> >> * 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..
>
> I am not sure if the components from runtime are used anywhere, or if they are
> anywhere outside Kontact Touch.
> It could be a dependency thing, i.e. not making kdepimlibs depend on
> QtDeclarative.
>
> So I think you are right that for the moment runtime would be the obvious
> choice.
>
> However I don't think it would be confusing to have different things in
> different modules.
> QML using developers wouldn't care since they would use import and let the
> declarative engine handle the plugin lookup, no?

Yeah, you're right. What would you suggest, move those calendar
components to kdepimlibs asap or keep them in runtime for the time
being?
And what to do with the other components in kdepim-runtime? Since they
probably should all be placed in kdepimlibs i guess.

>From my point of view it doesn't matter where they are, but i prefer
them to be in the right location from the start and not leaving them
in runtime for a few months before moving them to kdepimlibs.
>
> Cheers,
> Kevin
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>