Re: New(ish) Framework review: kstatusnotifieritem
El dimecres, 16 d’agost de 2023, a les 13:35:44 (CEST), Nicolas Fella va escriure: > Hi, > > at the last meeting we decided to extract KStatusNotifierItem from > KNotifications into a separate Framework. > > Reasons are: > > - They are rather distinct in scope/concept > > - They negatively affect each other's dependencies > > I've now created https://invent.kde.org/frameworks/kstatusnotifieritem > and started porting users of KStatusNotifierItem to it. > > Given that this is 100% pre-existing Frameworks code I don't think an > in-depth "new framework review" is really appropriate, but if you have > important and/or actionable points then we can of course discuss them. It's missing a Messages.sh file Cheers, Albert > > Cheers > > Nico
Re: New Framework Review: KTextTemplate
On Donnerstag, 11. Mai 2023 18:32:23 CEST Volker Krause wrote: > let's get the process for getting KTextTemplate (https://invent.kde.org/ > libraries/ktexttemplate) into KF6 going. This is the library formerly known > as Grantlee and implements Django-style text templates. It's in use in PIM > and KDevelop, among others. > > In the 5 era it was released stand-alone from Github, but providing ABI > stability as well there. Any other deviation from common KF patterns have > meanwhile been adjusted I think. The repository has now been moved to the frameworks group: https://invent.kde.org/frameworks/ktexttemplate Review of the pending SPDX conversion MR would be appreciated :) Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KTextTemplate
On Freitag, 12. Mai 2023 11:14:29 CEST Albert Astals Cid wrote: > El dijous, 11 de maig de 2023, a les 18:32:23 (CEST), Volker Krause va > > escriure: > > Hi, > > > > let's get the process for getting KTextTemplate (https://invent.kde.org/ > > libraries/ktexttemplate) into KF6 going. This is the library formerly > > known > > as Grantlee and implements Django-style text templates. It's in use in PIM > > and KDevelop, among others. > > > > In the 5 era it was released stand-alone from Github, but providing ABI > > stability as well there. Any other deviation from common KF patterns have > > meanwhile been adjusted I think. > > > > (I'm not the author or maintainer, I'm merely looking at getting things in > > place in time for the 6 release here). > > Can someone confirm that this doesn't need i18n ? That's my understanding, yes. There is support for translation inside HTML templates in there (which is why you get a bunch of hits on "i18n" when grep'ing), but that's API, not user-visible strings. There's also integration plugins for KF::I18n for this, currently living in PIM (and potentially more copies elsewhere), I'd also like to get those into KF eventually, but one step at a time :) Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KTextTemplate
El dijous, 11 de maig de 2023, a les 18:32:23 (CEST), Volker Krause va escriure: > Hi, > > let's get the process for getting KTextTemplate (https://invent.kde.org/ > libraries/ktexttemplate) into KF6 going. This is the library formerly known > as Grantlee and implements Django-style text templates. It's in use in PIM > and KDevelop, among others. > > In the 5 era it was released stand-alone from Github, but providing ABI > stability as well there. Any other deviation from common KF patterns have > meanwhile been adjusted I think. > > (I'm not the author or maintainer, I'm merely looking at getting things in > place in time for the 6 release here). Can someone confirm that this doesn't need i18n ? Cheers, Albert > > Regards, > Volker
Re: New
On 11/17/22 02:08, David Faure wrote> Done: kconfig v5.100.1 f4dcf631e9f22e25c768c323762672716ddbdd02 8bbb7951d74e8e289f7b0599887ef328b2726fdbdaae18effda2c9d7f18a82da sources/kconfig-5.100.1.tar.xz plasma-framework v5.100.1 0435ec52c76092bc8a8e2703fa0acbbb63484dfe 53940a920773a105df0af9dd3dbf7afcebc6e1eb66404cc77f46c80563b4ada1 sources/plasma-framework-5.100.1.tar.xz Linux/BSD packagers: you can skip kconfig-5.100.1, that fix is Windows-only anyway. Thanks a lot, David! Nate
Re: New
On mercredi 16 novembre 2022 16:34:28 CET Nate Graham wrote: > Hello frameworks and release folks, > > We had a few major regressions in the 5.100 release that have already > been fixed; see: > - https://invent.kde.org/frameworks/kconfig/-/merge_requests/148 > - https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/652 > > These are significant enough that I'd like to recommend we make new > releases of the kconfig and plasma-framework frameworks so we can get > the fixes to users as quickly as possible. Done: kconfig v5.100.1 f4dcf631e9f22e25c768c323762672716ddbdd02 8bbb7951d74e8e289f7b0599887ef328b2726fdbdaae18effda2c9d7f18a82da sources/kconfig-5.100.1.tar.xz plasma-framework v5.100.1 0435ec52c76092bc8a8e2703fa0acbbb63484dfe 53940a920773a105df0af9dd3dbf7afcebc6e1eb66404cc77f46c80563b4ada1 sources/plasma-framework-5.100.1.tar.xz Linux/BSD packagers: you can skip kconfig-5.100.1, that fix is Windows-only anyway. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New Framework Review: KDAV
This has all been executed now, including the move on Gitlab and the necessary changes to the dependency metadata. So unless I'm missing something this should be all done now and we'll have KDAV in KF 5.72 as a drop-in replacement for the one released with 20.04 :) Thanks everyone for helping with this! Volker On Sunday, 14 June 2020 11:53:42 CEST Albert Astals Cid wrote: > El diumenge, 14 de juny de 2020, a les 10:17:01 CEST, Ben Cooksley va escriure: > > On Sun, Jun 14, 2020 at 8:03 PM Volker Krause wrote: > > > With both 20.04.2 and 5.71.0 out I think it's now time to do this move. > > > > > > What extra steps do we need to take now that the framework/application > > > distinction exists in Gitlab as well? I guess this is the first case of > > > a > > > post-migration move. Also, what is the impact on the 20.04.3 release > > > when we move this in Gitlab? > > > > You'll need to file a Sysadmin ticket requesting we relocate the > > repository from it's current home in pim/ to frameworks/ > > Gitlab will provide a redirect for this automatically, so existing > > urls and clones won't be affected by this - although they will be > > given a notice that it has moved. > > > > Systems such as scripty won't be impacted by this as they use the > > stable repository identifier. > > > > In terms of the Release Service 20.04.3 release, Albert/Christoph will > > need to comment on this. > > It shouldn't, the release service scripts don't care about the subdir repos > are in, and given gitlab follows moves, we shouldn't not have a problem > either with things like pushing tags, etc. > > Cheers, > Albert > > > > Thanks, > > > Volker > > > > Cheers, > > Ben > > > > > On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote: > > > > The remaining issues that didn't change ABI anymore (movable value > > > > types, > > > > hide private methods/slots inside the private classes, etc) have long > > > > since > > > > been addressed. > > > > > > > > I think there's two possible time slots to actually execute the move > > > > to > > > > frameworks now: > > > > * ASAP, for the June release. > > > > * For the July release, just in time for the 20.08 dependency freeze. > > > > > > > > Opinions? > > > > > > > > Thanks, > > > > Volker > > > > > > > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > > > > > Thanks for the review! We are cutting it close again with the 20.04 > > > > > deadline, but fortunately most of these findings aren't ABI-breaking > > > > > :) > > > > > > > > > > The result was discussed in more detail at the (virtual) PIM sprint, > > > > > summary below for the record. > > > > > > > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > > > > > Hello, > > > > > > > > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > > > > > during Akademy there was a request to promote KDAV from KDE PIM > > > > > > > to > > > > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that > > > > > > > implements > > > > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav > > > > > > > support. > > > > > > > It > > > > > > > would be classified as a functional tier 3 framework. > > > > > > > > > > > > > > So far we have fixed a number of obvious ABI-compatibility > > > > > > > issues, > > > > > > > removed > > > > > > > QtXml[Patterns] usage from the public interface and relicensed > > > > > > > GPL > > > > > > > parts > > > > > > > (apart from a bit of test code) to LGPL. The next step would be > > > > > > > a more > > > > > > > thorough review to identify changes necessary before becoming a > > > > > > > Framework. > > > > > > > > > > > > > > To avoid the last minute invasive changes we ended up doing for > > > > > > > KCalendarCore, I'd propose the following timeline: > > > > > > > > > > > > > > - identify and implement all necessary changes to the API and > > > > > > > ABI > > > > > > > until > > > > > > > the > > > > > > > 20.04 Application release (that includes the still necessary > > > > > > > move to > > > > > > > the > > > > > > > KF5 library namespace). > > > > > > > > > > > > I'm likely late to the party, but here is what I found by looking > > > > > > at > > > > > > KDAV > > > > > > > > > > > > master today (first day of the KDE PIM sprint): > > > > > > * There's a few private methods or Q_SLOTS that I'd hide > > > > > > completely by > > > > > > > > > > > > moving them to the d-pointer, for the slots we're using type safe > > > > > > connects > > > > > > so they don't even need to be marked as slots at all; > > > > > > > > > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > > > > > > > > > * Is it worth making DavCollection moveable? It's only copyable > > > > > > right > > > > > > now; > > > > > > > > > > Probably yes, that's new API with no ABI break, so we can do that > > > > > post > > > > > 20.04 as well. > > > > > > > > > > > * We might want to do something about "ctag" in
Re: New Framework Review: KDAV
On Friday, 19 June 2020 01:16:20 CEST Friedrich W. H. Kossebau wrote: > Am Samstag, 4. April 2020, 16:20:21 CEST schrieb Kevin Ottens: > > Overall apidox would likely need a big pass of cleanups as well. > > I locally prepared the addition of ECMAddQch usage for KDAV tonight, and > while testing the output already did some small bits of minor cleanup > (consistent casing of terms like URL, ETag, etc. in the texts), documenting > CamelCase includes of classes as well triggering the documentation of > namespace KDAV. Thanks! > One thing which should get fixed by someone with insights are all the > remaining references to some "ResourceBase::retrieveItems()" in the docs > (simply grep for the string to find those). That needs more context, or > better some generalization what is meant there (seems something-Akonadi > specific?). I've added the full namespace now, but you are right, this leaks details about the origin of all this and should probably be abstracted/generalized. Regards, Volker
Re: New Framework Review: KDAV
Am Freitag, 19. Juni 2020, 01:16:20 CEST schrieb Friedrich W. H. Kossebau: > Will commit the ECMAddQch stuff once https://invent.kde.org/pim/kdav/-/ > merge_requests/1 is in, to not block this more due to resulting new merge > conflicts. And while I was typing & sending, that got merged at the same time it seems. So landing now as well... Cheers Friedrich
Re: New Framework Review: KDAV
Am Samstag, 4. April 2020, 16:20:21 CEST schrieb Kevin Ottens: > Overall apidox would likely need a big pass of cleanups as well. I locally prepared the addition of ECMAddQch usage for KDAV tonight, and while testing the output already did some small bits of minor cleanup (consistent casing of terms like URL, ETag, etc. in the texts), documenting CamelCase includes of classes as well triggering the documentation of namespace KDAV. One thing which should get fixed by someone with insights are all the remaining references to some "ResourceBase::retrieveItems()" in the docs (simply grep for the string to find those). That needs more context, or better some generalization what is meant there (seems something-Akonadi specific?). Will commit the ECMAddQch stuff once https://invent.kde.org/pim/kdav/-/ merge_requests/1 is in, to not block this more due to resulting new merge conflicts. Cheers Friedrich
Re: New Framework Review: KDAV
El diumenge, 14 de juny de 2020, a les 10:17:01 CEST, Ben Cooksley va escriure: > On Sun, Jun 14, 2020 at 8:03 PM Volker Krause wrote: > > > > With both 20.04.2 and 5.71.0 out I think it's now time to do this move. > > > > What extra steps do we need to take now that the framework/application > > distinction exists in Gitlab as well? I guess this is the first case of a > > post-migration move. Also, what is the impact on the 20.04.3 release when we > > move this in Gitlab? > > You'll need to file a Sysadmin ticket requesting we relocate the > repository from it's current home in pim/ to frameworks/ > Gitlab will provide a redirect for this automatically, so existing > urls and clones won't be affected by this - although they will be > given a notice that it has moved. > > Systems such as scripty won't be impacted by this as they use the > stable repository identifier. > > In terms of the Release Service 20.04.3 release, Albert/Christoph will > need to comment on this. It shouldn't, the release service scripts don't care about the subdir repos are in, and given gitlab follows moves, we shouldn't not have a problem either with things like pushing tags, etc. Cheers, Albert > > > > > Thanks, > > Volker > > Cheers, > Ben > > > > > On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote: > > > The remaining issues that didn't change ABI anymore (movable value types, > > > hide private methods/slots inside the private classes, etc) have long > > > since > > > been addressed. > > > > > > I think there's two possible time slots to actually execute the move to > > > frameworks now: > > > * ASAP, for the June release. > > > * For the July release, just in time for the 20.08 dependency freeze. > > > > > > Opinions? > > > > > > Thanks, > > > Volker > > > > > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > > > > Thanks for the review! We are cutting it close again with the 20.04 > > > > deadline, but fortunately most of these findings aren't ABI-breaking :) > > > > > > > > The result was discussed in more detail at the (virtual) PIM sprint, > > > > summary below for the record. > > > > > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > > > > Hello, > > > > > > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > > > > during Akademy there was a request to promote KDAV from KDE PIM to > > > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that > > > > > > implements > > > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav > > > > > > support. > > > > > > It > > > > > > would be classified as a functional tier 3 framework. > > > > > > > > > > > > So far we have fixed a number of obvious ABI-compatibility issues, > > > > > > removed > > > > > > QtXml[Patterns] usage from the public interface and relicensed GPL > > > > > > parts > > > > > > (apart from a bit of test code) to LGPL. The next step would be a > > > > > > more > > > > > > thorough review to identify changes necessary before becoming a > > > > > > Framework. > > > > > > > > > > > > To avoid the last minute invasive changes we ended up doing for > > > > > > KCalendarCore, I'd propose the following timeline: > > > > > > > > > > > > - identify and implement all necessary changes to the API and ABI > > > > > > until > > > > > > the > > > > > > 20.04 Application release (that includes the still necessary move to > > > > > > the > > > > > > KF5 library namespace). > > > > > > > > > > I'm likely late to the party, but here is what I found by looking at > > > > > KDAV > > > > > > > > > > master today (first day of the KDE PIM sprint): > > > > > * There's a few private methods or Q_SLOTS that I'd hide completely > > > > > by > > > > > > > > > > moving them to the d-pointer, for the slots we're using type safe > > > > > connects > > > > > so they don't even need to be marked as slots at all; > > > > > > > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > > > > > > > * Is it worth making DavCollection moveable? It's only copyable right > > > > > now; > > > > > > > > Probably yes, that's new API with no ABI break, so we can do that post > > > > 20.04 as well. > > > > > > > > > * We might want to do something about "ctag" in DavCollection it's a > > > > > bit > > > > > > > > > > obscure as a name (and the API doc doesn't help), also it seems to not > > > > > be > > > > > an official standard (while being widely supported) and there's the > > > > > sync-token mechanism which has a RFC (RFC6578); > > > > > > > > I have no idea what ctag is (I am only doing the technical work needed > > > > to > > > > turn this into a framework, I didn't write this library). > > > > > > > > > * Why isn't DavCollectionModifyJob using DavCollection somehow? > > > > > (might > > > > > just > > > > > > > > > > be my ignorance but I find it surprising that it is solely based on a > > > > > property mechanism); > > > > > > > > I think this is to be able to contro
Re: New Framework Review: KDAV
On Sun, Jun 14, 2020 at 8:03 PM Volker Krause wrote: > > With both 20.04.2 and 5.71.0 out I think it's now time to do this move. > > What extra steps do we need to take now that the framework/application > distinction exists in Gitlab as well? I guess this is the first case of a > post-migration move. Also, what is the impact on the 20.04.3 release when we > move this in Gitlab? You'll need to file a Sysadmin ticket requesting we relocate the repository from it's current home in pim/ to frameworks/ Gitlab will provide a redirect for this automatically, so existing urls and clones won't be affected by this - although they will be given a notice that it has moved. Systems such as scripty won't be impacted by this as they use the stable repository identifier. In terms of the Release Service 20.04.3 release, Albert/Christoph will need to comment on this. > > Thanks, > Volker Cheers, Ben > > On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote: > > The remaining issues that didn't change ABI anymore (movable value types, > > hide private methods/slots inside the private classes, etc) have long since > > been addressed. > > > > I think there's two possible time slots to actually execute the move to > > frameworks now: > > * ASAP, for the June release. > > * For the July release, just in time for the 20.08 dependency freeze. > > > > Opinions? > > > > Thanks, > > Volker > > > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > > > Thanks for the review! We are cutting it close again with the 20.04 > > > deadline, but fortunately most of these findings aren't ABI-breaking :) > > > > > > The result was discussed in more detail at the (virtual) PIM sprint, > > > summary below for the record. > > > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > > > Hello, > > > > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > > > during Akademy there was a request to promote KDAV from KDE PIM to > > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that > > > > > implements > > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. > > > > > It > > > > > would be classified as a functional tier 3 framework. > > > > > > > > > > So far we have fixed a number of obvious ABI-compatibility issues, > > > > > removed > > > > > QtXml[Patterns] usage from the public interface and relicensed GPL > > > > > parts > > > > > (apart from a bit of test code) to LGPL. The next step would be a more > > > > > thorough review to identify changes necessary before becoming a > > > > > Framework. > > > > > > > > > > To avoid the last minute invasive changes we ended up doing for > > > > > KCalendarCore, I'd propose the following timeline: > > > > > > > > > > - identify and implement all necessary changes to the API and ABI > > > > > until > > > > > the > > > > > 20.04 Application release (that includes the still necessary move to > > > > > the > > > > > KF5 library namespace). > > > > > > > > I'm likely late to the party, but here is what I found by looking at > > > > KDAV > > > > > > > > master today (first day of the KDE PIM sprint): > > > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > > > > > moving them to the d-pointer, for the slots we're using type safe > > > > connects > > > > so they don't even need to be marked as slots at all; > > > > > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > > > > > * Is it worth making DavCollection moveable? It's only copyable right > > > > now; > > > > > > Probably yes, that's new API with no ABI break, so we can do that post > > > 20.04 as well. > > > > > > > * We might want to do something about "ctag" in DavCollection it's a > > > > bit > > > > > > > > obscure as a name (and the API doc doesn't help), also it seems to not > > > > be > > > > an official standard (while being widely supported) and there's the > > > > sync-token mechanism which has a RFC (RFC6578); > > > > > > I have no idea what ctag is (I am only doing the technical work needed to > > > turn this into a framework, I didn't write this library). > > > > > > > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might > > > > just > > > > > > > > be my ignorance but I find it surprising that it is solely based on a > > > > property mechanism); > > > > > > I think this is to be able to control which properties get changed, rather > > > than sending the full set of them. > > > > > > > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter > > > > on > > > > > > > > its collectionDiscovered signal, is it really necessary? if it has to > > > > stay, > > > > shouldn't be at least documented? or at least a safer type than int? > > > > > > Fixed in https://phabricator.kde.org/D28564 and > > > https://phabricator.kde.org/ D28566 > > > > > > > * DavCollectionsMultiFetchJob is inconsistent as it's not using > > > > Q_DECLARE_PRIVATE; > > > > > > That's due to us
Re: New Framework Review: KDAV
With both 20.04.2 and 5.71.0 out I think it's now time to do this move. What extra steps do we need to take now that the framework/application distinction exists in Gitlab as well? I guess this is the first case of a post-migration move. Also, what is the impact on the 20.04.3 release when we move this in Gitlab? Thanks, Volker On Sunday, 24 May 2020 08:52:17 CEST Volker Krause wrote: > The remaining issues that didn't change ABI anymore (movable value types, > hide private methods/slots inside the private classes, etc) have long since > been addressed. > > I think there's two possible time slots to actually execute the move to > frameworks now: > * ASAP, for the June release. > * For the July release, just in time for the 20.08 dependency freeze. > > Opinions? > > Thanks, > Volker > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > > Thanks for the review! We are cutting it close again with the 20.04 > > deadline, but fortunately most of these findings aren't ABI-breaking :) > > > > The result was discussed in more detail at the (virtual) PIM sprint, > > summary below for the record. > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > > Hello, > > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > > during Akademy there was a request to promote KDAV from KDE PIM to > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that > > > > implements > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. > > > > It > > > > would be classified as a functional tier 3 framework. > > > > > > > > So far we have fixed a number of obvious ABI-compatibility issues, > > > > removed > > > > QtXml[Patterns] usage from the public interface and relicensed GPL > > > > parts > > > > (apart from a bit of test code) to LGPL. The next step would be a more > > > > thorough review to identify changes necessary before becoming a > > > > Framework. > > > > > > > > To avoid the last minute invasive changes we ended up doing for > > > > KCalendarCore, I'd propose the following timeline: > > > > > > > > - identify and implement all necessary changes to the API and ABI > > > > until > > > > the > > > > 20.04 Application release (that includes the still necessary move to > > > > the > > > > KF5 library namespace). > > > > > > I'm likely late to the party, but here is what I found by looking at > > > KDAV > > > > > > master today (first day of the KDE PIM sprint): > > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > > > moving them to the d-pointer, for the slots we're using type safe > > > connects > > > so they don't even need to be marked as slots at all; > > > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > > > * Is it worth making DavCollection moveable? It's only copyable right > > > now; > > > > Probably yes, that's new API with no ABI break, so we can do that post > > 20.04 as well. > > > > > * We might want to do something about "ctag" in DavCollection it's a > > > bit > > > > > > obscure as a name (and the API doc doesn't help), also it seems to not > > > be > > > an official standard (while being widely supported) and there's the > > > sync-token mechanism which has a RFC (RFC6578); > > > > I have no idea what ctag is (I am only doing the technical work needed to > > turn this into a framework, I didn't write this library). > > > > > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might > > > just > > > > > > be my ignorance but I find it surprising that it is solely based on a > > > property mechanism); > > > > I think this is to be able to control which properties get changed, rather > > than sending the full set of them. > > > > > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter > > > on > > > > > > its collectionDiscovered signal, is it really necessary? if it has to > > > stay, > > > shouldn't be at least documented? or at least a safer type than int? > > > > Fixed in https://phabricator.kde.org/D28564 and > > https://phabricator.kde.org/ D28566 > > > > > * DavCollectionsMultiFetchJob is inconsistent as it's not using > > > Q_DECLARE_PRIVATE; > > > > That's due to using KJob as a base directly. > > > > Subsequent discussion suggested this should be a KCompositeJob, David is > > taking care of this. > > > > > * KDAV::Error would benefit from more apidox; > > > > Yes, not blocked by the 20.04 freeze though. > > > > > * Is it worth making DavItem moveable? It's only copyable right now; > > > > See above, same as DavCollection. > > > > > * Same comment about etag for DavItem than the ctag one for > > > DavCollection > > > > See above, same as ctag. > > > > > * I'd be tempted to move all the protected methods of DavJobBase on its > > > d- > > > > > > pointer, the job subclasses would have access to them anyway, it'd make > > > sense to put them protected in the header only if we expect subc
Re: New Framework Review: KDAV
On Sun, May 24, 2020 at 8:52 AM Volker Krause wrote: > > The remaining issues that didn't change ABI anymore (movable value types, hide > private methods/slots inside the private classes, etc) have long since been > addressed. > > I think there's two possible time slots to actually execute the move to > frameworks now: > * ASAP, for the June release. > * For the July release, just in time for the 20.08 dependency freeze. > > Opinions? > > Thanks, > Volker > > On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > > Thanks for the review! We are cutting it close again with the 20.04 > > deadline, but fortunately most of these findings aren't ABI-breaking :) > > > > The result was discussed in more detail at the (virtual) PIM sprint, summary > > below for the record. > > > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > > Hello, > > > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > > during Akademy there was a request to promote KDAV from KDE PIM to > > > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > > > > would be classified as a functional tier 3 framework. > > > > > > > > So far we have fixed a number of obvious ABI-compatibility issues, > > > > removed > > > > QtXml[Patterns] usage from the public interface and relicensed GPL parts > > > > (apart from a bit of test code) to LGPL. The next step would be a more > > > > thorough review to identify changes necessary before becoming a > > > > Framework. > > > > > > > > To avoid the last minute invasive changes we ended up doing for > > > > KCalendarCore, I'd propose the following timeline: > > > > > > > > - identify and implement all necessary changes to the API and ABI until > > > > the > > > > 20.04 Application release (that includes the still necessary move to the > > > > KF5 library namespace). > > > > > > I'm likely late to the party, but here is what I found by looking at KDAV > > > > > > master today (first day of the KDE PIM sprint): > > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > > > moving them to the d-pointer, for the slots we're using type safe connects > > > so they don't even need to be marked as slots at all; > > > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > > > * Is it worth making DavCollection moveable? It's only copyable right > > > now; > > > > Probably yes, that's new API with no ABI break, so we can do that post 20.04 > > as well. > > > > > * We might want to do something about "ctag" in DavCollection it's a bit > > > > > > obscure as a name (and the API doc doesn't help), also it seems to not be > > > an official standard (while being widely supported) and there's the > > > sync-token mechanism which has a RFC (RFC6578); > > > > I have no idea what ctag is (I am only doing the technical work needed to > > turn this into a framework, I didn't write this library). > > > > > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might > > > just > > > > > > be my ignorance but I find it surprising that it is solely based on a > > > property mechanism); > > > > I think this is to be able to control which properties get changed, rather > > than sending the full set of them. > > > > > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on > > > > > > its collectionDiscovered signal, is it really necessary? if it has to > > > stay, > > > shouldn't be at least documented? or at least a safer type than int? > > > > Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/ > > D28566 > > > > > * DavCollectionsMultiFetchJob is inconsistent as it's not using > > > Q_DECLARE_PRIVATE; > > > > That's due to using KJob as a base directly. > > > > Subsequent discussion suggested this should be a KCompositeJob, David is > > taking care of this. > > > > > * KDAV::Error would benefit from more apidox; > > > > Yes, not blocked by the 20.04 freeze though. > > > > > * Is it worth making DavItem moveable? It's only copyable right now; > > > > See above, same as DavCollection. > > > > > * Same comment about etag for DavItem than the ctag one for DavCollection > > > > See above, same as ctag. > > > > > * I'd be tempted to move all the protected methods of DavJobBase on its > > > d- > > > > > > pointer, the job subclasses would have access to them anyway, it'd make > > > sense to put them protected in the header only if we expect subclasses > > > outside of the lib (and I doubt this is actually supported); > > > > ABI impact mitigated by https://phabricator.kde.org/D28562 so we can clean > > this up after 20.04. > > > > > * It needs to decide between Qt smart pointers or STL ones I think, found > > > a > > > > > > bit of both so far (I'd lean toward STL ones but maybe that's just me); > > > > Also fixed by https://phabricator.kde.org/D28562. > > > > > * Make DavUrl moveable? >
Re: New Framework Review: KDAV
The remaining issues that didn't change ABI anymore (movable value types, hide private methods/slots inside the private classes, etc) have long since been addressed. I think there's two possible time slots to actually execute the move to frameworks now: * ASAP, for the June release. * For the July release, just in time for the 20.08 dependency freeze. Opinions? Thanks, Volker On Saturday, 4 April 2020 17:32:19 CEST Volker Krause wrote: > Thanks for the review! We are cutting it close again with the 20.04 > deadline, but fortunately most of these findings aren't ABI-breaking :) > > The result was discussed in more detail at the (virtual) PIM sprint, summary > below for the record. > > On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > > Hello, > > > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > > during Akademy there was a request to promote KDAV from KDE PIM to > > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > > > would be classified as a functional tier 3 framework. > > > > > > So far we have fixed a number of obvious ABI-compatibility issues, > > > removed > > > QtXml[Patterns] usage from the public interface and relicensed GPL parts > > > (apart from a bit of test code) to LGPL. The next step would be a more > > > thorough review to identify changes necessary before becoming a > > > Framework. > > > > > > To avoid the last minute invasive changes we ended up doing for > > > KCalendarCore, I'd propose the following timeline: > > > > > > - identify and implement all necessary changes to the API and ABI until > > > the > > > 20.04 Application release (that includes the still necessary move to the > > > KF5 library namespace). > > > > I'm likely late to the party, but here is what I found by looking at KDAV > > > > master today (first day of the KDE PIM sprint): > > * There's a few private methods or Q_SLOTS that I'd hide completely by > > > > moving them to the d-pointer, for the slots we're using type safe connects > > so they don't even need to be marked as slots at all; > > Cosmetic with no ABI impact, we can do that post 20.04 still. > > > * Is it worth making DavCollection moveable? It's only copyable right > > now; > > Probably yes, that's new API with no ABI break, so we can do that post 20.04 > as well. > > > * We might want to do something about "ctag" in DavCollection it's a bit > > > > obscure as a name (and the API doc doesn't help), also it seems to not be > > an official standard (while being widely supported) and there's the > > sync-token mechanism which has a RFC (RFC6578); > > I have no idea what ctag is (I am only doing the technical work needed to > turn this into a framework, I didn't write this library). > > > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might > > just > > > > be my ignorance but I find it surprising that it is solely based on a > > property mechanism); > > I think this is to be able to control which properties get changed, rather > than sending the full set of them. > > > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on > > > > its collectionDiscovered signal, is it really necessary? if it has to > > stay, > > shouldn't be at least documented? or at least a safer type than int? > > Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/ > D28566 > > > * DavCollectionsMultiFetchJob is inconsistent as it's not using > > Q_DECLARE_PRIVATE; > > That's due to using KJob as a base directly. > > Subsequent discussion suggested this should be a KCompositeJob, David is > taking care of this. > > > * KDAV::Error would benefit from more apidox; > > Yes, not blocked by the 20.04 freeze though. > > > * Is it worth making DavItem moveable? It's only copyable right now; > > See above, same as DavCollection. > > > * Same comment about etag for DavItem than the ctag one for DavCollection > > See above, same as ctag. > > > * I'd be tempted to move all the protected methods of DavJobBase on its > > d- > > > > pointer, the job subclasses would have access to them anyway, it'd make > > sense to put them protected in the header only if we expect subclasses > > outside of the lib (and I doubt this is actually supported); > > ABI impact mitigated by https://phabricator.kde.org/D28562 so we can clean > this up after 20.04. > > > * It needs to decide between Qt smart pointers or STL ones I think, found > > a > > > > bit of both so far (I'd lean toward STL ones but maybe that's just me); > > Also fixed by https://phabricator.kde.org/D28562. > > > * Make DavUrl moveable? > > See above, same as DavCollection and DavItem. > > > * EtagCache probably shouldn't have anything protected, also, why is it a > > > > QObject at all? > > This is why: > https://lxr.kde.org/source/kde/pim/kdepim-runtime/resources/dav/ > resource/akonadietag
Re: New Framework Review: KDAV
Thanks for the review! We are cutting it close again with the 20.04 deadline, but fortunately most of these findings aren't ABI-breaking :) The result was discussed in more detail at the (virtual) PIM sprint, summary below for the record. On Saturday, 4 April 2020 16:20:21 CEST Kevin Ottens wrote: > Hello, > > On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > > during Akademy there was a request to promote KDAV from KDE PIM to > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > > would be classified as a functional tier 3 framework. > > > > So far we have fixed a number of obvious ABI-compatibility issues, removed > > QtXml[Patterns] usage from the public interface and relicensed GPL parts > > (apart from a bit of test code) to LGPL. The next step would be a more > > thorough review to identify changes necessary before becoming a Framework. > > > > To avoid the last minute invasive changes we ended up doing for > > KCalendarCore, I'd propose the following timeline: > > > > - identify and implement all necessary changes to the API and ABI until > > the > > 20.04 Application release (that includes the still necessary move to the > > KF5 library namespace). > > I'm likely late to the party, but here is what I found by looking at KDAV > master today (first day of the KDE PIM sprint): > * There's a few private methods or Q_SLOTS that I'd hide completely by > moving them to the d-pointer, for the slots we're using type safe connects > so they don't even need to be marked as slots at all; Cosmetic with no ABI impact, we can do that post 20.04 still. > * Is it worth making DavCollection moveable? It's only copyable right now; Probably yes, that's new API with no ABI break, so we can do that post 20.04 as well. > * We might want to do something about "ctag" in DavCollection it's a bit > obscure as a name (and the API doc doesn't help), also it seems to not be an > official standard (while being widely supported) and there's the sync-token > mechanism which has a RFC (RFC6578); I have no idea what ctag is (I am only doing the technical work needed to turn this into a framework, I didn't write this library). > * Why isn't DavCollectionModifyJob using DavCollection somehow? (might just > be my ignorance but I find it surprising that it is solely based on a > property mechanism); I think this is to be able to control which properties get changed, rather than sending the full set of them. > * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on > its collectionDiscovered signal, is it really necessary? if it has to stay, > shouldn't be at least documented? or at least a safer type than int? Fixed in https://phabricator.kde.org/D28564 and https://phabricator.kde.org/ D28566 > * DavCollectionsMultiFetchJob is inconsistent as it's not using > Q_DECLARE_PRIVATE; That's due to using KJob as a base directly. Subsequent discussion suggested this should be a KCompositeJob, David is taking care of this. > * KDAV::Error would benefit from more apidox; Yes, not blocked by the 20.04 freeze though. > * Is it worth making DavItem moveable? It's only copyable right now; See above, same as DavCollection. > * Same comment about etag for DavItem than the ctag one for DavCollection See above, same as ctag. > * I'd be tempted to move all the protected methods of DavJobBase on its d- > pointer, the job subclasses would have access to them anyway, it'd make > sense to put them protected in the header only if we expect subclasses > outside of the lib (and I doubt this is actually supported); ABI impact mitigated by https://phabricator.kde.org/D28562 so we can clean this up after 20.04. > * It needs to decide between Qt smart pointers or STL ones I think, found a > bit of both so far (I'd lean toward STL ones but maybe that's just me); Also fixed by https://phabricator.kde.org/D28562. > * Make DavUrl moveable? See above, same as DavCollection and DavItem. > * EtagCache probably shouldn't have anything protected, also, why is it a > QObject at all? This is why: https://lxr.kde.org/source/kde/pim/kdepim-runtime/resources/dav/ resource/akonadietagcache.cpp > * Are we sure we want to return a QLatin1String in ProtocolInfo? this > strike me as an odd choice. Fixed in https://phabricator.kde.org/D28563. > Overall apidox would likely need a big pass of cleanups as well. > I think that's it from me. I hope we managed to address everything on short notice that would require ABI breaks after the 20.04 release (and thus cause a delay of the frameworks move Volker signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KDAV
Hello, On Saturday, 9 November 2019 12:33:54 CEST Volker Krause wrote: > during Akademy there was a request to promote KDAV from KDE PIM to > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > would be classified as a functional tier 3 framework. > > So far we have fixed a number of obvious ABI-compatibility issues, removed > QtXml[Patterns] usage from the public interface and relicensed GPL parts > (apart from a bit of test code) to LGPL. The next step would be a more > thorough review to identify changes necessary before becoming a Framework. > > To avoid the last minute invasive changes we ended up doing for > KCalendarCore, I'd propose the following timeline: > > - identify and implement all necessary changes to the API and ABI until the > 20.04 Application release (that includes the still necessary move to the KF5 > library namespace). I'm likely late to the party, but here is what I found by looking at KDAV master today (first day of the KDE PIM sprint): * There's a few private methods or Q_SLOTS that I'd hide completely by moving them to the d-pointer, for the slots we're using type safe connects so they don't even need to be marked as slots at all; * Is it worth making DavCollection moveable? It's only copyable right now; * We might want to do something about "ctag" in DavCollection it's a bit obscure as a name (and the API doc doesn't help), also it seems to not be an official standard (while being widely supported) and there's the sync-token mechanism which has a RFC (RFC6578); * Why isn't DavCollectionModifyJob using DavCollection somehow? (might just be my ignorance but I find it surprising that it is solely based on a property mechanism); * DavCollections(Multi)FetchJob has a mysterious "protocol" parameter on its collectionDiscovered signal, is it really necessary? if it has to stay, shouldn't be at least documented? or at least a safer type than int? * DavCollectionsMultiFetchJob is inconsistent as it's not using Q_DECLARE_PRIVATE; * KDAV::Error would benefit from more apidox; * Is it worth making DavItem moveable? It's only copyable right now; * Same comment about etag for DavItem than the ctag one for DavCollection * I'd be tempted to move all the protected methods of DavJobBase on its d- pointer, the job subclasses would have access to them anyway, it'd make sense to put them protected in the header only if we expect subclasses outside of the lib (and I doubt this is actually supported); * It needs to decide between Qt smart pointers or STL ones I think, found a bit of both so far (I'd lean toward STL ones but maybe that's just me); * Make DavUrl moveable? * EtagCache probably shouldn't have anything protected, also, why is it a QObject at all? * Are we sure we want to return a QLatin1String in ProtocolInfo? this strike me as an odd choice. Overall apidox would likely need a big pass of cleanups as well. I think that's it from me. Regards. -- Kevin Ottens, http://ervin.ipsquad.net enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KDAV
Hi, > In mostly all files it is not clear if the LGPL or the GPL is meant (stating > "GNU Library General Public License" and referring to the GPL text at the > end of the statement). This license statement is used for all files except > autotests/fakesever.cpp and autotests/fakeserver.h. > Luckily, from the copyright statements there are only 3 copyright holders: > Tobias, Sandro and Gregory. I put all 3 into CC. > > @Tobias, Sandro, Gregory: Can you clarify that the code you are holding > copyright about in this repository is licensed according to > LGPL-2.0-or-later? I'm fine with (re-)licensing this code to LGPL-2.0-or-later. Sandro signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KDAV
On Sonntag, 16. Februar 2020 10:29:42 CET Volker Krause wrote: > On Saturday, 15 February 2020 11:42:57 CET Andreas Cord-Landwehr wrote: > > Hi, sorry for this very late mail, missed the call for reviews... > > > > Would it be possible to do some license clarifications before moving kdav > > into the frameworks section? > > > > In mostly all files it is not clear if the LGPL or the GPL is meant > > (stating "GNU Library General Public License" and referring to the GPL > > text at the end of the statement). This license statement is used for all > > files except autotests/fakesever.cpp and autotests/fakeserver.h. > > Luckily, from the copyright statements there are only 3 copyright holders: > > Tobias, Sandro and Gregory. I put all 3 into CC. > > > > @Tobias, Sandro, Gregory: Can you clarify that the code you are holding > > copyright about in this repository is licensed according to > > LGPL-2.0-or-later? > > Thanks for checking! > > We have relicensing approval to LGPL for those three already in https:// > mail.kde.org/pipermail/kde-pim/2019-September/042912.html (thread continues > into the next month), so it's probably something I messed up while executing > the relicensing :) Great! Maybe the simplest way then is to directly replace all affected headers with the text "SPDX-License-Identifier: LGPL-2.0-or-later" and the ambiguity is gone :) Cheers, Andreas
Re: New Framework Review: KDAV
On Saturday, 15 February 2020 11:42:57 CET Andreas Cord-Landwehr wrote: > Hi, sorry for this very late mail, missed the call for reviews... > > Would it be possible to do some license clarifications before moving kdav > into the frameworks section? > > In mostly all files it is not clear if the LGPL or the GPL is meant (stating > "GNU Library General Public License" and referring to the GPL text at the > end of the statement). This license statement is used for all files except > autotests/fakesever.cpp and autotests/fakeserver.h. > Luckily, from the copyright statements there are only 3 copyright holders: > Tobias, Sandro and Gregory. I put all 3 into CC. > > @Tobias, Sandro, Gregory: Can you clarify that the code you are holding > copyright about in this repository is licensed according to > LGPL-2.0-or-later? Thanks for checking! We have relicensing approval to LGPL for those three already in https:// mail.kde.org/pipermail/kde-pim/2019-September/042912.html (thread continues into the next month), so it's probably something I messed up while executing the relicensing :) Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KDAV
Hi, sorry for this very late mail, missed the call for reviews... Would it be possible to do some license clarifications before moving kdav into the frameworks section? In mostly all files it is not clear if the LGPL or the GPL is meant (stating "GNU Library General Public License" and referring to the GPL text at the end of the statement). This license statement is used for all files except autotests/fakesever.cpp and autotests/fakeserver.h. Luckily, from the copyright statements there are only 3 copyright holders: Tobias, Sandro and Gregory. I put all 3 into CC. @Tobias, Sandro, Gregory: Can you clarify that the code you are holding copyright about in this repository is licensed according to LGPL-2.0-or-later? Cheers, Andreas
Re: New Framework Review: KDAV
On Saturday, 9 November 2019 12:33:54 CET Volker Krause wrote: > Hi, > > during Akademy there was a request to promote KDAV from KDE PIM to > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > would be classified as a functional tier 3 framework. > > So far we have fixed a number of obvious ABI-compatibility issues, removed > QtXml[Patterns] usage from the public interface and relicensed GPL parts > (apart from a bit of test code) to LGPL. The next step would be a more > thorough review to identify changes necessary before becoming a Framework. > > To avoid the last minute invasive changes we ended up doing for > KCalendarCore, I'd propose the following timeline: > > - identify and implement all necessary changes to the API and ABI until the > 20.04 Application release (that includes the still necessary move to the KF5 > library namespace). The rename to the KF5 namespace has been done, if more changes to the ABI are necessary now would be a good time to point those out, so we can integrate them before the 20.04 freeze :) Thanks, Volker > - release KDAV with 20.04 with the final API/ABI that the first KF5 release > will provide as well > - become part of the KF5 release in May or June 2020, release as a drop-in > replacement of the last application release > > In general this is following the same transition process that has been used > for Syndication, KHolidays, KContacts and KCalendarCore as that should cause > minimal disruptions for distributors, but if there's better ideas on how to > handle this, now is a good time to bring this up :) > > Feedback? > > Thanks, > Volker signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KDAV
вс, 10 нояб. 2019 г. в 15:44, David Faure : > > On samedi 9 novembre 2019 21:14:46 CET Alexander Potashev wrote: > > сб, 9 нояб. 2019 г. в 14:37, Volker Krause : > > > during Akademy there was a request to promote KDAV from KDE PIM to > > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > > > would be classified as a functional tier 3 framework. > > > > Hi Volker, > > > > The name "KDAV" suggests that it might implement WebDAV. Do you think > > if it should be renamed to something like "DAVExtensions" or let's say > > "AnyDAV"? > > The name seems fine to me. The substring "DAV" appears just as much in WebDAV > as it does in CalDav/CardDav/GroupDav. So there's no reason to infer "WebDAV" > from "KDAV". > > "Extensions" sounds very optional, and "AnyDAV" looks like yet-another WebDAV- > based protocol in itself. > > The issue you see is that someone looking for WebDAV support might end up > thinking KDAV is the right thing to use? Well, maybe it should be, i.e. this > would probably be the right place for some proper future WebDAV API compared > to using kio_http with metadata directly OK. LGTM as well after your explanation. -- Alexander Potashev
Re: New Framework Review: KDAV
On samedi 9 novembre 2019 21:14:46 CET Alexander Potashev wrote: > сб, 9 нояб. 2019 г. в 14:37, Volker Krause : > > during Akademy there was a request to promote KDAV from KDE PIM to > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > > would be classified as a functional tier 3 framework. > > Hi Volker, > > The name "KDAV" suggests that it might implement WebDAV. Do you think > if it should be renamed to something like "DAVExtensions" or let's say > "AnyDAV"? The name seems fine to me. The substring "DAV" appears just as much in WebDAV as it does in CalDav/CardDav/GroupDav. So there's no reason to infer "WebDAV" from "KDAV". "Extensions" sounds very optional, and "AnyDAV" looks like yet-another WebDAV- based protocol in itself. The issue you see is that someone looking for WebDAV support might end up thinking KDAV is the right thing to use? Well, maybe it should be, i.e. this would probably be the right place for some proper future WebDAV API compared to using kio_http with metadata directly -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New Framework Review: KDAV
сб, 9 нояб. 2019 г. в 14:37, Volker Krause : > during Akademy there was a request to promote KDAV from KDE PIM to Frameworks > for use by Plasma Mobile. KDAV is a framework that implements the CalDav/ > CardDav/GroupDav protocol on top of KIO's WebDav support. It would be > classified as a functional tier 3 framework. Hi Volker, The name "KDAV" suggests that it might implement WebDAV. Do you think if it should be renamed to something like "DAVExtensions" or let's say "AnyDAV"? -- Alexander Potashev
Re: New Framework Review: KDAV
On Saturday, 9 November 2019 18:45:17 CET Christoph Feck wrote: > Hi Volker, > > On 11/09/19 12:33, Volker Krause wrote: > > during Akademy there was a request to promote KDAV from KDE PIM to > > Frameworks for use by Plasma Mobile. KDAV is a framework that implements > > the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It > > would be classified as a functional tier 3 framework. > > Could you clarify if the review is about > https://api.kde.org/kdepim/kdav/html/index.html or > https://api.kde.org/kdepim/kdav2/html/index.html ? good point, sorry about forgetting to add the corresponding links :) Code: https://phabricator.kde.org/source/kdav/ API docs: https://api.kde.org/kdepim/kdav/html/index.html Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New Framework Review: KDAV
Hi Volker, On 11/09/19 12:33, Volker Krause wrote: during Akademy there was a request to promote KDAV from KDE PIM to Frameworks for use by Plasma Mobile. KDAV is a framework that implements the CalDav/ CardDav/GroupDav protocol on top of KIO's WebDav support. It would be classified as a functional tier 3 framework. Could you clarify if the review is about https://api.kde.org/kdepim/kdav/html/index.html or https://api.kde.org/kdepim/kdav2/html/index.html ? Christoph Feck
Re: New framework: KCalCore
El dissabte, 20 de juliol de 2019, a les 12:14:09 CEST, David Faure va escriure: > Hi everyone, > > I just discussed this with Volker IRL and I found a solution to address my > initial concern with the name, the fact that a developer (who's new to all > this) seeing "Cal" might not understand this as meaning Calendar. > At the same time, KCalendar is unclear (does it display a calendar? is it > about calendar systems? etc.). And we already discussed the problem with the > other alternatives (a new developer wouldn't understand Incidences, iCal > isn't > the only format behind all this, etc.) > > So I suggested KCalendarCore, and Volker agreed. > > Unless there are strong objections, we'll go with that. All names are bad to some degree, let's just choose one and make sure the API documentation states clearly what this is for and that should be enough. Cheers, Albert > > Cheers, > David. > > On jeudi 18 juillet 2019 23:24:15 CEST Dominik Haumann wrote: > > To me this sounds as if KCal is the best choice: KCal - a library with iCal > > support. It's short, closest to iCal, and does not clash with calendar > > systems. > > > > Greetings > > Dominik > > > > Allen Winter schrieb am Do., 18. Juli 2019, 18:40: > > > On Thursday, July 18, 2019 12:18:36 PM EDT Volker Krause wrote: > > > > On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote: > > > > > On Tue, Jul 16, 2019 at 6:10 PM Volker Krause wrote: > > > > > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > > > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter > > > > > > wrote: > > > > > > > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > > > > > > > > > With the 19.08 release approaching (and thus the deadline for > > > > > > > > > incompatible > > > > > > > > > changes if we go ahead with this plan), I'd like to raise this > > > > > > again > > > > > > > > > > > > for > > > > > > > > > getting to a decision :) > > > > > > > > > > > > > > > > > > Summary of what happened in the past weeks: > > > > > > > > > - the Person/Attendee slicing issue was fixed by making both > > > > > > > > > independent > > > > > > > > > types - several "leaf" types were turned into implicitly > > > > > > > > > shared > > > > > > > > > value > > > > > > > > > types rather than being used heap-allocated inside shared > > > > > > pointers > > > > > > > > > > > > - the dependency on the Akonadi supertrait.h header file was > > > > > > removed > > > > > > > > > > > > - the virtual_hook usage in the incidence de/serialization > > > > > > code was > > > > > > > > > > > > replaced by new virtual methods > > > > > > > > > > > > > > > > > > Unless I missed something, the remaining unaddressed feedback > > > > > > is > > > > > > > > > > > > down > > > > > > > > > to: > > > > > > > > > - Rename KCalCore to something else. I'm ok with executing the > > > > > > > > > rename, > > > > > > > > > but > > > > > > > > > somebody needs to tell me the new name :) > > > > > > > > > > > > > > > > I don't remember the reason for changing the name. > > > > > > > > I vote for not changing the name. KCalCore is as good as any, > > > > > > > > imo > > > > > > > > > > > > > > > > > - Alexander P's fundamental objections to the current KCalCore > > > > > > API > > > > > > > > > > > > How do we proceed? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Volker > > > > > > > > > > > > > > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM > > > > > > to > > > > > > > > > > > > > KF5. > > > > > > > > > > > > > > > > > > > > KCalCore is an implementation of the iCalendar standard > > > > > > based on > > > > > > > > > > > > > libical, > > > > > > > > > > covering the data model, input/output and the rather complex > > > > > > > > > > recurrence > > > > > > > > > > algorithms defined in that standard. It's used outside of > > > > > > KDE PIM > > > > > > > > > > > > > as > > > > > > > > > > well, > > > > > > > > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > > > > > > > > > > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1 > > > > > > > > > > functional > > > > > > > > > > framework. > > > > > > > > > > > > > > > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 > > > > > > era, so > > > > > > > > > > > > > it's well prepared for complying with the API and ABI > > > > > > guarantees. > > > > > > > > > > > > > I'd suggest the same timeline as proposed for KContacts [1]. > > > > > > > > > > During > > > > > > > > > > the PIM > > > > > > > > > > sprint we did a number of fixes and cleanups as part of the > > > > > > review > > > > > > > > > > > > > for > > > > > > > > > > KF5 > > > > > > > > > > that make 19.08 the earliest release after which we can > > > > > > switch as > > > > > > > > > > > > > well, so > > > > > > >
Re: New framework: KCalCore
On samedi 20 juillet 2019 17:02:40 CEST Alexander Potashev wrote: > сб, 20 июл. 2019 г. в 13:14, David Faure : > > I just discussed this with Volker IRL and I found a solution to address my > > initial concern with the name, the fact that a developer (who's new to all > > this) seeing "Cal" might not understand this as meaning Calendar. > > At the same time, KCalendar is unclear (does it display a calendar? is it > > about calendar systems? etc.). And we already discussed the problem with > > the other alternatives (a new developer wouldn't understand Incidences, > > iCal isn't the only format behind all this, etc.) > > > > So I suggested KCalendarCore, and Volker agreed. > > Hi David, > > How about KCalendarFormats? Sounds like just a repository of formats, which this isn't. > In my opinion KCalendarCore is bad because it would suggest there must > be other KCalendar[...] libraries that depend on KCalendarCore, in a > manner similar to > - QtCore <- QtGui,QtQuick and > - KIOCore <- KIOWidgets,KIOGui. The EventViews library (in kdepim) is exactly such a library. It could be called KCalendarWidgets or KCalendarViews :-) But even if it's not named like that, that doesn't make the "Core" in KCalendarCore wrong at all. (The todo view is in korganizer itself) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KCalCore
сб, 20 июл. 2019 г. в 13:14, David Faure : > I just discussed this with Volker IRL and I found a solution to address my > initial concern with the name, the fact that a developer (who's new to all > this) seeing "Cal" might not understand this as meaning Calendar. > At the same time, KCalendar is unclear (does it display a calendar? is it > about calendar systems? etc.). And we already discussed the problem with the > other alternatives (a new developer wouldn't understand Incidences, iCal isn't > the only format behind all this, etc.) > > So I suggested KCalendarCore, and Volker agreed. Hi David, How about KCalendarFormats? In my opinion KCalendarCore is bad because it would suggest there must be other KCalendar[...] libraries that depend on KCalendarCore, in a manner similar to - QtCore <- QtGui,QtQuick and - KIOCore <- KIOWidgets,KIOGui. -- Alexander Potashev
Re: New framework: KCalCore
Hi everyone, I just discussed this with Volker IRL and I found a solution to address my initial concern with the name, the fact that a developer (who's new to all this) seeing "Cal" might not understand this as meaning Calendar. At the same time, KCalendar is unclear (does it display a calendar? is it about calendar systems? etc.). And we already discussed the problem with the other alternatives (a new developer wouldn't understand Incidences, iCal isn't the only format behind all this, etc.) So I suggested KCalendarCore, and Volker agreed. Unless there are strong objections, we'll go with that. Cheers, David. On jeudi 18 juillet 2019 23:24:15 CEST Dominik Haumann wrote: > To me this sounds as if KCal is the best choice: KCal - a library with iCal > support. It's short, closest to iCal, and does not clash with calendar > systems. > > Greetings > Dominik > > Allen Winter schrieb am Do., 18. Juli 2019, 18:40: > > On Thursday, July 18, 2019 12:18:36 PM EDT Volker Krause wrote: > > > On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote: > > > > On Tue, Jul 16, 2019 at 6:10 PM Volker Krause wrote: > > > > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter > > > > wrote: > > > > > > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > > > > > > > > With the 19.08 release approaching (and thus the deadline for > > > > > > > > incompatible > > > > > > > > changes if we go ahead with this plan), I'd like to raise this > > > > again > > > > > > > > > > for > > > > > > > > getting to a decision :) > > > > > > > > > > > > > > > > Summary of what happened in the past weeks: > > > > > > > > - the Person/Attendee slicing issue was fixed by making both > > > > > > > > independent > > > > > > > > types - several "leaf" types were turned into implicitly > > > > > > > > shared > > > > > > > > value > > > > > > > > types rather than being used heap-allocated inside shared > > > > pointers > > > > > > > > > > - the dependency on the Akonadi supertrait.h header file was > > > > removed > > > > > > > > > > - the virtual_hook usage in the incidence de/serialization > > > > code was > > > > > > > > > > replaced by new virtual methods > > > > > > > > > > > > > > > > Unless I missed something, the remaining unaddressed feedback > > > > is > > > > > > > > > > down > > > > > > > > to: > > > > > > > > - Rename KCalCore to something else. I'm ok with executing the > > > > > > > > rename, > > > > > > > > but > > > > > > > > somebody needs to tell me the new name :) > > > > > > > > > > > > > > I don't remember the reason for changing the name. > > > > > > > I vote for not changing the name. KCalCore is as good as any, > > > > > > > imo > > > > > > > > > > > > > > > - Alexander P's fundamental objections to the current KCalCore > > > > API > > > > > > > > > > How do we proceed? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Volker > > > > > > > > > > > > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM > > > > to > > > > > > > > > > > KF5. > > > > > > > > > > > > > > > > > > KCalCore is an implementation of the iCalendar standard > > > > based on > > > > > > > > > > > libical, > > > > > > > > > covering the data model, input/output and the rather complex > > > > > > > > > recurrence > > > > > > > > > algorithms defined in that standard. It's used outside of > > > > KDE PIM > > > > > > > > > > > as > > > > > > > > > well, > > > > > > > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > > > > > > > > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1 > > > > > > > > > functional > > > > > > > > > framework. > > > > > > > > > > > > > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 > > > > era, so > > > > > > > > > > > it's well prepared for complying with the API and ABI > > > > guarantees. > > > > > > > > > > > I'd suggest the same timeline as proposed for KContacts [1]. > > > > > > > > > During > > > > > > > > > the PIM > > > > > > > > > sprint we did a number of fixes and cleanups as part of the > > > > review > > > > > > > > > > > for > > > > > > > > > KF5 > > > > > > > > > that make 19.08 the earliest release after which we can > > > > switch as > > > > > > > > > > > well, so > > > > > > > > > we are looking at a switch in Sep/Oct this year. > > > > > > > > > > > > If you don't remember, just scroll up a bit. :P > > > > > > > > > > > > I went through the thread and that's what we said: > > > > > > - It's a framework to understand the ical format, this is not > > > > conveyed > > > > > > > > by the current name > > > > > > - The Core postfix doesn't add anything and we are already using > > > > > > it > > > > > > for differentiating different framework targets (e.g. > > > > KF5::ConfigCore > > > > > > > >
Re: New framework: KCalCore
To me this sounds as if KCal is the best choice: KCal - a library with iCal support. It's short, closest to iCal, and does not clash with calendar systems. Greetings Dominik Allen Winter schrieb am Do., 18. Juli 2019, 18:40: > On Thursday, July 18, 2019 12:18:36 PM EDT Volker Krause wrote: > > On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote: > > > On Tue, Jul 16, 2019 at 6:10 PM Volker Krause wrote: > > > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter > wrote: > > > > > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > > > > > > > With the 19.08 release approaching (and thus the deadline for > > > > > > > incompatible > > > > > > > changes if we go ahead with this plan), I'd like to raise this > again > > > > > > > for > > > > > > > getting to a decision :) > > > > > > > > > > > > > > Summary of what happened in the past weeks: > > > > > > > - the Person/Attendee slicing issue was fixed by making both > > > > > > > independent > > > > > > > types - several "leaf" types were turned into implicitly shared > > > > > > > value > > > > > > > types rather than being used heap-allocated inside shared > pointers > > > > > > > - the dependency on the Akonadi supertrait.h header file was > removed > > > > > > > - the virtual_hook usage in the incidence de/serialization > code was > > > > > > > replaced by new virtual methods > > > > > > > > > > > > > > Unless I missed something, the remaining unaddressed feedback > is > > > > > > > down > > > > > > > to: > > > > > > > - Rename KCalCore to something else. I'm ok with executing the > > > > > > > rename, > > > > > > > but > > > > > > > somebody needs to tell me the new name :) > > > > > > > > > > > > I don't remember the reason for changing the name. > > > > > > I vote for not changing the name. KCalCore is as good as any, imo > > > > > > > > > > > > > - Alexander P's fundamental objections to the current KCalCore > API > > > > > > > > > > > > > > How do we proceed? > > > > > > > > > > > > > > Thanks, > > > > > > > Volker > > > > > > > > > > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM > to > > > > > > > > KF5. > > > > > > > > > > > > > > > > KCalCore is an implementation of the iCalendar standard > based on > > > > > > > > libical, > > > > > > > > covering the data model, input/output and the rather complex > > > > > > > > recurrence > > > > > > > > algorithms defined in that standard. It's used outside of > KDE PIM > > > > > > > > as > > > > > > > > well, > > > > > > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > > > > > > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1 > > > > > > > > functional > > > > > > > > framework. > > > > > > > > > > > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 > era, so > > > > > > > > it's well prepared for complying with the API and ABI > guarantees. > > > > > > > > > > > > > > > > I'd suggest the same timeline as proposed for KContacts [1]. > > > > > > > > During > > > > > > > > the PIM > > > > > > > > sprint we did a number of fixes and cleanups as part of the > review > > > > > > > > for > > > > > > > > KF5 > > > > > > > > that make 19.08 the earliest release after which we can > switch as > > > > > > > > well, so > > > > > > > > we are looking at a switch in Sep/Oct this year. > > > > > > > > > > If you don't remember, just scroll up a bit. :P > > > > > > > > > > I went through the thread and that's what we said: > > > > > - It's a framework to understand the ical format, this is not > conveyed > > > > > by the current name > > > > > - The Core postfix doesn't add anything and we are already using it > > > > > for differentiating different framework targets (e.g. > KF5::ConfigCore > > > > > and KF5::ConfigGui) > > > > > > > > "Core" had exactly the same meaning here when the widget parts were > split > > > > out during the Nokia times. Less relevant today probably. > > > > > > > > > I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents, > > > > > KCalendarIncidences being suggested. It's not going to be me who > > > > > chooses one though. > > > > > > > > If those are the options I'd vote for KCal or KCalendar, KiCal is too > > > > close to KiCad IMHO, and the rest is just unnecessarily long. Anyway, > > > > let's please have a quick decision on this, it's going to be a large > > > > change, so I'd like to get this in ASAP. > > > > > > > > Thanks, > > > > Volker > > > > > > I tend to agree. If so I'd suggest KCalendar. Following KContacts > > > (which should possibly be KVCards, but we assume vcards are the one > > > and only format ever for contacts). > > > > It's not necessarily the one and only file format (and support for other > file > > formats is possible in those libraries, KCalCore e.g. can read some iCal > > predecessor too), b
Re: New framework: KCalCore
On Thursday, July 18, 2019 12:18:36 PM EDT Volker Krause wrote: > On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote: > > On Tue, Jul 16, 2019 at 6:10 PM Volker Krause wrote: > > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter wrote: > > > > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > > > > > > With the 19.08 release approaching (and thus the deadline for > > > > > > incompatible > > > > > > changes if we go ahead with this plan), I'd like to raise this again > > > > > > for > > > > > > getting to a decision :) > > > > > > > > > > > > Summary of what happened in the past weeks: > > > > > > - the Person/Attendee slicing issue was fixed by making both > > > > > > independent > > > > > > types - several "leaf" types were turned into implicitly shared > > > > > > value > > > > > > types rather than being used heap-allocated inside shared pointers > > > > > > - the dependency on the Akonadi supertrait.h header file was removed > > > > > > - the virtual_hook usage in the incidence de/serialization code was > > > > > > replaced by new virtual methods > > > > > > > > > > > > Unless I missed something, the remaining unaddressed feedback is > > > > > > down > > > > > > to: > > > > > > - Rename KCalCore to something else. I'm ok with executing the > > > > > > rename, > > > > > > but > > > > > > somebody needs to tell me the new name :) > > > > > > > > > > I don't remember the reason for changing the name. > > > > > I vote for not changing the name. KCalCore is as good as any, imo > > > > > > > > > > > - Alexander P's fundamental objections to the current KCalCore API > > > > > > > > > > > > How do we proceed? > > > > > > > > > > > > Thanks, > > > > > > Volker > > > > > > > > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to > > > > > > > KF5. > > > > > > > > > > > > > > KCalCore is an implementation of the iCalendar standard based on > > > > > > > libical, > > > > > > > covering the data model, input/output and the rather complex > > > > > > > recurrence > > > > > > > algorithms defined in that standard. It's used outside of KDE PIM > > > > > > > as > > > > > > > well, > > > > > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > > > > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1 > > > > > > > functional > > > > > > > framework. > > > > > > > > > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so > > > > > > > it's well prepared for complying with the API and ABI guarantees. > > > > > > > > > > > > > > I'd suggest the same timeline as proposed for KContacts [1]. > > > > > > > During > > > > > > > the PIM > > > > > > > sprint we did a number of fixes and cleanups as part of the review > > > > > > > for > > > > > > > KF5 > > > > > > > that make 19.08 the earliest release after which we can switch as > > > > > > > well, so > > > > > > > we are looking at a switch in Sep/Oct this year. > > > > > > > > If you don't remember, just scroll up a bit. :P > > > > > > > > I went through the thread and that's what we said: > > > > - It's a framework to understand the ical format, this is not conveyed > > > > by the current name > > > > - The Core postfix doesn't add anything and we are already using it > > > > for differentiating different framework targets (e.g. KF5::ConfigCore > > > > and KF5::ConfigGui) > > > > > > "Core" had exactly the same meaning here when the widget parts were split > > > out during the Nokia times. Less relevant today probably. > > > > > > > I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents, > > > > KCalendarIncidences being suggested. It's not going to be me who > > > > chooses one though. > > > > > > If those are the options I'd vote for KCal or KCalendar, KiCal is too > > > close to KiCad IMHO, and the rest is just unnecessarily long. Anyway, > > > let's please have a quick decision on this, it's going to be a large > > > change, so I'd like to get this in ASAP. > > > > > > Thanks, > > > Volker > > > > I tend to agree. If so I'd suggest KCalendar. Following KContacts > > (which should possibly be KVCards, but we assume vcards are the one > > and only format ever for contacts). > > It's not necessarily the one and only file format (and support for other file > formats is possible in those libraries, KCalCore e.g. can read some iCal > predecessor too), but both vcard and ical have effectively been the one > ubiquitous data model in the past two decades for this kind of data. That > IMHO > justifies the very generic naming :) > > In the earlier discussion David Jarvie raised concerns about the KCalendar > name being misleading towards a calendar systems related library. Valid > point, > but IMHO the topic of calendar systems is more specialized (and typically an > implementation detail o
Re: New framework: KCalCore
On Wednesday, 17 July 2019 01:51:42 CEST Aleix Pol wrote: > On Tue, Jul 16, 2019 at 6:10 PM Volker Krause wrote: > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter wrote: > > > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > > > > > With the 19.08 release approaching (and thus the deadline for > > > > > incompatible > > > > > changes if we go ahead with this plan), I'd like to raise this again > > > > > for > > > > > getting to a decision :) > > > > > > > > > > Summary of what happened in the past weeks: > > > > > - the Person/Attendee slicing issue was fixed by making both > > > > > independent > > > > > types - several "leaf" types were turned into implicitly shared > > > > > value > > > > > types rather than being used heap-allocated inside shared pointers > > > > > - the dependency on the Akonadi supertrait.h header file was removed > > > > > - the virtual_hook usage in the incidence de/serialization code was > > > > > replaced by new virtual methods > > > > > > > > > > Unless I missed something, the remaining unaddressed feedback is > > > > > down > > > > > to: > > > > > - Rename KCalCore to something else. I'm ok with executing the > > > > > rename, > > > > > but > > > > > somebody needs to tell me the new name :) > > > > > > > > I don't remember the reason for changing the name. > > > > I vote for not changing the name. KCalCore is as good as any, imo > > > > > > > > > - Alexander P's fundamental objections to the current KCalCore API > > > > > > > > > > How do we proceed? > > > > > > > > > > Thanks, > > > > > Volker > > > > > > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > > > > > Hi, > > > > > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to > > > > > > KF5. > > > > > > > > > > > > KCalCore is an implementation of the iCalendar standard based on > > > > > > libical, > > > > > > covering the data model, input/output and the rather complex > > > > > > recurrence > > > > > > algorithms defined in that standard. It's used outside of KDE PIM > > > > > > as > > > > > > well, > > > > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1 > > > > > > functional > > > > > > framework. > > > > > > > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so > > > > > > it's well prepared for complying with the API and ABI guarantees. > > > > > > > > > > > > I'd suggest the same timeline as proposed for KContacts [1]. > > > > > > During > > > > > > the PIM > > > > > > sprint we did a number of fixes and cleanups as part of the review > > > > > > for > > > > > > KF5 > > > > > > that make 19.08 the earliest release after which we can switch as > > > > > > well, so > > > > > > we are looking at a switch in Sep/Oct this year. > > > > > > If you don't remember, just scroll up a bit. :P > > > > > > I went through the thread and that's what we said: > > > - It's a framework to understand the ical format, this is not conveyed > > > by the current name > > > - The Core postfix doesn't add anything and we are already using it > > > for differentiating different framework targets (e.g. KF5::ConfigCore > > > and KF5::ConfigGui) > > > > "Core" had exactly the same meaning here when the widget parts were split > > out during the Nokia times. Less relevant today probably. > > > > > I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents, > > > KCalendarIncidences being suggested. It's not going to be me who > > > chooses one though. > > > > If those are the options I'd vote for KCal or KCalendar, KiCal is too > > close to KiCad IMHO, and the rest is just unnecessarily long. Anyway, > > let's please have a quick decision on this, it's going to be a large > > change, so I'd like to get this in ASAP. > > > > Thanks, > > Volker > > I tend to agree. If so I'd suggest KCalendar. Following KContacts > (which should possibly be KVCards, but we assume vcards are the one > and only format ever for contacts). It's not necessarily the one and only file format (and support for other file formats is possible in those libraries, KCalCore e.g. can read some iCal predecessor too), but both vcard and ical have effectively been the one ubiquitous data model in the past two decades for this kind of data. That IMHO justifies the very generic naming :) In the earlier discussion David Jarvie raised concerns about the KCalendar name being misleading towards a calendar systems related library. Valid point, but IMHO the topic of calendar systems is more specialized (and typically an implementation detail of other libs), compared to the calendar conecpt KCalCore is referring to, so KCalendar vs KCalendarSystems would IMHO be acceptable. Other views/opinions on this? Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Tue, Jul 16, 2019 at 6:10 PM Volker Krause wrote: > > On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter wrote: > > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > > > > With the 19.08 release approaching (and thus the deadline for > > > > incompatible > > > > changes if we go ahead with this plan), I'd like to raise this again for > > > > getting to a decision :) > > > > > > > > Summary of what happened in the past weeks: > > > > - the Person/Attendee slicing issue was fixed by making both independent > > > > types - several "leaf" types were turned into implicitly shared value > > > > types rather than being used heap-allocated inside shared pointers > > > > - the dependency on the Akonadi supertrait.h header file was removed > > > > - the virtual_hook usage in the incidence de/serialization code was > > > > replaced by new virtual methods > > > > > > > > Unless I missed something, the remaining unaddressed feedback is down > > > > to: > > > > - Rename KCalCore to something else. I'm ok with executing the rename, > > > > but > > > > somebody needs to tell me the new name :) > > > > > > I don't remember the reason for changing the name. > > > I vote for not changing the name. KCalCore is as good as any, imo > > > > > > > - Alexander P's fundamental objections to the current KCalCore API > > > > > > > > How do we proceed? > > > > > > > > Thanks, > > > > Volker > > > > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > > > > Hi, > > > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > > > > > KCalCore is an implementation of the iCalendar standard based on > > > > > libical, > > > > > covering the data model, input/output and the rather complex > > > > > recurrence > > > > > algorithms defined in that standard. It's used outside of KDE PIM as > > > > > well, > > > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1 functional > > > > > framework. > > > > > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so > > > > > it's well prepared for complying with the API and ABI guarantees. > > > > > > > > > > I'd suggest the same timeline as proposed for KContacts [1]. During > > > > > the PIM > > > > > sprint we did a number of fixes and cleanups as part of the review for > > > > > KF5 > > > > > that make 19.08 the earliest release after which we can switch as > > > > > well, so > > > > > we are looking at a switch in Sep/Oct this year. > > > > If you don't remember, just scroll up a bit. :P > > > > I went through the thread and that's what we said: > > - It's a framework to understand the ical format, this is not conveyed > > by the current name > > - The Core postfix doesn't add anything and we are already using it > > for differentiating different framework targets (e.g. KF5::ConfigCore > > and KF5::ConfigGui) > > "Core" had exactly the same meaning here when the widget parts were split out > during the Nokia times. Less relevant today probably. > > > I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents, > > KCalendarIncidences being suggested. It's not going to be me who > > chooses one though. > > If those are the options I'd vote for KCal or KCalendar, KiCal is too close to > KiCad IMHO, and the rest is just unnecessarily long. Anyway, let's please have > a quick decision on this, it's going to be a large change, so I'd like to get > this in ASAP. > > Thanks, > Volker I tend to agree. If so I'd suggest KCalendar. Following KContacts (which should possibly be KVCards, but we assume vcards are the one and only format ever for contacts). Aleix
Re: New framework: KContacts
On Saturday, 6 April 2019 18:01:09 CEST Volker Krause wrote: > Hi, > > I'd like to propose KContacts for review to move from KDE PIM to KF5. > > KContacts is essentially an implementation of the vCard standard, covering > the data model as well as parsing and creating of vCard files. As the > recent CI issue showed it's used outside of KDE PIM as well, therefore we > would particularly benefit from the KF5 stability guarantees. > > KContacts depends on KConfig, KCodecs, KCoreAddons and KI18n, making it a > Tier 2 functional framework. > > KContacts used to be part of kdelibs during the 2 and 3 era under the name > "kabc", and part of kdepimlibs in the 4 era, so it's very well prepared for > complying with the API and ABI guarantees. > > To have a smooth as possible transition the proposed timeline would be: > - complete the review and possibly required adjustments before the 19.08 > freeze > - do one final release as part of KDE PIM with 19.08, with the final ABI and > library name for KF5 > - after 19.08 (so Sep or Oct 2019), release it with KF5, which will then be > a drop-in replacement for the KDE PIM release. > > This approach has already successfully been used for KHolidays and > Syndication. > > We did a review at the currently ongoing PIM sprint, which resulted in > removal of some ancient unused cruft (D20270, D20273, D20274, D20275, > D20276) which did technically change the ABI, therefore the transition > after 19.08 rather than 19.04. With the 19.08 deadline approaching I'd also like to raise this again for a decision :) I'm not aware of any unaddressed feedback, main changes in the meantime: - a number of duplicated or string-based code in applications using this was upstreamed into KContacts with proper API - several types got Q_GADGET/Q_PROPERTY annotations for direct use in QML or Grantlee (now used directly by KAddressBook's display and printing code) - custom fields for messaging addresses are now converted to standard Impp fields, improving e.g. compatibility with Nextcloud and removing error-prone application code Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Monday, 15 July 2019 18:43:42 CEST Aleix Pol wrote: > On Fri, Jul 12, 2019 at 9:03 PM Allen Winter wrote: > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > > > With the 19.08 release approaching (and thus the deadline for > > > incompatible > > > changes if we go ahead with this plan), I'd like to raise this again for > > > getting to a decision :) > > > > > > Summary of what happened in the past weeks: > > > - the Person/Attendee slicing issue was fixed by making both independent > > > types - several "leaf" types were turned into implicitly shared value > > > types rather than being used heap-allocated inside shared pointers > > > - the dependency on the Akonadi supertrait.h header file was removed > > > - the virtual_hook usage in the incidence de/serialization code was > > > replaced by new virtual methods > > > > > > Unless I missed something, the remaining unaddressed feedback is down > > > to: > > > - Rename KCalCore to something else. I'm ok with executing the rename, > > > but > > > somebody needs to tell me the new name :) > > > > I don't remember the reason for changing the name. > > I vote for not changing the name. KCalCore is as good as any, imo > > > > > - Alexander P's fundamental objections to the current KCalCore API > > > > > > How do we proceed? > > > > > > Thanks, > > > Volker > > > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > > > Hi, > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > > > KCalCore is an implementation of the iCalendar standard based on > > > > libical, > > > > covering the data model, input/output and the rather complex > > > > recurrence > > > > algorithms defined in that standard. It's used outside of KDE PIM as > > > > well, > > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1 functional > > > > framework. > > > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so > > > > it's well prepared for complying with the API and ABI guarantees. > > > > > > > > I'd suggest the same timeline as proposed for KContacts [1]. During > > > > the PIM > > > > sprint we did a number of fixes and cleanups as part of the review for > > > > KF5 > > > > that make 19.08 the earliest release after which we can switch as > > > > well, so > > > > we are looking at a switch in Sep/Oct this year. > > If you don't remember, just scroll up a bit. :P > > I went through the thread and that's what we said: > - It's a framework to understand the ical format, this is not conveyed > by the current name > - The Core postfix doesn't add anything and we are already using it > for differentiating different framework targets (e.g. KF5::ConfigCore > and KF5::ConfigGui) "Core" had exactly the same meaning here when the widget parts were split out during the Nokia times. Less relevant today probably. > I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents, > KCalendarIncidences being suggested. It's not going to be me who > chooses one though. If those are the options I'd vote for KCal or KCalendar, KiCal is too close to KiCad IMHO, and the rest is just unnecessarily long. Anyway, let's please have a quick decision on this, it's going to be a large change, so I'd like to get this in ASAP. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Fri, Jul 12, 2019 at 9:03 PM Allen Winter wrote: > > On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > > With the 19.08 release approaching (and thus the deadline for incompatible > > changes if we go ahead with this plan), I'd like to raise this again for > > getting to a decision :) > > > > Summary of what happened in the past weeks: > > - the Person/Attendee slicing issue was fixed by making both independent > > types > > - several "leaf" types were turned into implicitly shared value types rather > > than being used heap-allocated inside shared pointers > > - the dependency on the Akonadi supertrait.h header file was removed > > - the virtual_hook usage in the incidence de/serialization code was replaced > > by new virtual methods > > > > Unless I missed something, the remaining unaddressed feedback is down to: > > - Rename KCalCore to something else. I'm ok with executing the rename, but > > somebody needs to tell me the new name :) > > I don't remember the reason for changing the name. > I vote for not changing the name. KCalCore is as good as any, imo > > > - Alexander P's fundamental objections to the current KCalCore API > > > > How do we proceed? > > > > Thanks, > > Volker > > > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > > Hi, > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > KCalCore is an implementation of the iCalendar standard based on libical, > > > covering the data model, input/output and the rather complex recurrence > > > algorithms defined in that standard. It's used outside of KDE PIM as well, > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > KCalCore depends on Qt and libical only, making it a Tier 1 functional > > > framework. > > > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so it's > > > well > > > prepared for complying with the API and ABI guarantees. > > > > > > I'd suggest the same timeline as proposed for KContacts [1]. During the > > > PIM > > > sprint we did a number of fixes and cleanups as part of the review for KF5 > > > that make 19.08 the earliest release after which we can switch as well, so > > > we are looking at a switch in Sep/Oct this year. If you don't remember, just scroll up a bit. :P I went through the thread and that's what we said: - It's a framework to understand the ical format, this is not conveyed by the current name - The Core postfix doesn't add anything and we are already using it for differentiating different framework targets (e.g. KF5::ConfigCore and KF5::ConfigGui) I see KCal, KCalendar, KiCalendar, KiCal, KCalendarEvents, KCalendarIncidences being suggested. It's not going to be me who chooses one though. ;) Aleix
Re: New framework: KCalCore
пт, 12 июл. 2019 г. в 19:25, Volker Krause : > - Alexander P's fundamental objections to the current KCalCore API After studing kcalcore sources again and also its usages with LXR, I realize that i would be painful to remove the FileStorage functionality because it implements format detection, and it's hard to decide in what use cases we can or cannot drop format detection (vCal1 vs iCal2). For use cases where file operations have to be asynchronous, the FileStorage layer can be ignored and ICalFormat::fromRawString()/fromString()/toString() used directly instead (however I didn't try this approach yet because it's uncommon). All in all, I agree to follow the golden rule "if it works, don't touch it". -- Alexander Potashev
Re: New framework: KCalCore
On Friday, July 12, 2019 12:23:58 PM EDT Volker Krause wrote: > With the 19.08 release approaching (and thus the deadline for incompatible > changes if we go ahead with this plan), I'd like to raise this again for > getting to a decision :) > > Summary of what happened in the past weeks: > - the Person/Attendee slicing issue was fixed by making both independent types > - several "leaf" types were turned into implicitly shared value types rather > than being used heap-allocated inside shared pointers > - the dependency on the Akonadi supertrait.h header file was removed > - the virtual_hook usage in the incidence de/serialization code was replaced > by new virtual methods > > Unless I missed something, the remaining unaddressed feedback is down to: > - Rename KCalCore to something else. I'm ok with executing the rename, but > somebody needs to tell me the new name :) I don't remember the reason for changing the name. I vote for not changing the name. KCalCore is as good as any, imo > - Alexander P's fundamental objections to the current KCalCore API > > How do we proceed? > > Thanks, > Volker > > On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > > Hi, > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > KCalCore is an implementation of the iCalendar standard based on libical, > > covering the data model, input/output and the rather complex recurrence > > algorithms defined in that standard. It's used outside of KDE PIM as well, > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > KCalCore depends on Qt and libical only, making it a Tier 1 functional > > framework. > > > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so it's well > > prepared for complying with the API and ABI guarantees. > > > > I'd suggest the same timeline as proposed for KContacts [1]. During the PIM > > sprint we did a number of fixes and cleanups as part of the review for KF5 > > that make 19.08 the earliest release after which we can switch as well, so > > we are looking at a switch in Sep/Oct this year. > > > > > > Thanks, > > Volker > > > > [1] > > https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html > >
Re: New framework: KCalCore
With the 19.08 release approaching (and thus the deadline for incompatible changes if we go ahead with this plan), I'd like to raise this again for getting to a decision :) Summary of what happened in the past weeks: - the Person/Attendee slicing issue was fixed by making both independent types - several "leaf" types were turned into implicitly shared value types rather than being used heap-allocated inside shared pointers - the dependency on the Akonadi supertrait.h header file was removed - the virtual_hook usage in the incidence de/serialization code was replaced by new virtual methods Unless I missed something, the remaining unaddressed feedback is down to: - Rename KCalCore to something else. I'm ok with executing the rename, but somebody needs to tell me the new name :) - Alexander P's fundamental objections to the current KCalCore API How do we proceed? Thanks, Volker On Sunday, 7 April 2019 14:45:09 CEST Volker Krause wrote: > Hi, > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > KCalCore is an implementation of the iCalendar standard based on libical, > covering the data model, input/output and the rather complex recurrence > algorithms defined in that standard. It's used outside of KDE PIM as well, > e.g. by Zanshin or the Plasma Mobile calendar app. > > KCalCore depends on Qt and libical only, making it a Tier 1 functional > framework. > > KCalCore used to be part of part of kdepimlibs in the KDE4 era, so it's well > prepared for complying with the API and ABI guarantees. > > I'd suggest the same timeline as proposed for KContacts [1]. During the PIM > sprint we did a number of fixes and cleanups as part of the review for KF5 > that make 19.08 the earliest release after which we can switch as well, so > we are looking at a switch in Sep/Oct this year. > > > Thanks, > Volker > > [1] > https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Tue, Apr 30, 2019 at 8:52 PM Allen Winter wrote: > > Clazy is complaining about missing assign operators. Do we care? > If so, I can take a look at adding them or if anyone else wants to do that. > -Allen That will be fixed in Qt. Regards, Sergio Martins
Re: New framework: KCalCore
Clazy is complaining about missing assign operators. Do we care?
If so, I can take a look at adding them or if anyone else wants to do that.
-Allen
./src/calendar.cpp
line 305: for (it = vals.constBegin(); it != vals.constEnd(); ++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
./src/calfilter.cpp
line 161: for (it = attendees.begin(); it != attendees.end(); ++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
./src/freebusy.cpp
line 120: for (it = eventList.constBegin(); it != eventList.constEnd();
++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has copy-ctor
but no assign operator
line 299: for (it = periods.constBegin(); it != periods.constEnd(); ++it) {
=> Using assign operator but class
QTypedArrayData::const_iterator has copy-ctor but no assign
operator
./src/icalformat_p.cpp
line 628: for (atIt = attachments.constBegin(); atIt !=
attachments.constEnd(); ++atIt) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
./src/icaltimezones.cpp
line 493: begin = phase.transitions.cbegin();
=> Using assign operator but class
QTypedArrayData::const_iterator has copy-ctor but no assign operator
./src/incidencebase.cpp
line 513: for (it = d->mAttendees.constBegin(); it !=
d->mAttendees.constEnd(); ++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
line 530: for (itA = d->mAttendees.constBegin(); itA !=
d->mAttendees.constEnd(); ++itA) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
line 544: for (it = d->mAttendees.constBegin(); it !=
d->mAttendees.constEnd(); ++it) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has
copy-ctor but no assign operator
./src/vcalformat.cpp
line 1603: for (eIt = d->mEventsRelate.constBegin(); eIt !=
d->mEventsRelate.constEnd(); ++eIt) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has copy-ctor
but no assign operator
line 1607: for (tIt = d->mTodosRelate.constBegin(); tIt !=
d->mTodosRelate.constEnd(); ++tIt) {
=> Using assign operator but class
QTypedArrayData >::const_iterator has copy-ctor
but no assign operator
Sunday, April 7, 2019 8:45:09 AM EDT Volker Krause wrote:
> Hi,
>
> I'd like to propose KCalCore for review to move from KDE PIM to KF5.
>
> KCalCore is an implementation of the iCalendar standard based on libical,
> covering the data model, input/output and the rather complex recurrence
> algorithms defined in that standard. It's used outside of KDE PIM as well,
> e.g. by Zanshin or the Plasma Mobile calendar app.
>
> KCalCore depends on Qt and libical only, making it a Tier 1 functional
> framework.
>
> KCalCore used to be part of part of kdepimlibs in the KDE4 era, so it's well
> prepared for complying with the API and ABI guarantees.
>
> I'd suggest the same timeline as proposed for KContacts [1]. During the PIM
> sprint we did a number of fixes and cleanups as part of the review for KF5
> that make 19.08 the earliest release after which we can switch as well, so we
> are looking at a switch in Sep/Oct this year.
>
>
> Thanks,
> Volker
>
> [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2019-April/084057.html
Re: New framework: KCalCore
On Wed, Apr 17, 2019 at 6:40 PM Volker Krause wrote: > > On Sunday, 14 April 2019 13:31:41 CEST David Faure wrote: > > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > > > Hi, > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > KCalCore is an implementation of the iCalendar standard based on libical, > > > > I wonder about the name, which doesn't mean much outside the circle of PIM > > people. Shouldn't this be called KCalendar ? > > > > If the "Core" simply means non-GUI, we certainly don't have that word in > > every non-GUI framework. > > Renaming the namespace should be manageable, we can soften the blow for > external users with a namespace alias I guess, to at least keep SC until > everyone has adapted. > > > > covering the data model, input/output and the rather complex recurrence > > > algorithms defined in that standard. It's used outside of KDE PIM as well, > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > This makes me wonder: where does that mobile calendar app get the events > > from? Akonadi? (then it still depends on kde/pim/*, and this move in itself > > doesn't really remove the unwanted workspace->apps dependency?) > > So far it looked like just a local ical file, which I guess is temporary, > while focusing on mobile UI development. Eventually I at least expect the need > for KDav there too. So just moving KCalCore isn't going to be enough > obviously, but it is a necessary first step either way. > > > Zanshin does use akonadi (though one could imagine a mobile version that > > only uses KDav and KCalCore^H^H^H KCalendar). > > > > Some review: > > > > icalformat_p.h://TODO: KDE5, move this implementation to > > icalformat_p.cpp incidencebase.h: * // TODO_KDE5: Provide a virtual > > serialize() method, as done with assign() and equals(). incidencebase.h: * > > // TODO_KDE5: Provide a virtual serialize() method, as done with assign() > > and equals(). person.h:// TODO_KDE5: FIXME: This operator does > > slicing,if the object is in fact one of the derived classes (Attendee) > > Person/Attendee I'd like to ideally see split into two non-polymorphic value > types, as that would make direct QML consumption easier. That would also > address the slicing risk. Aliases shouldn't be strictly necessary because the framework can be called KCal and the target KF5::CalCore, much like in KConfig. We could decide to have it this way though. Aleix
Re: New framework: KCalCore
On Sunday, 14 April 2019 20:30:07 CEST Alexander Potashev wrote: > вт, 9 апр. 2019 г. в 20:10, Volker Krause : > > On Sunday, 7 April 2019 16:24:13 CEST Alexander Potashev wrote: > > > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > > > Hi, > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > > > KCalCore is an implementation of the iCalendar standard based on > > > > libical, > > > > covering the data model, input/output and the rather complex > > > > recurrence > > > > algorithms defined in that standard. It's used outside of KDE PIM as > > > > well, > > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > > > Hi Volker, > > > > > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > > > support on the way from KDELibs4 to KF 5.0. > > > > > > Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat > > > relation looks weird to me: ICalFormat::save() is the method that > > > actually writes file to disk, while class name "ICalFormat" suggests > > > that it should only be concerned about iCal contents, not the I/O. > > > > > > May be CalFormat should only implement marshal/unmarshal methods, then > > > actual r/w from disk can be done in FileStorage. Otherwise, for me to > > > add KIO support right now I need to subclass ICalFormat rather than > > > FileStorage which is weird. > > > > Right. IMHO the entire file handling code should probably not be in there > > in the first place. That is, the CalStorage class hierarchy and the file > > I/O methods from the CalFormat hierachy (streaming to/from QIODevice > > rather than working with full QByteArray serialization might however make > > sense there). > > > > This is also why KIO support was a very bad idea in there, the KCalCore > > API is synchronous (predating KIO), while KIO is asynchronous, and so is > > likely any other persistence backend one might want to use. > > > > Looking at lxr.kde.org I'm however reluctant to remove any of this now > > though, this is still too widely used. > > Hi Volker, > > Thanks for your thoughts! > > Since David suggested renaming KCalCore to something else, how about we > instead 1. Redesign the API (e.g. drop file handling, etc) and call it e.g. > KCal, get it into KF5, > 2. Keep releasing KCalCore as part of KDEPIM and may be port it to > KF5::KCal as backend to reduce codebase, > 3. Deprecate KCalCore and gradually port everything to the new clean > KF5::KCal? ... > 4. PROFIT: nobody's code is hurt since the legacy KCalCore API is > still available. That's essentially rejecting the move of KCalCore to KF5, which is a perfectly valid outcome of this discussion of course. If that's going to be the consensus it would be good to know that sooner rather than later though, to not waste any time on this. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Sunday, 14 April 2019 13:31:41 CEST David Faure wrote: > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > > Hi, > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > KCalCore is an implementation of the iCalendar standard based on libical, > > I wonder about the name, which doesn't mean much outside the circle of PIM > people. Shouldn't this be called KCalendar ? > > If the "Core" simply means non-GUI, we certainly don't have that word in > every non-GUI framework. Renaming the namespace should be manageable, we can soften the blow for external users with a namespace alias I guess, to at least keep SC until everyone has adapted. > > covering the data model, input/output and the rather complex recurrence > > algorithms defined in that standard. It's used outside of KDE PIM as well, > > e.g. by Zanshin or the Plasma Mobile calendar app. > > This makes me wonder: where does that mobile calendar app get the events > from? Akonadi? (then it still depends on kde/pim/*, and this move in itself > doesn't really remove the unwanted workspace->apps dependency?) So far it looked like just a local ical file, which I guess is temporary, while focusing on mobile UI development. Eventually I at least expect the need for KDav there too. So just moving KCalCore isn't going to be enough obviously, but it is a necessary first step either way. > Zanshin does use akonadi (though one could imagine a mobile version that > only uses KDav and KCalCore^H^H^H KCalendar). > > Some review: > > icalformat_p.h://TODO: KDE5, move this implementation to > icalformat_p.cpp incidencebase.h: * // TODO_KDE5: Provide a virtual > serialize() method, as done with assign() and equals(). incidencebase.h: * > // TODO_KDE5: Provide a virtual serialize() method, as done with assign() > and equals(). person.h:// TODO_KDE5: FIXME: This operator does > slicing,if the object is in fact one of the derived classes (Attendee) Person/Attendee I'd like to ideally see split into two non-polymorphic value types, as that would make direct QML consumption easier. That would also address the slicing risk. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On lundi 15 avril 2019 12:40:06 CEST Daniel Vrátil wrote: > On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote: > > Maybe KCal is enough? Reminds of iCal. > > Wasn't KCal the original name of the library from pre-Akonadi times? > KCalCore was a fork of KCal with the pre-Akonadi "Resources" system > removed... See? That's perfect, it comes full circle then :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KCalCore
On Mon, Apr 15, 2019 at 2:52 PM David Jarvie wrote: > > > > On 15 April 2019 13:25:56 BST, Allen Winter wrote: > > On Monday, April 15, 2019 6:40:06 AM EDT Daniel Vrátil wrote: > > > On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote: > > > > On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote: > > > > > On 14 April 2019 12:31:41 BST, David Faure > > wrote: > > > > > > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM > > to KF5. > > > > > > > > > > > > > > KCalCore is an implementation of the iCalendar standard > > based on > > > > > > > > > > > > libical, > > > > > > > > > > > > I wonder about the name, which doesn't mean much outside the > > circle of > > > > > > PIM people. Shouldn't this be called KCalendar ? > > > > > > > > > > > > If the "Core" simply means non-GUI, we certainly don't have > > that word > > > > > > in every non-GUI framework. > > > > > > > > > > Renaming makes sense. KCalendar suggests it could be about > > calendar > > > > > systems, > > > > Indeed. > > > > > > > > > so to avoid that confusion, perhaps call it KiCalendar? > > > > > > > > Doesn't read very well > > > > I would want to say KCalendarEvents but I guess the more correct > > generic > > > > term would be KCalendarIncidences ... not convicing either. > > > > > > > > Maybe KCal is enough? Reminds of iCal. > > > > > > Wasn't KCal the original name of the library from pre-Akonadi times? > > KCalCore > > > was a fork of KCal with the pre-Akonadi "Resources" system > > removed... > > > > > Yep. Back to the Future. Let's stay away from "KCal" and "KCalendar" > > > > commit 6b4c1896211075fcd0b88b2c617eaacd831c9f6d > > Author: Allen Winter > > Date: Sat Jul 17 17:00:14 2010 + > > > > Add the new KCalCore library. > > > > The KCalCore library deprecates and mostly replaces the KCal library. > > KCalCore is free of any relation to the old Calendar resources and > > focuses entirely on iCalendar and vCalendar storage and data > > manipulation. > > KCalCore used QSharedPointers for safe memory access, is free of i18n > > strings and contains no methods for user interaction: KCalCore is all > > about the calendar data. > > Would KCalendarSerialization be a better name? I think that sums up its > purpose. > > -- > David Jarvie > KAlarm author, KDE developer > http://www.astrojar.org.uk/kalarm KContacts is the framework dealing with vcards (which are equivalent to iCal, for contacts). It makes sense to follow the same naming. If we really don't want calendaring functions there, we could consider calling it KiCal, I don't think it's that bad either and it's definitely more self-explanatory. Or we call it KCalendar and allow having calendar building blocks in it which could make sense as well, if required. Aleix
Re: New framework: KCalCore
On 15 April 2019 13:25:56 BST, Allen Winter wrote: > On Monday, April 15, 2019 6:40:06 AM EDT Daniel Vrátil wrote: > > On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote: > > > On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote: > > > > On 14 April 2019 12:31:41 BST, David Faure > wrote: > > > > > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > > > > > > Hi, > > > > > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM > to KF5. > > > > > > > > > > > > KCalCore is an implementation of the iCalendar standard > based on > > > > > > > > > > libical, > > > > > > > > > > I wonder about the name, which doesn't mean much outside the > circle of > > > > > PIM people. Shouldn't this be called KCalendar ? > > > > > > > > > > If the "Core" simply means non-GUI, we certainly don't have > that word > > > > > in every non-GUI framework. > > > > > > > > Renaming makes sense. KCalendar suggests it could be about > calendar > > > > systems, > > > Indeed. > > > > > > > so to avoid that confusion, perhaps call it KiCalendar? > > > > > > Doesn't read very well > > > I would want to say KCalendarEvents but I guess the more correct > generic > > > term would be KCalendarIncidences ... not convicing either. > > > > > > Maybe KCal is enough? Reminds of iCal. > > > > Wasn't KCal the original name of the library from pre-Akonadi times? > KCalCore > > was a fork of KCal with the pre-Akonadi "Resources" system > removed... > > > Yep. Back to the Future. Let's stay away from "KCal" and "KCalendar" > > commit 6b4c1896211075fcd0b88b2c617eaacd831c9f6d > Author: Allen Winter > Date: Sat Jul 17 17:00:14 2010 + > > Add the new KCalCore library. > > The KCalCore library deprecates and mostly replaces the KCal library. > KCalCore is free of any relation to the old Calendar resources and > focuses entirely on iCalendar and vCalendar storage and data > manipulation. > KCalCore used QSharedPointers for safe memory access, is free of i18n > strings and contains no methods for user interaction: KCalCore is all > about the calendar data. Would KCalendarSerialization be a better name? I think that sums up its purpose. -- David Jarvie KAlarm author, KDE developer http://www.astrojar.org.uk/kalarm
Re: New framework: KCalCore
On Sunday, 14 April 2019 20:17:54 CEST David Faure wrote: > On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote: > > On 14 April 2019 12:31:41 BST, David Faure wrote: > > > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > > > > Hi, > > > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > > > KCalCore is an implementation of the iCalendar standard based on > > > > > > libical, > > > > > > I wonder about the name, which doesn't mean much outside the circle of > > > PIM people. Shouldn't this be called KCalendar ? > > > > > > If the "Core" simply means non-GUI, we certainly don't have that word > > > in every non-GUI framework. > > > > Renaming makes sense. KCalendar suggests it could be about calendar > > systems, > Indeed. > > > so to avoid that confusion, perhaps call it KiCalendar? > > Doesn't read very well > I would want to say KCalendarEvents but I guess the more correct generic > term would be KCalendarIncidences ... not convicing either. > > Maybe KCal is enough? Reminds of iCal. Wasn't KCal the original name of the library from pre-Akonadi times? KCalCore was a fork of KCal with the pre-Akonadi "Resources" system removed... -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
вт, 9 апр. 2019 г. в 20:10, Volker Krause : > > On Sunday, 7 April 2019 16:24:13 CEST Alexander Potashev wrote: > > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > > Hi, > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > KCalCore is an implementation of the iCalendar standard based on libical, > > > covering the data model, input/output and the rather complex recurrence > > > algorithms defined in that standard. It's used outside of KDE PIM as well, > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > Hi Volker, > > > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > > support on the way from KDELibs4 to KF 5.0. > > > > Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat > > relation looks weird to me: ICalFormat::save() is the method that > > actually writes file to disk, while class name "ICalFormat" suggests > > that it should only be concerned about iCal contents, not the I/O. > > > > May be CalFormat should only implement marshal/unmarshal methods, then > > actual r/w from disk can be done in FileStorage. Otherwise, for me to > > add KIO support right now I need to subclass ICalFormat rather than > > FileStorage which is weird. > > Right. IMHO the entire file handling code should probably not be in there in > the first place. That is, the CalStorage class hierarchy and the file I/O > methods from the CalFormat hierachy (streaming to/from QIODevice rather than > working with full QByteArray serialization might however make sense there). > > This is also why KIO support was a very bad idea in there, the KCalCore API is > synchronous (predating KIO), while KIO is asynchronous, and so is likely any > other persistence backend one might want to use. > > Looking at lxr.kde.org I'm however reluctant to remove any of this now though, > this is still too widely used. Hi Volker, Thanks for your thoughts! Since David suggested renaming KCalCore to something else, how about we instead 1. Redesign the API (e.g. drop file handling, etc) and call it e.g. KCal, get it into KF5, 2. Keep releasing KCalCore as part of KDEPIM and may be port it to KF5::KCal as backend to reduce codebase, 3. Deprecate KCalCore and gradually port everything to the new clean KF5::KCal? ... 4. PROFIT: nobody's code is hurt since the legacy KCalCore API is still available. -- Alexander Potashev
Re: New framework: KCalCore
On dimanche 14 avril 2019 19:46:02 CEST David Jarvie wrote: > On 14 April 2019 12:31:41 BST, David Faure wrote: > > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > > > Hi, > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > KCalCore is an implementation of the iCalendar standard based on > > > > libical, > > > > I wonder about the name, which doesn't mean much outside the circle of > > PIM people. Shouldn't this be called KCalendar ? > > > > If the "Core" simply means non-GUI, we certainly don't have that word > > in every non-GUI framework. > > Renaming makes sense. KCalendar suggests it could be about calendar systems, Indeed. > so to avoid that confusion, perhaps call it KiCalendar? Doesn't read very well I would want to say KCalendarEvents but I guess the more correct generic term would be KCalendarIncidences ... not convicing either. Maybe KCal is enough? Reminds of iCal. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KCalCore
On 14 April 2019 12:31:41 BST, David Faure wrote: > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > > Hi, > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > KCalCore is an implementation of the iCalendar standard based on > libical, > > I wonder about the name, which doesn't mean much outside the circle of > PIM people. Shouldn't this be called KCalendar ? > > If the "Core" simply means non-GUI, we certainly don't have that word > in every non-GUI framework. Renaming makes sense. KCalendar suggests it could be about calendar systems, so to avoid that confusion, perhaps call it KiCalendar? -- David Jarvie KAlarm author, KDE developer http://www.astrojar.org.uk/kalarm
Re: New framework: KCalCore
On Sunday, April 14, 2019 7:31:41 AM EDT David Faure wrote: > On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > > Hi, > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > KCalCore is an implementation of the iCalendar standard based on libical, > > I wonder about the name, which doesn't mean much outside the circle of PIM > people. Shouldn't this be called KCalendar ? > > If the "Core" simply means non-GUI, we certainly don't have that word in > every non-GUI framework. > > > covering the data model, input/output and the rather complex recurrence > > algorithms defined in that standard. It's used outside of KDE PIM as well, > > e.g. by Zanshin or the Plasma Mobile calendar app. > > This makes me wonder: where does that mobile calendar app get the events from? > Akonadi? (then it still depends on kde/pim/*, and this move in itself doesn't > really remove the unwanted workspace->apps dependency?) > > Zanshin does use akonadi (though one could imagine a mobile version that only > uses KDav and KCalCore^H^H^H KCalendar). > > > Some review: > > icalformat_p.h://TODO: KDE5, move this implementation to icalformat_p.cpp > incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as > done with assign() and equals(). > incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as > done with assign() and equals(). > person.h:// TODO_KDE5: FIXME: This operator does slicing,if the object is > in fact one of the derived classes (Attendee) > > This would be the perfect time to make these changes, if they are valid. > > Allen, the first TODO above is from you (commit efe923294b4d7). > I don't get it, this is a _p.h file (i.e. no SC/BC guarantees), why not just > outline the method if you wanted to? > I'll remove that TODO in icalformat_p.h No idea why... from 2013. > The "TODO: KDE5:" in calendar.h however looks like pie-in-the-sky wishful > thinking, but maybe the suggestion > about merging some virtual methods makes sense, I don't know. > >
Re: New framework: KCalCore
On dimanche 7 avril 2019 14:45:09 CEST Volker Krause wrote: > Hi, > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > KCalCore is an implementation of the iCalendar standard based on libical, I wonder about the name, which doesn't mean much outside the circle of PIM people. Shouldn't this be called KCalendar ? If the "Core" simply means non-GUI, we certainly don't have that word in every non-GUI framework. > covering the data model, input/output and the rather complex recurrence > algorithms defined in that standard. It's used outside of KDE PIM as well, > e.g. by Zanshin or the Plasma Mobile calendar app. This makes me wonder: where does that mobile calendar app get the events from? Akonadi? (then it still depends on kde/pim/*, and this move in itself doesn't really remove the unwanted workspace->apps dependency?) Zanshin does use akonadi (though one could imagine a mobile version that only uses KDav and KCalCore^H^H^H KCalendar). Some review: icalformat_p.h://TODO: KDE5, move this implementation to icalformat_p.cpp incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as done with assign() and equals(). incidencebase.h: * // TODO_KDE5: Provide a virtual serialize() method, as done with assign() and equals(). person.h:// TODO_KDE5: FIXME: This operator does slicing,if the object is in fact one of the derived classes (Attendee) This would be the perfect time to make these changes, if they are valid. Allen, the first TODO above is from you (commit efe923294b4d7). I don't get it, this is a _p.h file (i.e. no SC/BC guarantees), why not just outline the method if you wanted to? The "TODO: KDE5:" in calendar.h however looks like pie-in-the-sky wishful thinking, but maybe the suggestion about merging some virtual methods makes sense, I don't know. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KCalCore
On Monday, 8 April 2019 02:44:46 CEST Alexander Potashev wrote: > вс, 7 апр. 2019 г. в 17:24, Alexander Potashev : > > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > > Hi, > > > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > > > KCalCore is an implementation of the iCalendar standard based on > > > libical, > > > covering the data model, input/output and the rather complex recurrence > > > algorithms defined in that standard. It's used outside of KDE PIM as > > > well, > > > e.g. by Zanshin or the Plasma Mobile calendar app. > > > > Hi Volker, > > > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > > support on the way from KDELibs4 to KF 5.0. > > Another pitfall is shared pointers required everywhere. Because of > them, one can't easily subclass KCalCore classes. Sorry for the delay, finally found the time to look into this properly. > Examples: > 1. KTimeTracker has a class [1] derived from > KCalCore::MemoryCalendar. In order to pass "this" into > KCalCore::FileStorage ctor, it also stores a QWeakPointer to recover > the associated shared pointer. I would love if KCalCore::FileStorage > could accept a plain pointer to KCalCore::Calendar, there is no reason > to make it shared pointer. There is a reason this uses shared pointers everywhere: to avoid dangling references or leaked memory. Allowing to bypass that seems like a very slippery slope. In this specific case I think the pain comes from using a class inside a calendar object that seems rather meant for being used alongside one. > 2. akonadi-calendar uses the same approach [2]. Kudos to whoever > invented this clever hack I tried to find where this is actually needed, and it seems to be entirely unused. Removed in D20472. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KContacts
On Tuesday, 9 April 2019 03:11:57 CEST Aleix Pol wrote: > On Sat, Apr 6, 2019 at 6:02 PM Volker Krause wrote: > > Hi, > > > > I'd like to propose KContacts for review to move from KDE PIM to KF5. > > > > KContacts is essentially an implementation of the vCard standard, covering > > the data model as well as parsing and creating of vCard files. As the > > recent CI issue showed it's used outside of KDE PIM as well, therefore we > > would particularly benefit from the KF5 stability guarantees. > > > > KContacts depends on KConfig, KCodecs, KCoreAddons and KI18n, making it a > > Tier 2 functional framework. > > > > KContacts used to be part of kdelibs during the 2 and 3 era under the name > > "kabc", and part of kdepimlibs in the 4 era, so it's very well prepared > > for > > complying with the API and ABI guarantees. > > > > To have a smooth as possible transition the proposed timeline would be: > > - complete the review and possibly required adjustments before the 19.08 > > freeze > > - do one final release as part of KDE PIM with 19.08, with the final ABI > > and library name for KF5 > > - after 19.08 (so Sep or Oct 2019), release it with KF5, which will then > > be a drop-in replacement for the KDE PIM release. > > > > This approach has already successfully been used for KHolidays and > > Syndication. > > > > We did a review at the currently ongoing PIM sprint, which resulted in > > removal of some ancient unused cruft (D20270, D20273, D20274, D20275, > > D20276) which did technically change the ABI, therefore the transition > > after 19.08 rather than 19.04. > > > > Thanks, > > Volker > > Hi, > What's the reasoning behind it? What's changing now that made > kcontacts now need to be part of KF5? I think it's rather the other way around: why did it take us so long to have it as part of KF5, considering it has been part of kde[pim]libs since the KDE 2 era? So it's less about something changing recently making this move necessary, it's more about finally fixing a long-standing issue of the KF5 migration :) However one recent event highlighting again the need to finally fix this was the CI maintainability thread, which shows that things being de facto used as frameworks but not following framework procedures and guarantees do cause trouble. The same applies to KCalCore too, as well as possibly more components currently part of the KDE PIM release (KMime, KSmtp, KImap, KDav, etc). Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
On Sunday, 7 April 2019 16:24:13 CEST Alexander Potashev wrote: > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > Hi, > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > KCalCore is an implementation of the iCalendar standard based on libical, > > covering the data model, input/output and the rather complex recurrence > > algorithms defined in that standard. It's used outside of KDE PIM as well, > > e.g. by Zanshin or the Plasma Mobile calendar app. > > Hi Volker, > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > support on the way from KDELibs4 to KF 5.0. > > Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat > relation looks weird to me: ICalFormat::save() is the method that > actually writes file to disk, while class name "ICalFormat" suggests > that it should only be concerned about iCal contents, not the I/O. > > May be CalFormat should only implement marshal/unmarshal methods, then > actual r/w from disk can be done in FileStorage. Otherwise, for me to > add KIO support right now I need to subclass ICalFormat rather than > FileStorage which is weird. Right. IMHO the entire file handling code should probably not be in there in the first place. That is, the CalStorage class hierarchy and the file I/O methods from the CalFormat hierachy (streaming to/from QIODevice rather than working with full QByteArray serialization might however make sense there). This is also why KIO support was a very bad idea in there, the KCalCore API is synchronous (predating KIO), while KIO is asynchronous, and so is likely any other persistence backend one might want to use. Looking at lxr.kde.org I'm however reluctant to remove any of this now though, this is still too widely used. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KContacts
On Sat, Apr 6, 2019 at 6:02 PM Volker Krause wrote: > > Hi, > > I'd like to propose KContacts for review to move from KDE PIM to KF5. > > KContacts is essentially an implementation of the vCard standard, covering the > data model as well as parsing and creating of vCard files. As the recent CI > issue showed it's used outside of KDE PIM as well, therefore we would > particularly benefit from the KF5 stability guarantees. > > KContacts depends on KConfig, KCodecs, KCoreAddons and KI18n, making it a Tier > 2 functional framework. > > KContacts used to be part of kdelibs during the 2 and 3 era under the name > "kabc", and part of kdepimlibs in the 4 era, so it's very well prepared for > complying with the API and ABI guarantees. > > To have a smooth as possible transition the proposed timeline would be: > - complete the review and possibly required adjustments before the 19.08 > freeze > - do one final release as part of KDE PIM with 19.08, with the final ABI and > library name for KF5 > - after 19.08 (so Sep or Oct 2019), release it with KF5, which will then be a > drop-in replacement for the KDE PIM release. > > This approach has already successfully been used for KHolidays and > Syndication. > > We did a review at the currently ongoing PIM sprint, which resulted in removal > of some ancient unused cruft (D20270, D20273, D20274, D20275, D20276) which > did technically change the ABI, therefore the transition after 19.08 rather > than 19.04. > > Thanks, > Volker Hi, What's the reasoning behind it? What's changing now that made kcontacts now need to be part of KF5? Thanks! Aleix
Re: New framework: KCalCore
On Sunday, 7 April 2019 18:54:19 CEST Albert Astals Cid wrote: > El diumenge, 7 d’abril de 2019, a les 14:45:09 CEST, Volker Krause va escriure: > > Hi, > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > Does exceptions.h need a d-pointer? Looks like it, I'll fix that. Thanks, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KContacts
Thanks for having a look at this Albert! On Sunday, 7 April 2019 18:46:46 CEST Albert Astals Cid wrote: > El dissabte, 6 d’abril de 2019, a les 18:01:09 CEST, Volker Krause va escriure: > > Hi, > > > > I'd like to propose KContacts for review to move from KDE PIM to KF5. > > ## QUESTION 1 ## > > Does VCardTool need a d-pointer? Should it be a namespace instead of a > class? It's a class with no members, seems a bit weird Indeed. This however isn't installed, it seems only to be exported for unit tests. As a first step I'll rename it to _p.h to make that clear. > ## QUESTION 2 ## > > How concerned are we by the include names being so "generic". > > i.e. it has stuff like address.h or email.h > > They seem to inter-include eachother "directly" i.e. addressee.h has > #include "address.h" > and not > #include "kcontacts/address.h" > > So it seems like the -I paths may be a bit "polluting". It looks like the "namespace" part of the include path is not added to the include search path. So "#include " will not work in user code (it always needs the "kcontacts/" prefix), but the header files themselves can still reference files in the same folder using the double-quoted #include variant. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KCalCore
вс, 7 апр. 2019 г. в 17:24, Alexander Potashev : > > вс, 7 апр. 2019 г. в 15:45, Volker Krause : > > Hi, > > > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > > > KCalCore is an implementation of the iCalendar standard based on libical, > > covering the data model, input/output and the rather complex recurrence > > algorithms defined in that standard. It's used outside of KDE PIM as well, > > e.g. by Zanshin or the Plasma Mobile calendar app. > > Hi Volker, > > While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO > support on the way from KDELibs4 to KF 5.0. Another pitfall is shared pointers required everywhere. Because of them, one can't easily subclass KCalCore classes. Examples: 1. KTimeTracker has a class [1] derived from KCalCore::MemoryCalendar. In order to pass "this" into KCalCore::FileStorage ctor, it also stores a QWeakPointer to recover the associated shared pointer. I would love if KCalCore::FileStorage could accept a plain pointer to KCalCore::Calendar, there is no reason to make it shared pointer. 2. akonadi-calendar uses the same approach [2]. Kudos to whoever invented this clever hack https://twitter.com/elonmusk/status/1104498091305009152 [1] https://cgit.kde.org/scratch/nalvarez/ktimetracker-filtered.git/tree/src/file/filecalendar.cpp?h=develop&id=d12569704d7b8c399151a46c067b51f2d6fbd8d1 [2] https://api.kde.org/frameworks-api/frameworks-apidocs/kdepim/akonadi-calendar/html/classAkonadi_1_1CalendarBase.html#ae3f11b166c0b51f4f071d3a74c6b91ba -- Alexander Potashev
Re: New framework: KCalCore
El diumenge, 7 d’abril de 2019, a les 14:45:09 CEST, Volker Krause va escriure: > Hi, > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. Does exceptions.h need a d-pointer? Cheers, Albert
Re: New framework: KContacts
El dissabte, 6 d’abril de 2019, a les 18:01:09 CEST, Volker Krause va escriure: > Hi, > > I'd like to propose KContacts for review to move from KDE PIM to KF5. ## QUESTION 1 ## Does VCardTool need a d-pointer? Should it be a namespace instead of a class? It's a class with no members, seems a bit weird ## QUESTION 2 ## How concerned are we by the include names being so "generic". i.e. it has stuff like address.h or email.h They seem to inter-include eachother "directly" i.e. addressee.h has #include "address.h" and not #include "kcontacts/address.h" So it seems like the -I paths may be a bit "polluting". Cheers, Albert
Re: New framework: KCalCore
вс, 7 апр. 2019 г. в 15:45, Volker Krause : > Hi, > > I'd like to propose KCalCore for review to move from KDE PIM to KF5. > > KCalCore is an implementation of the iCalendar standard based on libical, > covering the data model, input/output and the rather complex recurrence > algorithms defined in that standard. It's used outside of KDE PIM as well, > e.g. by Zanshin or the Plasma Mobile calendar app. Hi Volker, While porting KTimeTracker to KF5, I noticed that KCalCore lost KIO support on the way from KDELibs4 to KF 5.0. Of course I can subclass ICalFormat, but the FileStorage<->ICalFormat relation looks weird to me: ICalFormat::save() is the method that actually writes file to disk, while class name "ICalFormat" suggests that it should only be concerned about iCal contents, not the I/O. May be CalFormat should only implement marshal/unmarshal methods, then actual r/w from disk can be done in FileStorage. Otherwise, for me to add KIO support right now I need to subclass ICalFormat rather than FileStorage which is weird. P.S. Sorry for the off-topic. -- Alexander Potashev
Re: New framework: KF5Syndication
On Fri, Aug 31, 2018 at 6:35 AM Volker Krause wrote: > > On Thursday, 30 August 2018 18:04:56 CEST Christoph Feck wrote: > > On 18.08.2018 15:38, Volker Krause wrote: > > > The KIO dependency has been refactored away, so [KF5Syndication] is now a > > > tier 2 functional framework. > > > > Any idea why > > https://api.kde.org/frameworks/syndication/html/syndication-dependencies.htm > > l says it needs KIO? > > Good question. IIUC kapidox generates this from cmake --graphviz, and that > locally shows me no references to KIO (nor does grep'ing the syndication > repo). Outdated checkout/dirty build dir on the API docs build machine maybe? If memory serves it uses results from the CI system, so should be reasonably up to date. However i'm not sure what logic it relies on (the API site generation system needs an overhaul as mentioned at Akademy, i'm not sure how this all works) > > Regards, > Volker Cheers, Ben
Re: New framework: KF5Syndication
On Thursday, 30 August 2018 18:04:56 CEST Christoph Feck wrote: > On 18.08.2018 15:38, Volker Krause wrote: > > The KIO dependency has been refactored away, so [KF5Syndication] is now a > > tier 2 functional framework. > > Any idea why > https://api.kde.org/frameworks/syndication/html/syndication-dependencies.htm > l says it needs KIO? Good question. IIUC kapidox generates this from cmake --graphviz, and that locally shows me no references to KIO (nor does grep'ing the syndication repo). Outdated checkout/dirty build dir on the API docs build machine maybe? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KF5Syndication
On 18.08.2018 15:38, Volker Krause wrote: The KIO dependency has been refactored away, so [KF5Syndication] is now a tier 2 functional framework. Any idea why https://api.kde.org/frameworks/syndication/html/syndication-dependencies.html says it needs KIO?
Re: New framework: KF5Syndication
On Monday, 20 August 2018 22:51:44 CEST David Faure wrote: > On samedi 18 août 2018 15:38:48 CEST Volker Krause wrote: > > On Wednesday, 22 April 2015 21:44:05 CEST Daniel Vrátil wrote: > > > Hi all, > > > > > > I'd like to ask for review of another Framework from kdepimlibs: > > > KF5Syndication > > > > > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > > > fetch > > > feeds directly from network. > > > > > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's > > > currently being > > > used only by Akregator. > > > > > > I would like to submit KF5Syndication for the standard 2 week review > > > period, and if everything is OK, then move it to Frameworks. > > > > Now that 18.08 is done let's finally move this forward. > > > > The KIO dependency has been refactored away, so this is now a tier 2 > > functional framework. > > > > Unless there are objections we'd like to move KF5Syndication from PIM to > > KF5 before the 18.12 dependency freeze (ie. in to the KF5 September or > > October releases). > > Works for me. Please request the move and the addition to Frameworks CI so > it shows up on my radar :) This has been done and is reflected in the CI, the dependency meta data and the versioning now. Just the release flag is still missing. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New framework: KF5Syndication
On samedi 18 août 2018 15:38:48 CEST Volker Krause wrote: > On Wednesday, 22 April 2015 21:44:05 CEST Daniel Vrátil wrote: > > Hi all, > > > > I'd like to ask for review of another Framework from kdepimlibs: > > KF5Syndication > > > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > > fetch > > feeds directly from network. > > > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's > > currently being > > used only by Akregator. > > > > I would like to submit KF5Syndication for the standard 2 week review > > period, and if everything is OK, then move it to Frameworks. > > Now that 18.08 is done let's finally move this forward. > > The KIO dependency has been refactored away, so this is now a tier 2 > functional framework. > > Unless there are objections we'd like to move KF5Syndication from PIM to KF5 > before the 18.12 dependency freeze (ie. in to the KF5 September or October > releases). Works for me. Please request the move and the addition to Frameworks CI so it shows up on my radar :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: New framework: KF5Syndication
On Wednesday, 22 April 2015 21:44:05 CEST Daniel Vrátil wrote: > Hi all, > > I'd like to ask for review of another Framework from kdepimlibs: > KF5Syndication > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > fetch > feeds directly from network. > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's > currently being > used only by Akregator. > > I would like to submit KF5Syndication for the standard 2 week review > period, and if everything is OK, then move it to Frameworks. Now that 18.08 is done let's finally move this forward. The KIO dependency has been refactored away, so this is now a tier 2 functional framework. Unless there are objections we'd like to move KF5Syndication from PIM to KF5 before the 18.12 dependency freeze (ie. in to the KF5 September or October releases). Same procedure as with the KF5Holidays move, it's an ABI-compatible drop-in replacement for what's shipped with 18.08. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: New KDE application
Adding other lists. On 10-Jan-2018 11:49 PM, "Sayan Biswas" wrote: > Hi, > > A very happy new year to all. Hope you guys are doing good. :) > > Me and Rahul (CC'ed; IRC nick - rahulch) came up with an idea for a > new application in KDE, and we were hoping to get an opinion on it. > > The central idea behind the app will be to manage the expenses of a > group of users. As a user, you can create one or more groups, add > members to them, and add entries for expenses for a given group. You > can also check the outstanding balances and choose to settle-up with one > or more members. There will be options for fine-tuning a given entry - > decide who all have born the total expenditure and by what > proportions, how should the total expense be divided among the members > (equally/specific amounts/etc), add pictures for receipts, add > comments, and so on and so forth. > > We are planning to start off with desktop application with a decentralised > approach, i.e. the users will hold the data of the shared expenses. Now > again, > there is a possibility of tampering with the expenditure so we might need > to > set a centralised archived or something similar data set to maintain the > integrity and persistence of a transaction. We are open to opinions and > discussions for this also. Further to that we will be building mobile > application for the users ease of usage and add expenditure on the go. > After > all, mobiles are more widely used by user than desktop application. > > > For settling up we were thinking of integrating some standard payment > gateways (PayPal, etc) but I am not sure of how much of this > integration is possible in KDE. Until then we can just maintain a > transaction record indicating that members A and B have settled up. We > were also considering developing a cryptocurrency (we could call it > KCoin or something) that would serve as a means of payment. Opinions > are welcome in this particular segment as possibilities can be immense. > > As for maintaining the ledgers, we wanted to implement it using > blockchain, but again, I am not sure if it can be done in KDE, or if > we have some libraries that support blockchain implementation, etc. > > An application like this comes in handy when a group of people need to > manage their regular expenses, and we thought it might be a good idea > to have something similar in KDE. The target audience for this will be > college groups, work groups, school groups, etc whoever is entitled to > shared expenditure. We would love to get your feedback, mainly on the > feasibility of the features mentioned above. > > > Regards, > Sayan >
Re: New maintainers wanted: KDE Telepathy, KAccounts, Plasma Notifications and others
Hi, thanks for your hard work and good luck with your new job! :) I'd love taking over KNotifications with the Plasma Notification applet as I would really like to move that stack forward to better follow Plasma's mantra of not standing in the user's way. I already made a wiki page [1] with some thoughts and ideas that might be worth trying out. Cheers, Kai Uwe [1] https://community.kde.org/Plasma/Notifications ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: BluezQt
On Thursday 28 May 2015 22:52:17 David Rosca wrote: > It's been over 14 days now, so if there are no objections, I will ask > sysadmins to move it to frameworks. > > Also, are there any other steps I should do besides moving the repository? It looks fine, it's getting picked up for KF 5.11. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: BluezQt
It's been over 14 days now, so if there are no objections, I will ask sysadmins to move it to frameworks. Also, are there any other steps I should do besides moving the repository? Thanks, David On Tue, May 12, 2015 at 11:44 PM, David Rosca wrote: > Hi all, > > I'd like to submit bluez-qt [1] for a review and then release it as > part of frameworks 5.11. > > It is used in Bluedevil since the first release with Plasma 5.3. I > have worked on API changes (it is source incompatible from the 5.3 > version) and also added a new tests (including QML tests). > I believe it is now ready to become a framework. > > If you have any comments, please let me know. > > Thanks, > David > > [1] http://quickgit.kde.org/?p=bluez-qt.git ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KF5Syndication
On Thursday 23 April 2015, David Edmundson wrote: > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's > > currently being > > used only by Akregator. > > There is another (depending on the definition of "currently") > > Plasma 4 used it for an RSS reader plasmoid. > In Plasma 5 the code is there but commented out of the build system. yeah, i would love having the two rss reader plamoids again ;) (they even had a partial qml port somewhere) -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KF5Syndication
On Wed, Apr 22, 2015 at 9:44 PM, Daniel Vrátil wrote: > Hi all, > > I'd like to ask for review of another Framework from kdepimlibs: > KF5Syndication > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > fetch > feeds directly from network. > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's currently > being > used only by Akregator. > There is another (depending on the definition of "currently") Plasma 4 used it for an RSS reader plasmoid. In Plasma 5 the code is there but commented out of the build system. David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KF5Syndication
On Thu, Apr 23, 2015 at 12:13 AM, Daniel Vrátil wrote: > On Wednesday, April 22, 2015 11:02:31 PM Frank Osterfeld wrote: >> Hi, >> >> > KF5Syndication is an RSS/Atom parsing library. It also provides API to >> > fetch feeds directly from network. >> > >> > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's currently >> > being used only by Akregator. >> >> The Akonadi RSS resources (still lingering in some work branch, I assume?) >> and some plasmoids were also using it. >> >> As for the dependencies: The KIO dependency is used only by a single class, >> “DataRetriever”, which is a rather thin wrapper around KIO::get to download >> the feed file. The actual parser only requires KCodecs from KF. So I wonder >> if it would make sense to either drop the retriever classes completely, >> split them into another library (too tiny I guess), or make them optional >> in the build. > > If KIO is really needed only to fetch the feeds then I would say we can drop > it. If Akregator ever gets ported to Akonadi :), then the retrieval will be > handled by the resource and other applications using Syndication will probably > prefer their own retrieval methods and can always fall back to just calling > KIO::get themselves. > > Dan > >> >> Frank > > -- > Daniel Vrátil > www.dvratil.cz | dvra...@kde.org > IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) > > GPG Key: 0x4D69557AECB13683 > Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > As a hint, for KDE Connect what I'm working on is to use KIO::AccessManager so in practice the framework only depends on QtNetwork (QNetworkAccessManager) and then a hook is provided to feed the KIO implementation. This is also what QtWebKit does. HTH, Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KF5Syndication
On Wednesday, April 22, 2015 11:02:31 PM Frank Osterfeld wrote: > Hi, > > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > > fetch feeds directly from network. > > > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's currently > > being used only by Akregator. > > The Akonadi RSS resources (still lingering in some work branch, I assume?) > and some plasmoids were also using it. > > As for the dependencies: The KIO dependency is used only by a single class, > “DataRetriever”, which is a rather thin wrapper around KIO::get to download > the feed file. The actual parser only requires KCodecs from KF. So I wonder > if it would make sense to either drop the retriever classes completely, > split them into another library (too tiny I guess), or make them optional > in the build. If KIO is really needed only to fetch the feeds then I would say we can drop it. If Akregator ever gets ported to Akonadi :), then the retrieval will be handled by the resource and other applications using Syndication will probably prefer their own retrieval methods and can always fall back to just calling KIO::get themselves. Dan > > Frank -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 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: New framework: KF5Syndication
On Wednesday, April 22, 2015 10:51:15 PM Mark Gaiser wrote: > On Wed, Apr 22, 2015 at 9:44 PM, Daniel Vrátil wrote: > > Hi all, > > > > I'd like to ask for review of another Framework from kdepimlibs: > > KF5Syndication > > > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > > fetch > > feeds directly from network. > > > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's currently > > being > > used only by Akregator. > > > > I would like to submit KF5Syndication for the standard 2 week review > > period, and if everything is OK, then move it to Frameworks. > > > > Cheers, > > Daniel > > > > Disclaimer: I've never seen this code nor knew about it's existence till > > ~30 minutes ago. > > This library depends on QtXml (quite heavily in fact). That very Qt module > is deprecated [1]. > Funnily enough, that is the only place that mentions it as being > deprecated. No QtXml classes mention it in the docs and you won't get any > compiler warnings either when you decide to use it. > > When searching for bug reports for deprecating QtXml i found [2] where they > say it's been mislabeled and should have the same status as Widgets. Aka: > done. > Which also means it might go deprecated in some future release (Qt6?). > > Now i don't know what the real state of QtXml is, but if it really is > deprecated then i don't know if it's wise to release this library while > depending on a deprecated module. > In that case it might be better to "port" (which probably requires quite > some work) to the QXmlStreamReader and QXmlStreamWriter. I don't think we need to bother ourselves with this now since QtXml is not going away in Qt 5. If QtXml is indeed removed from Qt at some point then we will of course have to re-evaluate switching to QXmlStreamReader (or some 3rd party parser). QtXml is not exposed in public API of Syndication, so we should be able to just switch to different parser in KF6 without breaking API (too much). QXmlStreamReader has a rather low-level API IMO - it's OK if you want to parse the XML top-down but what Syndication does is closer to mapping objects to parts of the XML DOM so as you said rewriting it to QXmlStreamReader would be quite a lot of work. Cheers, Dan > > Just my 5 cents :) > > [1] http://doc.qt.io/qt-5/qtmodules.html > [2] https://bugreports.qt.io/browse/QTBUG-32926 -- Daniel Vrátil www.dvratil.cz | dvra...@kde.org IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde) GPG Key: 0x4D69557AECB13683 Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683 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: New framework: KF5Syndication
Hi, > > KF5Syndication is an RSS/Atom parsing library. It also provides API to fetch > feeds directly from network. > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's currently > being > used only by Akregator. The Akonadi RSS resources (still lingering in some work branch, I assume?) and some plasmoids were also using it. As for the dependencies: The KIO dependency is used only by a single class, “DataRetriever”, which is a rather thin wrapper around KIO::get to download the feed file. The actual parser only requires KCodecs from KF. So I wonder if it would make sense to either drop the retriever classes completely, split them into another library (too tiny I guess), or make them optional in the build. Frank ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KF5Syndication
> On 22 Apr 2015, at 22:51, Mark Gaiser wrote: > > Disclaimer: I've never seen this code nor knew about it's existence till ~30 > minutes ago. > > This library depends on QtXml (quite heavily in fact). That very Qt module is > deprecated [1]. > Funnily enough, that is the only place that mentions it as being deprecated. > No QtXml classes mention it in the docs and you won't get any compiler > warnings either when you decide to use it. True, the heavy QDom usage is a burden, which I don’t think you can get rid of in a sensible way, not without changing both API and implementation to a point where you end up with a rewrite, not a refactoring. If I would rewrite such a library today, I’d use QXmlStreamReader instead of QDom. I’d also get rid of all that funky polymorphism and design pattern-isms, and just parse the feed data from the XML and create plain and dumb value-type objects for feeds, items etc. (and kill it’s homegrown RDF parser/model…) Frank ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KF5Syndication
On Wed, Apr 22, 2015 at 9:44 PM, Daniel Vrátil wrote: > Hi all, > > I'd like to ask for review of another Framework from kdepimlibs: > KF5Syndication > > KF5Syndication is an RSS/Atom parsing library. It also provides API to > fetch > feeds directly from network. > > It's a Tier 3 Framework (depends on KCodecs and KIO). AFAIK it's currently > being > used only by Akregator. > > I would like to submit KF5Syndication for the standard 2 week review > period, and if everything is OK, then move it to Frameworks. > > Cheers, > Daniel > > Disclaimer: I've never seen this code nor knew about it's existence till ~30 minutes ago. This library depends on QtXml (quite heavily in fact). That very Qt module is deprecated [1]. Funnily enough, that is the only place that mentions it as being deprecated. No QtXml classes mention it in the docs and you won't get any compiler warnings either when you decide to use it. When searching for bug reports for deprecating QtXml i found [2] where they say it's been mislabeled and should have the same status as Widgets. Aka: done. Which also means it might go deprecated in some future release (Qt6?). Now i don't know what the real state of QtXml is, but if it really is deprecated then i don't know if it's wise to release this library while depending on a deprecated module. In that case it might be better to "port" (which probably requires quite some work) to the QXmlStreamReader and QXmlStreamWriter. Just my 5 cents :) [1] http://doc.qt.io/qt-5/qtmodules.html [2] https://bugreports.qt.io/browse/QTBUG-32926 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: ModemManagerQt
Time to move Modem Manager Qt now? Last Plasma 5.2.2 is tarred and KF 5.9 is due for tagging in 2 weeks. Jonathan On 16 March 2015 at 15:44, Jan Grulich wrote: > On Thursday 12 of March 2015 14:12 David Edmundson wrote: > > Looks good to me. > > 2 minor comments. > > > > All classes are namespaced, but generictypes.h is not. > > Given these names could easily clash with something else and are publicly > > included, it might be worth putting them in the same namespace. > > Done. > > > ModemManager::ModemMessaging::messages can be const? > > Yes, fixed. > > > > > David > > > > > > On Friday 13 of March 2015 00:06 Albert Astals Cid wrote: > > Kill the framework branch? > > Removed. > > > Move macros.h and mmdebug.h to _p.h? > > Done. > > > Can listBearers and findBearer be const? > > Yep, done. > > > In InterfaceType i'd say you can let the enums be there even if the > > MM_CHECK_VERSION doesn't match, makes sure in case some others are added > > later they always have the same "int" value > > Removed check. > > > Make BearerStruct, IpConfig and NetworkTimeZonea and the structs in > > generictypes.h classes with dptr in case you ever need more fields in > them? > > I made only BearerStruct, IpConfig and NetworkTimeZone as classes. Other > structures are just pairs and won't need more fields in future. > > > Add const & to params of ip4ConfigChanged, ip6ConfigChanged and > > networkTimeZoneChanged? > > Done. > > > Cheers, > > Albert > > > > Thanks, is there anything else? > > Regards, > Jan > -- > Jan Grulich > Red Hat Czech, s.r.o > jgrul...@redhat.com > ___ > 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: New framework: ModemManagerQt
On Thursday 12 of March 2015 14:12 David Edmundson wrote: > Looks good to me. > 2 minor comments. > > All classes are namespaced, but generictypes.h is not. > Given these names could easily clash with something else and are publicly > included, it might be worth putting them in the same namespace. Done. > ModemManager::ModemMessaging::messages can be const? Yes, fixed. > > David > > On Friday 13 of March 2015 00:06 Albert Astals Cid wrote: > Kill the framework branch? Removed. > Move macros.h and mmdebug.h to _p.h? Done. > Can listBearers and findBearer be const? Yep, done. > In InterfaceType i'd say you can let the enums be there even if the > MM_CHECK_VERSION doesn't match, makes sure in case some others are added > later they always have the same "int" value Removed check. > Make BearerStruct, IpConfig and NetworkTimeZonea and the structs in > generictypes.h classes with dptr in case you ever need more fields in them? I made only BearerStruct, IpConfig and NetworkTimeZone as classes. Other structures are just pairs and won't need more fields in future. > Add const & to params of ip4ConfigChanged, ip6ConfigChanged and > networkTimeZoneChanged? Done. > Cheers, > Albert > Thanks, is there anything else? Regards, Jan -- Jan Grulich Red Hat Czech, s.r.o jgrul...@redhat.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: ModemManagerQt
El Dijous, 12 de març de 2015, a les 09:56:06, Jan Grulich va escriure: > Hi all, > > I would like to ask you if you could review ModemManagerQt library > (currently as libmm-qt). I want to make it as framework before KF5 5.9.0 > gets released and make Plasma 5.3 depend on it, otherwise we would have to > release it again together with Plasma and wait three more months. The only > missing part there are unit-tests, but I'm working on them, I already added > one yesterday and will keep adding new ones. The API is very similar to > NetworkManagerQt, so everything mentioned during NMQT review should be > already fixed there. > > You can find it here under frameworks branch: > https://projects.kde.org/projects/kde/workspace/libmm-qt Kill the framework branch? Move macros.h and mmdebug.h to _p.h? Can listBearers and findBearer be const? In InterfaceType i'd say you can let the enums be there even if the MM_CHECK_VERSION doesn't match, makes sure in case some others are added later they always have the same "int" value Make BearerStruct, IpConfig and NetworkTimeZonea and the structs in generictypes.h classes with dptr in case you ever need more fields in them? Add const & to params of ip4ConfigChanged, ip6ConfigChanged and networkTimeZoneChanged? Cheers, Albert > > Thanks a lot. > > Regards, > Jan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: ModemManagerQt
Looks good to me. 2 minor comments. All classes are namespaced, but generictypes.h is not. Given these names could easily clash with something else and are publicly included, it might be worth putting them in the same namespace. ModemManager::ModemMessaging::messages can be const? David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: BluezQt
I'm forwarding the reply here too: > The name KF5BluezQt seems inelegant, is has both a prefix and a suffix, how > about just KF5Bluez? That would work, but only for cmake files, otherwise I would have to change namespace from BluezQt to just Bluez, which is obviously not a right thing. > The headers get installed into /usr/include/BluezQt/, I guess that should be > /usr/include/KF5/BluezQt/ ? > > It requires extra-cmake-modules 1.8 but seems to compile fine with 1.7. Fixed > Do you expect this to be moved into KDE Frameworks? That gets tagged > on April 4th. Or do you expect it to be moved into kde/workspace for > release with Plasma? That gets tagged in April 9th. > > If it goes into Frameworks it must remain API and ABI compatible while > in Plasma you only need to bump the soversion if it changes. Is it > ready for that? Originally, I wanted to move it to frameworks. But if i think about it again, I plan to extend the library with new features which may break the ABI. So, I would like to move it to kde/workspace once reviewed. Thanks, David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: BluezQt
On Tue, Mar 10, 2015 at 10:12:31PM +0100, David Rosca wrote: > BluezQt is a wrapper library for Bluez 5 DBus API. It will be > used in Bluedevil as a replacement for libbluedevil. > It is currently in playground (playground/libs/bluez-qt). > > It should be a Tier 1 framework (only depends on Qt libs). > > The code should follow all framework policies and the build is green, > so I'd like to submit BluezQt for review. Also sent this to the other thread on kde-core-devel... Looks like you've been working hard :) The name KF5BluezQt seems inelegant, is has both a prefix and a suffix, how about just KF5Bluez ? The headers get installed into /usr/include/BluezQt/, I guess that should be /usr/include/KF5/BluezQt/ ? It requires extra-cmake-modules 1.8 but seems to compile fine with 1.7. Do you expect this to be moved into KDE Frameworks? That gets tagged on April 4th. Or do you expect it to be moved into kde/workspace for release with Plasma? That gets tagged in April 9th. If it goes into Frameworks it must remain API and ABI compatible while in Plasma you only need to bump the soversion if it changes. Is it ready for that? Jonathan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KXmlRpcClient
On Thursday 26 February 2015 01:06:40 Albert Astals Cid wrote: > El Dimecres, 25 de febrer de 2015, a les 13:23:42, David Faure va escriure: > > On Wednesday 28 January 2015 20:01:45 Albert Astals Cid wrote: > > > El Dimecres, 28 de gener de 2015, a les 16:17:53, David Faure va escriure: > > > > On Monday 26 January 2015 15:25:34 Daniel Vrátil wrote: > > > > > Bump. > > > > > > > > > > We would really love to get this to 5.7, so unless anyone objects, > > > > > I'll > > > > > wait couple days, then file a sysadmin request and flip the > > > > > 'Release' > > > > > flag > > > > > in the YAML file to true. > > > > > > > > Did you check the frameworks checklist? > > > > > > > > https://community.kde.org/Frameworks/CreationGuidelines > > > > > > > > One of the items is "green in CI", which it's not. > > > > http://build.kde.org/view/Frameworks/job/kxmlrpcclient_master_qt5/ > > > > > > > > > > > > I took care of adding this job to view/Frameworks, but it seems a > > > > kxmlrpcclient_stable_qt5 is missing, compared to the other frameworks? > > > > > > Well it hasn't had a stable release yet, so why there should be a > > > _stable > > > job? > > > > I thought _stable was about the underlying Qt 5 version. > > _stable jobs exist because on how our jenkins architecture work, you can't > have plasma_desktop_stable job building against kcoreaddons_master, you need > it to be kcoreaddons_stable > > Now, you're right that they also build against an older Qt5, and that's > good, but it's not the main reason the _stable jobs are. > > I'd prefer to make sure we don't have a kxmlrpcclient_stable job until it's > released, that way if by mistake other _stable jobs try to use it, they will > fail, signaling they are trying to build against an unreleased lib. > > What do you think? OK, I see, thanks for the explanation. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New build dependency in KF5
On Tuesday 03 of March 2015 13:06:19 Aleix Pol wrote: > Hi, > My build had been failing for the last days, I just realized that the > issue was that we're now depending on URI/Escape.pm in order to encode > uri's from cmake in kdelibs4support and kdoctools. > > Was this intentional? Yes, it is. Yes, it's likely my mistake that I didn't add a failure in the configuring phase. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KXmlRpcClient
El Dimecres, 25 de febrer de 2015, a les 13:23:42, David Faure va escriure: > On Wednesday 28 January 2015 20:01:45 Albert Astals Cid wrote: > > El Dimecres, 28 de gener de 2015, a les 16:17:53, David Faure va escriure: > > > On Monday 26 January 2015 15:25:34 Daniel Vrátil wrote: > > > > Bump. > > > > > > > > We would really love to get this to 5.7, so unless anyone objects, > > > > I'll > > > > wait couple days, then file a sysadmin request and flip the 'Release' > > > > flag > > > > in the YAML file to true. > > > > > > Did you check the frameworks checklist? > > > > > > https://community.kde.org/Frameworks/CreationGuidelines > > > > > > One of the items is "green in CI", which it's not. > > > http://build.kde.org/view/Frameworks/job/kxmlrpcclient_master_qt5/ > > > > > > > > > I took care of adding this job to view/Frameworks, but it seems a > > > kxmlrpcclient_stable_qt5 is missing, compared to the other frameworks? > > > > Well it hasn't had a stable release yet, so why there should be a _stable > > job? > > I thought _stable was about the underlying Qt 5 version. _stable jobs exist because on how our jenkins architecture work, you can't have plasma_desktop_stable job building against kcoreaddons_master, you need it to be kcoreaddons_stable Now, you're right that they also build against an older Qt5, and that's good, but it's not the main reason the _stable jobs are. I'd prefer to make sure we don't have a kxmlrpcclient_stable job until it's released, that way if by mistake other _stable jobs try to use it, they will fail, signaling they are trying to build against an unreleased lib. What do you think? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KXmlRpcClient
On Wednesday 11 February 2015 15:03:06 Aleix Pol wrote:
> On Thu, Jan 8, 2015 at 6:08 PM, Daniel Vrátil wrote:
> > Hi all,
> >
> > KXmlRpcClient provides a complete XMLRPC client for applications to use.
> > It's used most notably by DrKonqi to talk to b.k.o. It's the first
> > framework split from kdepimlibs that we feel is ready to be shipped with
> > KDE Frameworks.
> >
> > I went through the code, fixed couple minor problems I spotted and added
> > unit- tests to test the (de)marshaller code properly.
> >
> > It should be a Tier 3 framework, as it depends on KIO (for HTTP
> > interaction).
> >
> > I would like to submit the KXmlRpcClient for the standard 2 week review
> > period, and if everything is OK, then move it to Frameworks (so we can
> > finally drop the bundled copy from DrKonqi ;-)).
> >
> > Cheers,
> > Daniel
>
> Hi,
> What's the status of this?
>
> I might be able to help if there's some task to be done.
AFAICS it's all set for being part of KF 5.8.
Ah, except one thing, it has weird version numbering for the .so itself.
Can I apply this?
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 01e6de9..084910b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -18,10 +18,9 @@ include(KDEFrameworkCompilerSettings)
set(KF5_VERSION "5.8.0") # handled by release scripts
set(KF5_DEP_VERSION "5.7.0") # handled by release scripts
-set(KXMLRPCCLIENT_LIB_VERSION "4.79.0")
add_definitions(-DTRANSLATION_DOMAIN=\"libkxmlrpcclient5\")
-ecm_setup_version(${KXMLRPCCLIENT_LIB_VERSION} VARIABLE_PREFIX KXMLRPCCLIENT
+ecm_setup_version(${KF5_VERSION} VARIABLE_PREFIX KXMLRPCCLIENT
VERSION_HEADER
"${CMAKE_CURRENT_BINARY_DIR}/kxmlrpcclient_version.h"
PACKAGE_VERSION_FILE
"${CMAKE_CURRENT_BINARY_DIR}/KF5XmlRpcClientConfigVersion.cmake"
SOVERSION 5
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KXmlRpcClient
On Wednesday 28 January 2015 20:01:45 Albert Astals Cid wrote: > El Dimecres, 28 de gener de 2015, a les 16:17:53, David Faure va escriure: > > On Monday 26 January 2015 15:25:34 Daniel Vrátil wrote: > > > Bump. > > > > > > We would really love to get this to 5.7, so unless anyone objects, I'll > > > wait couple days, then file a sysadmin request and flip the 'Release' > > > flag > > > in the YAML file to true. > > > > Did you check the frameworks checklist? > > > > https://community.kde.org/Frameworks/CreationGuidelines > > > > One of the items is "green in CI", which it's not. > > http://build.kde.org/view/Frameworks/job/kxmlrpcclient_master_qt5/ > > > > > > I took care of adding this job to view/Frameworks, but it seems a > > kxmlrpcclient_stable_qt5 is missing, compared to the other frameworks? > > Well it hasn't had a stable release yet, so why there should be a _stable > job? I thought _stable was about the underlying Qt 5 version. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KXmlRpcClient
On Fri, Feb 13, 2015 at 10:34 AM, Harald Sitter wrote: > > > > Can someone tell the distro packagers list they'll have a duplciation > issue > > when using frameworks 5.8 + Plasma 5.2? > > if the translation catalog gets renamed there is no conflict. > currently it is libkxmlrpcclient5.pot, so simply aligning that with > the actual library name would neatly solve this. > > in workspace xmlrpc was handled as a private lib (filename had a > private suffix, no cmake config installed, no headers installed etc.) > so tother than translations here should be no problems mixing kf5.8 > with plasma5.2. > It should still probably get an "if" in the plasma-workspace to not build the internal library with frameworks 5.8 though. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KXmlRpcClient
On Thu, Feb 12, 2015 at 8:25 PM, Albert Astals Cid wrote: > El Dijous, 12 de febrer de 2015, a les 12:31:14, Daniel Vrátil va escriure: >> On Friday, January 30, 2015 09:12:01 AM David Faure wrote: >> > On Wednesday 28 January 2015 17:12:04 Daniel Vrátil wrote: >> > > I guess I should update kde-build-metadata and release-tools and ask for >> > > the _stable_qt5 build once the repo is moved to frameworks on >> > > projects.k.o, so that changes don't have to be done twice (I don't >> > > really >> > > know if build.k.o has to be updated when module moves...?). >> > >> > No, build.kde.org uses a git url, so it doesn't matter where the module is >> > logically placed on projects.kde.org. >> > >> > But yes, for kde-build-metadata it matters. >> > >> > (there is nothing to update in release-tools, just set release to true in >> > your yaml file) >> >> KXmlRpcClient has been moved to frameworks. I enabled the "release" flag, >> adjusted kde-build-metadata, created bugzilla entry, so we should be good to >> go. > > Can someone tell the distro packagers list they'll have a duplciation issue > when using frameworks 5.8 + Plasma 5.2? if the translation catalog gets renamed there is no conflict. currently it is libkxmlrpcclient5.pot, so simply aligning that with the actual library name would neatly solve this. in workspace xmlrpc was handled as a private lib (filename had a private suffix, no cmake config installed, no headers installed etc.) so tother than translations here should be no problems mixing kf5.8 with plasma5.2. HS ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KXmlRpcClient
El Dijous, 12 de febrer de 2015, a les 12:31:14, Daniel Vrátil va escriure: > On Friday, January 30, 2015 09:12:01 AM David Faure wrote: > > On Wednesday 28 January 2015 17:12:04 Daniel Vrátil wrote: > > > I guess I should update kde-build-metadata and release-tools and ask for > > > the _stable_qt5 build once the repo is moved to frameworks on > > > projects.k.o, so that changes don't have to be done twice (I don't > > > really > > > know if build.k.o has to be updated when module moves...?). > > > > No, build.kde.org uses a git url, so it doesn't matter where the module is > > logically placed on projects.kde.org. > > > > But yes, for kde-build-metadata it matters. > > > > (there is nothing to update in release-tools, just set release to true in > > your yaml file) > > KXmlRpcClient has been moved to frameworks. I enabled the "release" flag, > adjusted kde-build-metadata, created bugzilla entry, so we should be good to > go. Can someone tell the distro packagers list they'll have a duplciation issue when using frameworks 5.8 + Plasma 5.2? Cheers, Albert > > David, could you please add it to release-tools? Apparently I don't have the > rights :-) > > > Thanks, > Dan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New framework: KXmlRpcClient
On Thursday 12 February 2015 12:31:14 Daniel Vrátil wrote: > On Friday, January 30, 2015 09:12:01 AM David Faure wrote: > > On Wednesday 28 January 2015 17:12:04 Daniel Vrátil wrote: > > > I guess I should update kde-build-metadata and release-tools and ask for > > > the _stable_qt5 build once the repo is moved to frameworks on > > > projects.k.o, so that changes don't have to be done twice (I don't > > > really > > > know if build.k.o has to be updated when module moves...?). > > > > No, build.kde.org uses a git url, so it doesn't matter where the module is > > logically placed on projects.kde.org. > > > > But yes, for kde-build-metadata it matters. > > > > (there is nothing to update in release-tools, just set release to true in > > your yaml file) > > KXmlRpcClient has been moved to frameworks. I enabled the "release" flag, > adjusted kde-build-metadata, created bugzilla entry, so we should be good to > go. Great. > David, could you please add it to release-tools? Apparently I don't have the > rights :-) Again: don't worry about release-tools, it gets updated automatically at release time, based on the release flag in the yaml files. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 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: New framework: KXmlRpcClient
On Friday, January 30, 2015 09:12:01 AM David Faure wrote: > On Wednesday 28 January 2015 17:12:04 Daniel Vrátil wrote: > > I guess I should update kde-build-metadata and release-tools and ask for > > the _stable_qt5 build once the repo is moved to frameworks on > > projects.k.o, so that changes don't have to be done twice (I don't really > > know if build.k.o has to be updated when module moves...?). > > No, build.kde.org uses a git url, so it doesn't matter where the module is > logically placed on projects.kde.org. > > But yes, for kde-build-metadata it matters. > > (there is nothing to update in release-tools, just set release to true in > your yaml file) KXmlRpcClient has been moved to frameworks. I enabled the "release" flag, adjusted kde-build-metadata, created bugzilla entry, so we should be good to go. David, could you please add it to release-tools? Apparently I don't have the rights :-) Thanks, Dan -- Daniel Vrátil | dvra...@redhat.com | dvratil on #kde-devel, #kontact, #akonadi Software Engineer - KDE Desktop Team, Red Hat Inc. 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: New framework: KXmlRpcClient
On Thu, Jan 8, 2015 at 6:08 PM, Daniel Vrátil wrote: > Hi all, > > KXmlRpcClient provides a complete XMLRPC client for applications to use. It's > used most notably by DrKonqi to talk to b.k.o. It's the first framework split > from kdepimlibs that we feel is ready to be shipped with KDE Frameworks. > > I went through the code, fixed couple minor problems I spotted and added unit- > tests to test the (de)marshaller code properly. > > It should be a Tier 3 framework, as it depends on KIO (for HTTP interaction). > > I would like to submit the KXmlRpcClient for the standard 2 week review > period, and if everything is OK, then move it to Frameworks (so we can finally > drop the bundled copy from DrKonqi ;-)). > > Cheers, > Daniel > Hi, What's the status of this? I might be able to help if there's some task to be done. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
