Re: split kdepimlibs
Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit : kpimidentities Maybe deserves a better name? kidentitymanagement? Done. kpimtextedit I suspect it could get a better name, but couldn't decide yet. :-) Also I wonder if some of it could/should go in ktexteditor? But I don't know the respective feature sets enough to be sure. kpimutils Looks like another dumping ground of random classes. Each class should likely find a new home. I started to remove some duplicate function and start to move in other modules ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [Kde-pim] split kdepimlibs
On Tuesday, 2014-08-26, 18:30:54, Daniel Vratil wrote: I think all the type-specific libraries (-abc, -calendar, ...) would all depend on the Widgets library anyway and the amount of non-gui stuff is rather limited * I think it is a worthy goal to make a widget split there as well. Some of the widgets are things like type data editors, which could be separated such that all editing logic and data handling can be used in a C++ or QML context. If the QML driven technology is not QtWidgets, then forcing a dependency might not be appreciated. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Wednesday, 2014-08-27, 19:59:24, John Layt wrote: My general 2c: I'm with Kevin that we should do functional and api reviews, move code around, and generally refactor stuff *before* we split anything. It's just plain easier that way. I don't think we're anywhere near close to knowing what to do with everything to be splitting things yet. Will we also end up with deprecated code in a kdepimlibs4-support, for example? We started a page at https://community.kde.org/Frameworks/Epics/kdepimlibs to document this sort of stuff, it would be good to bring it up-to-date and work through it progressively. We also have Akademy and the sprint scheduled for November (?) at which we could sit down and methodically work through the list of everything and figure out what to do. I agree, it makes little sense to rush this before Akademy. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [Kde-pim] split kdepimlibs
On Thursday, August 28, 2014 11:46:02 Kevin Krammer wrote: We also have Akademy and the sprint scheduled for November (?) at which we could sit down and methodically work through the list of everything and figure out what to do. I agree, it makes little sense to rush this before Akademy. Why not do this at Akademy? There should be enough luminaries around to be able to come up with a sensible proposal? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
My general 2c: I'm with Kevin that we should do functional and api reviews, move code around, and generally refactor stuff *before* we split anything. It's just plain easier that way. I don't think we're anywhere near close to knowing what to do with everything to be splitting things yet. Will we also end up with deprecated code in a kdepimlibs4-support, for example? We started a page at https://community.kde.org/Frameworks/Epics/kdepimlibs to document this sort of stuff, it would be good to bring it up-to-date and work through it progressively. We also have Akademy and the sprint scheduled for November (?) at which we could sit down and methodically work through the list of everything and figure out what to do. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On 26 August 2014 11:41, Jonathan Riddell j...@jriddell.org wrote: I'd like to suggest taking the opportunity to remove uses of the quite ugly term PIM in favour of the friendlier Kontact. I would say no. PIM in library names makes sense, especially as we want that others outside KDE-PIM / Kontact will use the PIM Frameworks . It's ugly, but recognised in the techie community. And just as with the other Frameworks, any gui strings need to be neutral as well. Now, KDE-PIM itself is another issue... John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
split kdepimlibs
Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils gpgme++ kabc kalarmcal kblog kcalcore kcalutils kholidays kimap kioslave kldap kmbox kmime kontactinterface kpimidentities kpimtextedit kpimutils ktnef kxmlrpcclient mailtransport microblog qgpgme syndication is it ok for you ? Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday 26 August 2014 11:20:25 laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils To me it sounds like some of those things could be regrouped now. What about also bringing the akonadi server on board? Having a bigger akonadi framework containing server (right now in kdesupport), some access libs and a few default plugins would make sense (it looks like a KIO like framework). gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? kholidays kimap kioslave Definitely not a framework. Are all the ioslaves in there still used? I think at least some of them can be let go. The others could go in kio-extras I guess. kldap kmbox kmime kontactinterface Probably should go in kdepim or kontact itself. Similarly the content of the kdelibs/interfaces folder moved out of KF5. kpimidentities Maybe deserves a better name? kidentitymanagement? kpimtextedit I suspect it could get a better name, but couldn't decide yet. :-) Also I wonder if some of it could/should go in ktexteditor? But I don't know the respective feature sets enough to be sure. kpimutils Looks like another dumping ground of random classes. Each class should likely find a new home. ktnef kxmlrpcclient mailtransport microblog qgpgme Couldn't that be merged with gpgme++? This one already builds several variants depending what it finds on the platform, why not treat the Qt integration in the same way? syndication is it ok for you ? I tried to point out things which would be harder to address after the split. So I think we should have discussions and decisions about the points above before being able to proceed. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit : On Tuesday 26 August 2014 11:20:25 laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils To me it sounds like some of those things could be regrouped now. What about also bringing the akonadi server on board? Having a bigger akonadi framework containing server (right now in kdesupport), some access libs and a few default plugins would make sense (it looks like a KIO like framework). Regroup as a framework as : akonadi-framework (better name) - src - akonadi-abc - akonadi-calendar - akonadi-contact - akonadi-mime - akonadi-notes - akonadi-socialutils - server (Dan must speak about it if he wants to move here) - plugins serializer (moved from kdepim-runtime) gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? Sergio can speak about it kholidays kimap kioslave Definitely not a framework. Are all the ioslaves in there still used? I think at least some of them can be let go. The others could go in kio-extras I guess. kioslave indeed not a framework. I think that just pop3 is used by kdepim yes others can move to kio-extra kldap kmbox kmime kontactinterface Probably should go in kdepim or kontact itself. Similarly the content of the kdelibs/interfaces folder moved out of KF5. We extracted it in 4.x to allow to create kontact plugins for other application. If we merge in kdepim we will not able to do it. kpimidentities Maybe deserves a better name? kidentitymanagement? Ok seems better. I will work to rename it. kpimtextedit I suspect it could get a better name, but couldn't decide yet. :-) Also I wonder if some of it could/should go in ktexteditor? But I don't know the respective feature sets enough to be sure. For me it's kdepim specific. kpimutils Looks like another dumping ground of random classes. Each class should likely find a new home. Ok I will try to move them. ktnef kxmlrpcclient mailtransport microblog qgpgme Couldn't that be merged with gpgme++? This one already builds several variants depending what it finds on the platform, why not treat the Qt integration in the same way? Really I never study this lib, there is not unittest, I don't know how it works and I don't know why there is several build. I will not work on. syndication is it ok for you ? I tried to point out things which would be harder to address after the split. So I think we should have discussions and decisions about the points above before being able to proceed. Regards. -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tue, Aug 26, 2014 at 11:20 AM, laurent Montel mon...@kde.org wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils gpgme++ kabc kalarmcal kblog kcalcore kcalutils kholidays kimap kioslave kldap kmbox kmime kontactinterface kpimidentities kpimtextedit kpimutils ktnef kxmlrpcclient mailtransport microblog qgpgme syndication is it ok for you ? Regards I'm sorry if I'm insisting too much. Will these become KDE Frameworks? Some of them? For example KXMLRPC is used by drkonqi, it would be good if it could become a KDE Framework. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
Le mardi 26 août 2014 12:37:40 Aleix Pol a écrit : On Tue, Aug 26, 2014 at 11:20 AM, laurent Montel mon...@kde.org wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils gpgme++ kabc kalarmcal kblog kcalcore kcalutils kholidays kimap kioslave kldap kmbox kmime kontactinterface kpimidentities kpimtextedit kpimutils ktnef kxmlrpcclient mailtransport microblog qgpgme syndication is it ok for you ? Regards I'm sorry if I'm insisting too much. Will these become KDE Frameworks? Some of them? For example KXMLRPC is used by drkonqi, it would be good if it could become a KDE Framework. it's the focus. We start to split and after we move as KF5 each module when they are ready. Aleix -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
El 26/08/2014 15:49, Vishesh Handa m...@vhanda.in escribió: On Tuesday, August 26, 2014 11:50:50 AM Kevin Ottens wrote: gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? KAbc definitely doesn't seem like a dumping ground. It's a valuable library that is also used by kpeople. It seems like a good candidate for an individual framework I would say he refers to kcalutils. Am I wrong? Cheers David Gil -- Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday, August 26, 2014 11:50:50 AM Kevin Ottens wrote: gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? KAbc definitely doesn't seem like a dumping ground. It's a valuable library that is also used by kpeople. It seems like a good candidate for an individual framework. -- Vishesh Handa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday 26 August 2014 15:51:33 David Gil Oliva wrote: El 26/08/2014 15:49, Vishesh Handa m...@vhanda.in escribió: On Tuesday, August 26, 2014 11:50:50 AM Kevin Ottens wrote: gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? KAbc definitely doesn't seem like a dumping ground. It's a valuable library that is also used by kpeople. It seems like a good candidate for an individual framework Really ;-) I would say he refers to kcalutils. Am I wrong? You're completely right. I didn't add any comments for the ones which looked fine. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
Looks like you forgot to add the KDE PIM list :-) On Tuesday, 2014-08-26, 11:20:25, laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc Is that akonadi/kabc? akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils gpgme++ kabc kalarmcal kblog kcalcore kcalutils kholidays kimap kioslave kldap kmbox kmime kontactinterface kpimidentities kpimtextedit kpimutils ktnef kxmlrpcclient mailtransport microblog qgpgme syndication Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday, 2014-08-26, 12:32:48, laurent Montel wrote: Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit : On Tuesday 26 August 2014 11:20:25 laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils To me it sounds like some of those things could be regrouped now. What about also bringing the akonadi server on board? Having a bigger akonadi framework containing server (right now in kdesupport), some access libs and a few default plugins would make sense (it looks like a KIO like framework). Regroup as a framework as : akonadi-framework (better name) - src - akonadi-abc - akonadi-calendar - akonadi-contact - akonadi-mime - akonadi-notes - akonadi-socialutils - server (Dan must speak about it if he wants to move here) - plugins serializer (moved from kdepim-runtime) We have to assume that frameworks will end up in single package dependencies, so it would be nice to have Akonadi server separate so it remains installable on its own. One thing that should probably be considered is that the current libs mix non- UI and UI stuff, so some separation in between these lines might still be something to strive for. gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? Sergio can speak about it kholidays kimap kioslave Definitely not a framework. Are all the ioslaves in there still used? I think at least some of them can be let go. The others could go in kio-extras I guess. kioslave indeed not a framework. I think that just pop3 is used by kdepim yes others can move to kio-extra Is the Akonadi IO slave in there as well? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday 26 of August 2014 12:32:48 laurent Montel wrote: Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit : On Tuesday 26 August 2014 11:20:25 laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils To me it sounds like some of those things could be regrouped now. What about also bringing the akonadi server on board? Having a bigger akonadi framework containing server (right now in kdesupport), some access libs and a few default plugins would make sense (it looks like a KIO like framework). Regroup as a framework as : akonadi-framework (better name) - src - akonadi-abc - akonadi-calendar - akonadi-contact - akonadi-mime - akonadi-notes - akonadi-socialutils - server (Dan must speak about it if he wants to move here) - plugins serializer (moved from kdepim-runtime) Hi, I definitely want to have the Server and the client libraries in one repo, shipped as a complete solution for PIM storage with the server being just part of the solution, not a standalone one. My original idea was that we would just merge the client libs into the existing akonadi.git repo, but setting up new akonadi-framework.git works just fine with me (and akonadi.git end up like kdelibs.git) About the type-specific (-abc, -calendar, ...) frameworks: maybe there could be something like Akonadi Framework Extras, and Akonadi Framework would really only be the server and the base client libs? What do you think? Dan gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? Sergio can speak about it kholidays kimap kioslave Definitely not a framework. Are all the ioslaves in there still used? I think at least some of them can be let go. The others could go in kio-extras I guess. kioslave indeed not a framework. I think that just pop3 is used by kdepim yes others can move to kio-extra kldap kmbox kmime kontactinterface Probably should go in kdepim or kontact itself. Similarly the content of the kdelibs/interfaces folder moved out of KF5. We extracted it in 4.x to allow to create kontact plugins for other application. If we merge in kdepim we will not able to do it. kpimidentities Maybe deserves a better name? kidentitymanagement? Ok seems better. I will work to rename it. kpimtextedit I suspect it could get a better name, but couldn't decide yet. :-) Also I wonder if some of it could/should go in ktexteditor? But I don't know the respective feature sets enough to be sure. For me it's kdepim specific. kpimutils Looks like another dumping ground of random classes. Each class should likely find a new home. Ok I will try to move them. ktnef kxmlrpcclient mailtransport microblog qgpgme Couldn't that be merged with gpgme++? This one already builds several variants depending what it finds on the platform, why not treat the Qt integration in the same way? Really I never study this lib, there is not unittest, I don't know how it works and I don't know why there is several build. I will not work on. syndication is it ok for you ? I tried to point out things which would be harder to address after the split. So I think we should have discussions and decisions about the points above before being able to proceed. Regards. -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi KDE Desktop Team Associate Software Engineer, Red Hat GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday 26 of August 2014 17:29:46 Kevin Krammer wrote: On Tuesday, 2014-08-26, 12:32:48, laurent Montel wrote: Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit : On Tuesday 26 August 2014 11:20:25 laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils To me it sounds like some of those things could be regrouped now. What about also bringing the akonadi server on board? Having a bigger akonadi framework containing server (right now in kdesupport), some access libs and a few default plugins would make sense (it looks like a KIO like framework). Regroup as a framework as : akonadi-framework (better name) - src - akonadi-abc - akonadi-calendar - akonadi-contact - akonadi-mime - akonadi-notes - akonadi-socialutils - server (Dan must speak about it if he wants to move here) - plugins serializer (moved from kdepim-runtime) We have to assume that frameworks will end up in single package dependencies, so it would be nice to have Akonadi server separate so it remains installable on its own. Ee, the server goes in :-) It will still be installable standalone of course, the only difference is that what is now libakonadiprotocolinternals.so would be libKF5AkonadiPrivate.so. One thing that should probably be considered is that the current libs mix non- UI and UI stuff, so some separation in between these lines might still be something to strive for. The Akonadi framework itself is already split into multiple libraries: libKF5AkonadiCore - non-gui stuff libKF5AkonadiAgentBase - agents/resources-related stuff (non-gui) libKF5AkonadiWidgets - gui (and some more, not important) I think all the type-specific libraries (-abc, -calendar, ...) would all depend on the Widgets library anyway and the amount of non-gui stuff is rather limited * * I haven't actually checked, sorry ;) gpgme++ kabc kalarmcal kblog kcalcore kcalutils This one looks like a dumping ground of random things. Maybe some of it should move in other frameworks? Sergio can speak about it kholidays kimap kioslave Definitely not a framework. Are all the ioslaves in there still used? I think at least some of them can be let go. The others could go in kio-extras I guess. kioslave indeed not a framework. I think that just pop3 is used by kdepim yes others can move to kio-extra Is the Akonadi IO slave in there as well? Cheers, Kevin -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi KDE Desktop Team Associate Software Engineer, Red Hat GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday 26 of August 2014 17:24:24 Kevin Krammer wrote: Looks like you forgot to add the KDE PIM list :-) On Tuesday, 2014-08-26, 11:20:25, laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc Is that akonadi/kabc? Yep - the massive framework with two files that contain two strings in total! I think this framework should die and the files moved to akonadi-contact. Or even better, we could just drop it - the only use in entire PIM stack I found is in the contactgroup serializer plugin - and it's only including the header file and not even actually using the strings defined there - seems kinda useless to me :-) Dan akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils gpgme++ kabc kalarmcal kblog kcalcore kcalutils kholidays kimap kioslave kldap kmbox kmime kontactinterface kpimidentities kpimtextedit kpimutils ktnef kxmlrpcclient mailtransport microblog qgpgme syndication Cheers, Kevin -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi KDE Desktop Team Associate Software Engineer, Red Hat GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
Le mardi 26 août 2014 17:29:46 Kevin Krammer a écrit : kioslave indeed not a framework. I think that just pop3 is used by kdepim yes others can move to kio-extra Is the Akonadi IO slave in there as well? Akonadi io slave is from kdepim-runtime but can be moved to kio-extra too not a problem fo me. Cheers, Kevin -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
Le mardi 26 août 2014 17:24:24 Kevin Krammer a écrit : Looks like you forgot to add the KDE PIM list :-) On Tuesday, 2014-08-26, 11:20:25, laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc Is that akonadi/kabc? yes it's akonadi-kabc. akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils gpgme++ kabc kalarmcal kblog kcalcore kcalutils kholidays kimap kioslave kldap kmbox kmime kontactinterface kpimidentities kpimtextedit kpimutils ktnef kxmlrpcclient mailtransport microblog qgpgme syndication Cheers, Kevin -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
Le mardi 26 août 2014 18:25:01 Daniel Vratil a écrit : On Tuesday 26 of August 2014 12:32:48 laurent Montel wrote: Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit : On Tuesday 26 August 2014 11:20:25 laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils To me it sounds like some of those things could be regrouped now. What about also bringing the akonadi server on board? Having a bigger akonadi framework containing server (right now in kdesupport), some access libs and a few default plugins would make sense (it looks like a KIO like framework). Regroup as a framework as : akonadi-framework (better name) - src - akonadi-abc - akonadi-calendar - akonadi-contact - akonadi-mime - akonadi-notes - akonadi-socialutils - server (Dan must speak about it if he wants to move here) - plugins serializer (moved from kdepim-runtime) Hi, I definitely want to have the Server and the client libraries in one repo, shipped as a complete solution for PIM storage with the server being just part of the solution, not a standalone one. My original idea was that we would just merge the client libs into the existing akonadi.git repo, but setting up new akonadi-framework.git works just fine with me (and akonadi.git end up like kdelibs.git) seems good for me And we move serialize plugin from kdepim-runtime to this framework no ? About the type-specific (-abc, -calendar, ...) frameworks: maybe there could be something like Akonadi Framework Extras, and Akonadi Framework would really only be the server and the base client libs? What do you think? I like it Dan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
On Tuesday 26 of August 2014 19:02:49 laurent Montel wrote: Le mardi 26 août 2014 18:25:01 Daniel Vratil a écrit : On Tuesday 26 of August 2014 12:32:48 laurent Montel wrote: Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit : On Tuesday 26 August 2014 11:20:25 laurent Montel wrote: Hi, I will split kdepimlibs as it akonadi (need to find another name because it's still used) akonadi-abc akonadi-calendar akonadi-contact akonadi-mime akonadi-notes akonadi-socialutils To me it sounds like some of those things could be regrouped now. What about also bringing the akonadi server on board? Having a bigger akonadi framework containing server (right now in kdesupport), some access libs and a few default plugins would make sense (it looks like a KIO like framework). Regroup as a framework as : akonadi-framework (better name) - src - akonadi-abc - akonadi-calendar - akonadi-contact - akonadi-mime - akonadi-notes - akonadi-socialutils - server (Dan must speak about it if he wants to move here) - plugins serializer (moved from kdepim-runtime) Hi, I definitely want to have the Server and the client libraries in one repo, shipped as a complete solution for PIM storage with the server being just part of the solution, not a standalone one. My original idea was that we would just merge the client libs into the existing akonadi.git repo, but setting up new akonadi-framework.git works just fine with me (and akonadi.git end up like kdelibs.git) seems good for me And we move serialize plugin from kdepim-runtime to this framework no ? The plugins usually depend on the type-specific classes, so they would have to go to the Extras too. About the type-specific (-abc, -calendar, ...) frameworks: maybe there could be something like Akonadi Framework Extras, and Akonadi Framework would really only be the server and the base client libs? What do you think? I like it Dan -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi KDE Desktop Team Associate Software Engineer, Red Hat GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348 signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: split kdepimlibs
Hello, On Tuesday 26 August 2014 18:25:01 Daniel Vratil wrote: I definitely want to have the Server and the client libraries in one repo, shipped as a complete solution for PIM storage with the server being just part of the solution, not a standalone one. Excellent. Definitely what I'd like to see happen. My original idea was that we would just merge the client libs into the existing akonadi.git repo, but setting up new akonadi-framework.git works just fine with me (and akonadi.git end up like kdelibs.git) If we could keep the akonadi repository that would be nice. I'm not too fond of the -framework suffix in the repository name. About the type-specific (-abc, -calendar, ...) frameworks: maybe there could be something like Akonadi Framework Extras, and Akonadi Framework would really only be the server and the base client libs? What do you think? Makes sense. An akonadi-extras is a possibility. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
