@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 <mark...@gmail.com> wrote: > On Sun, Jul 14, 2013 at 7:58 PM, Kevin Krammer <kram...@kde.org> wrote: > > On Sunday, 2013-07-14, Mark wrote: > >> On Sun, Jul 14, 2013 at 6:12 PM, Kevin Krammer <kram...@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@kde.org > > https://mail.kde.org/mailman/listinfo/plasma-devel > > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
