QML Calendar components for Akonadi in scratch repo

[Kevin Krammer]

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?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130714/c0e6b72a/attachment.sig>