QML Calendar components for Akonadi in scratch repo

[Heena Mahour]

@Mark
You may like to review a small patch
https://git.reviewboard.kde.org/r/111516/


On Mon, Jul 15, 2013 at 7:20 AM, Mark <markg85 at gmail.com> wrote:

> 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
> >
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
-Heena
Season of kde'12 participant
Google Summer of Code 2013
Delhi College of Engineering(COE),India
http://about.me/heena.mahour
http://heenamahour.blogspot.in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130715/8ed70de9/attachment.html>