Re: KDE Frameworks 6 - Virtual Sprint setup

2021-02-03 Thread Volker Krause
On Freitag, 29. Januar 2021 15:57:59 CET Adam Szopa wrote:
> Hello,
> I've been talking with David Faure about setting up a Sprint focused on KF6 
> work. Some of the topics would include:
> - Reviewing the KF6 board
> (https://phabricator.kde.org/project/board/310/[1]): -- Clean up
> -- Tagging Junior Jobs
> - Working out a structure/process for handling:
> -- "Stuck" tasks
> -- Unit test regressions
> - Decide the 5.15 minimum requirement bump timeline
> - Decide on a 6 branching strategy and timeline
> - Decide if/how ECM should support multiple Qt versions
> 
> That's just an example list - the wiki[1] should include the up to date and
> detailed topics.
> 
> The Sprint will use the KDE BBB instance - same tech that powered last years
>  Akademy; I'll coordinate that with our sysadmins to have it available.
> 
> As for the date and length, usually Virtual Sprints are a weekend thing. I'd
> love to hear from you if that sounds OK, and which weekend would be
> workable for you (how soon can we get this started) and your preferred
> availability hours. I'll set up a poll later to pinpoint the final timing.

Poll: https://framadate.org/LGvewKljewnW6836
Wiki: https://community.kde.org/Sprints/KF6/2021Virtual

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.


Re: KDE Frameworks 6 - Virtual Sprint setup

2021-01-30 Thread Volker Krause
On Freitag, 29. Januar 2021 15:57:59 CET Adam Szopa wrote:
> Hello,
> I've been talking with David Faure about setting up a Sprint focused on KF6 
> work. Some of the topics would include:
> - Reviewing the KF6 board
> (https://phabricator.kde.org/project/board/310/[1]): -- Clean up
> -- Tagging Junior Jobs
> - Working out a structure/process for handling:
> -- "Stuck" tasks
> -- Unit test regressions
> - Decide the 5.15 minimum requirement bump timeline
> - Decide on a 6 branching strategy and timeline
> - Decide if/how ECM should support multiple Qt versions
> 
> That's just an example list - the wiki[1] should include the up to date and
> detailed topics.
> 
> The Sprint will use the KDE BBB instance - same tech that powered last years
>  Akademy; I'll coordinate that with our sysadmins to have it available.
> 
> As for the date and length, usually Virtual Sprints are a weekend thing. I'd
> love to hear from you if that sounds OK, and which weekend would be
> workable for you (how soon can we get this started) and your preferred
> availability hours. I'll set up a poll later to pinpoint the final timing.

Thanks for driving this, I'm in! European hours preferred, any weekend 
starting from w6 should be possible.

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.


Re: KDE review for KWeatherCore

2021-01-02 Thread Volker Krause
On Samstag, 2. Januar 2021 12:44:31 CET Dominik Haumann wrote:
> This is just by looking at the first two header files.
> 
> Looking at WeatherForecast.cpp:
> 
> double maxTemp = std::numeric_limits::min();
> double minTemp = std::numeric_limits::max();
> 
> Initializing the temperature to 0, 0, sounds a bit more sane to me, but
> that is disputable I guess.

Nice find. This looks quite familiar, the weather forecast accumulation code 
in Itinerary does something very much like this, to make std::min/std::max 
work without special-casing invalid values.

However the way it's done here will fail for negative max temperatures, as 
std::numeric_limits::min() is not what one might expect (it's the 
smallest positive value for floating point types), you want 
std::numeric_limits::lowest().

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.


Re: KDE review for KWeatherCore

2020-12-21 Thread Volker Krause
Having implemented the weather support for Itinerary, rebasing that onto a 
more comprehensive framework would indeed be welcome :)

I haven't looked too deeply at the implementation or the API yet, most of the 
feedback below is based on things learned when implementing this for 
Itinerary.

## api.met.no license and ToS compliance

The data is coming from the Norwegian Meteorological Institute, CC-licensed 
and with an API that doesn't require authentication, well documented and with 
a mailinglist for service changes and roadmap/disruption announcements. As far 
as implementing Open Data by organizations/public administration goes this is 
exemplary and unfortunately quite rare.

So at the very least we should follow their license and terms of services as 
close as possible, in letter and in spirit. Not all of that can be ensured by 
the library, some of this needs to be handled by the application. In the 
latter case those requirements need to be clearly documented though.

In particular I remember implementing the following aspects:

(1) add a point of contact to the User-Agent header, in case your client 
misbehaves. I only see this done in one place, https://invent.kde.org/
libraries/kweathercore/-/blob/master/src/weatherforecastsource.cpp#L52, which 
looks suspiciously like a verbatim copy from Itinerary, without even adjusting 
the contact address.

(2) Request throttling. The ToS seem to have been changed in wording since I 
last looked at this, but the requirement is still similar: Ensure we don't run 
unnecessary many queries. The Itinerary implementation uses a random interval 
between 120-150 minutes as lower bound, based on previous suggestions in the 
ToS.

The already suggested daemon is one way to ensure this globally, however I'm 
very reluctant to suggest a daemon for this, considering the deployment issues 
this causes for e.g. Flatpak or APKs. Itinerary uses a simple file cache and 
file mtimes, something like this should also hold up in a multi-process setup 
with a bit of extra care I think.

(3) Attribution, as required by the CC-BY license. This has to happen in the 
UI, but as a library user I need to know about this requirement, so this needs 
prominent mention in the docs I'd say.

See https://api.met.no/doc/TermsOfService for more details.


I also see other services used there I'm not familiar with, are we complying 
with their licenses and terms of services?


## Privacy considerations

(1) Requested geo coordinates are passed to the online API as-is, ie. this is 
potentially leaking a high-resolution position of the user to the outside. We 
can't avoid this entirely obviously, but we can reduce the impact by reducing 
the coordinate resolution. 

Itinerary uses 1/10th of a degree for this, which unless you get close to the 
poles are areas of a few kilometers in size, ie. rather than leaking your home 
address it's only leaking your home town.

(2) What does the sunrise API offer beyond the existing sunrise API we have in 
KF5::Holidays? The latter has the advantage of doing the entire calculation 
locally.

See https://api.kde.org/frameworks/kholidays/html/
namespaceKHolidays_1_1SunRiseSet.html

(3) Similarly, we do have a full offline implementation for timezone lookup by 
geo coordinates here: https://api.kde.org/kdepim/kitinerary/html/
namespaceKItinerary_1_1KnowledgeDb.html#ac409f468badee3c05438695009d7c67f

(4) There are http: only requests send to api.geonames.org it seems.


Similarly as with the compliance point, some of this can be argued to be the 
job of the using application. It would seem safer though is the library would 
try  to avoid mistakes to begin with.


## Other observations

(1) The license seems to be GPL-2.0-or-later, which is incompatible with the 
Frameworks license policy. See https://community.kde.org/Policies/
Licensing_Policy

(2) The result types (DailyForecast, HourlyForecast, etc) might benefit from 
being Q_GADGETs and having Q_PROPERTYs added, so they can be directly consumed 
by QML?

(3) binary compatibility measures seem to be missing in a number of places: 
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B


Regards,
Volker

On Montag, 21. Dezember 2020 07:16:09 CET hanyoung wrote:
> KWeatherCore: https://invent.kde.org/libraries/kweathercore is a library for
> querying weather forecast data. During the development of KWeather, we
> found the need to have a weather library. KWeatherCore is the result of
> extracting weather data fetching code from KWeather. I think having a
> dedicated weather library can serve the following propose: - simplify the
> KWeather code
> - easier to develop a weather daemon
> - potentially less code duplication across KDE
> 
> Many of you may have already seen my previous email to kde-devel mailing
> list.
> Thank you for your constructive suggestions. Here are something I want to 
clarify:
> > I would also propose to consider doing a demon instead, so different
> > 

Re: RFC: Switching to min Qt version 5.14 for KF on December 14th

2020-12-07 Thread Volker Krause
On Sonntag, 6. Dezember 2020 14:20:47 CET Friedrich W. H. Kossebau wrote:
> you might have seen I asked* whether anyone knows a real world requirement
> to stick with Qt 5.13 as new current minimum required Qt version for
> current KF releases. So far no-one had to report a reason to support Qt >=
> 5.13 instead of only Qt >= 5.14 now.
> * E.g.
> https://mail.kde.org/pipermail/distributions/2020-December/000894.html
> 
> So hereby I propose to switch for KF 5.78 to Qt 5.14 as minimum version, and
> change the KF dependencies policy text* to this:
> * https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements
> 
> "
> With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5
> versions would be released. Then adapt to actual real world usage of a given
> Qt version:
> * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e.
> on 26 Nov 2020
> * Qt 5.14 would be the minimum required version 12 months after Qt 5.15,
> i.e. on 26 May 2021. With no-one known to stick with Qt 5.13, the date is
> moved to earlier mid-December 2020.
> * Qt 5.15 LTS will be the minimum required version 18 months after its
> release, i.e. on 26 Nov 2021
> "

Thanks! I'm generally in favor of an accelerated path to Qt 5.15 as the 
minimum dependency in the light of the upcoming Qt 6 transition. The proposed 
approach only addresses half of the problem though, we'll end up with the same 
discussion in a few month again I fear. Would it therefore make sense to cover 
this as well now, so people can plan ahead?

For example:

> With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5
> versions would be released on a slightly accelerated schedule to match the 
> expected convergence towards the final Qt5 release:
> * Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e.
> on 26 Nov 2020
> * Qt 5.14 would be the minimum required version 7 months after Qt 5.15,
> i.e. on 26 Dec 2020.
> * Qt 5.15 LTS will be the minimum required version 12 months after its
> release, i.e. on 26 May 2021

(I'm not tied to any specific date in there, but you get the idea)


One thing I haven't really seen addressed yet is Krita's concerns about newer 
Qt versions, how do we want to handle that?

Regards,
Volker





Re: KUserFeedback => Frameworks?

2020-10-09 Thread Volker Krause
On Freitag, 9. Oktober 2020 21:17:42 CEST Christoph Cullmann wrote:
> On 2020-09-26 21:52, Christoph Cullmann wrote:
> > Hi,
> > 
> > is there any real reason why KUserFeedback is yet no official
> > framework?
> > 
> > I just stumbled over this during my try to add it as dependency for
> > the Windows builds of Kate.
> > 
> > Given at least the Plasma Desktop itself and Kate uses this now,
> > wouldn't it make sense to have it in the regular releases?
> 
> Hi,
> 
> any feedback on this?

it IMHO should move to some form of release automation for sure, so at least 
release service. And given it's needed by Plasma as well, Frameworks might be 
even better.

Regards,
Volker




Re: Dropping the moderation by default flag

2020-07-22 Thread Volker Krause
On Tuesday, 21 July 2020 21:16:00 CEST Albert Astals Cid wrote:
> Hi, this list has an unusual setting [for kde mailing lists] inherited from
> kde-core-devel that is that even subscribed people get moderated, and then
> the list moderator can decide to clear the moderate flag for each person
> one by one.
> 
> I'm proposing to change that because:
>  * it's non consistent with the rest of kde mailing lists
>  * as moderator of this list i don't think i've seen ever any spam coming
> from a subscribed member.
> 
> Opinions?

+1. That setup on core-devel was already around in the early 2000s, so 
probably a response to some events from 20 years ago, I doubt we still need 
that today.

Regards,
Volker




D29747: Deprecate AbstractBarcode::minimumSize() also for the compiler

2020-06-22 Thread Volker Krause
vkrause accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R280 Prison

BRANCH
  fullydeprecateminimumsize

REVISION DETAIL
  https://phabricator.kde.org/D29747

To: kossebau, #frameworks, svuorela, vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


Re: Shift for parts of the CI system to Qt 5.15

2020-06-20 Thread Volker Krause
On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> Hi all,
> 
> This weekend parts of our CI system shifted to using Qt 5.15, with all
> FreeBSD builds now being based on Qt 5.15. We also shifted all Linux
> builds of Plasma, and the latest Qt version build of Frameworks to Qt
> 5.15 as well (apologies for the massive amount of email this kicked
> up)
> 
> It has however exposed a series of SIC changes in Qt which will need
> to be adapted to. The list of affected projects appears to be as
> follows:
> - kalarm
> - kdesdk-kioslaves
> - kompare
> - subtitlecomposer

all fixed

> - kaffeine

This doesn't look like something caused by Qt 5.15, more like an issue with 
the FreeBSD DVB headers, builds on Linux.

> In addition, the following projects appear to have long standing build
> issues. It would be appreciated if they could please investigate and
> correct these:
> - kbibtex

fixed

> - atcore
> - kmymoney

MSVC-only, or rather GCC/clang being a bit too forgiving. 

atcore looks like an ambiguous default argument, removing that should fix it, 
but since this is a public interface I didn't want to just change this, being 
unable to estimate the impact.

kmymoney is using an exported class in two DLLs with the same export macro, 
that doesn't work. Needs more insights into the project to restructure that 
accordingly I think.

> - ring-kde

build errors seem to be in stuff downloaded by cmake!?

> Further, the following project appears to have a broken build due to
> SIC changes within another KDE project:
> - zanshin

fixed

Regards,
Volker





Re: New Framework Review: KDAV

2020-06-20 Thread Volker Krause
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 ne

Re: New Framework Review: KDAV

2020-06-19 Thread Volker Krause
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

2020-06-14 Thread Volker Krause
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 inconsist

D29747: Deprecate AbstractBarcode::minimumSize() also for the compiler

2020-05-26 Thread Volker Krause
vkrause added a comment.


  PIM has been fully adapted meanwhile, only https://phabricator.kde.org/D29478 
missing I think.

REPOSITORY
  R280 Prison

REVISION DETAIL
  https://phabricator.kde.org/D29747

To: kossebau, #frameworks, svuorela, vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


Re: New Framework Review: KDAV

2020-05-24 Thread Volker Krause
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/D

Re: KEmoticons, emoticons kcm

2020-05-23 Thread Volker Krause
On Saturday, 23 May 2020 02:49:57 CEST Aleix Pol wrote:
> I was looking through some Plasma code and I saw that we have some
> fairly old emoticons KCM using KF5Emoticons.
> 
> Now while I know why this exists, it feels like it's more of a thing
> of the past from when people wrote :) instead of . While keeping it
> around for the few apps that might still use it (ktp? kopete?) could
> make sense, I'm afraid it's probably making it confusing for the users
> who expect this to actually allow them to customise their  but
> won't.
> 
> Do you think it would make sense to deprecate the framework and remove the
> KCM?

Absolutely! 

There's some discussion on this topic in https://phabricator.kde.org/T11585 
already. While direct usage of KEmoticons in applications is rare, there is a 
"backdoor dependency" via a KCoreAddons plug-in it provides.

Regards,
Volker




D29358: Implement lock-screen visibility control on Android

2020-05-23 Thread Volker Krause
vkrause closed this revision.

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D29358

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29358: Implement lock-screen visibility control on Android

2020-05-22 Thread Volker Krause
vkrause updated this revision to Diff 83104.
vkrause added a comment.


  Rename visibility hint.

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29358?vs=81734=83104

BRANCH
  pending

REVISION DETAIL
  https://phabricator.kde.org/D29358

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29358: Implement lock-screen visibility control on Android

2020-05-19 Thread Volker Krause
vkrause added a comment.


  ping?

REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D29358

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29335: Implement notification grouping on Android

2020-05-19 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R289:942bddded289: Implement notification grouping on Android 
(authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29335?vs=81731=83063#toc

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29335?vs=81731=83063

REVISION DETAIL
  https://phabricator.kde.org/D29335

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29357: Display rich text notification messages on Android

2020-05-18 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R289:c14be41192d2: Display rich text notification messages on 
Android (authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29357?vs=82566=83046#toc

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29357?vs=82566=83046

REVISION DETAIL
  https://phabricator.kde.org/D29357

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, tfella
Cc: z3ntu, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D27989: Add a new set of barcode size functions

2020-05-14 Thread Volker Krause
vkrause added a comment.


  In D27989#670416 , @kossebau wrote:
  
  > > minimumSize() becomes deprecated by this, the deprecation macros will
  > >  follow once the current users have been adjusted.
  >
  > IMHO you should add the macros from the start, otherwise it will be only 
forgotten later, as there is no mechanism to remind you. And without compiler 
warnings all the remaining users might never learn about it.
  >
  > I would expect you have prepared patches for some known users already to 
testdrive the new API for usefulness, so the set of remaining users (in KDE 
spheres) should be already small. And those not yet withzout a patch, what 
would be the plan to care for them? In the end it needs to compiler warnings to 
get other people in the game. After all API is not deprecated without a reason. 
Being too gentle with warnings does not help anyone in the end.
  
  
  There's two remaining users in everything covered by lxr, the Plasma 
clipboard (patch in review: https://phabricator.kde.org/D29478) and KDE PIM 
(which now depends on a sufficiently new KF5 version to actually do the 
migration). Both ways can be argued of course, I optimized for "helps me" (the 
warnings for things I can't change yet don't), and "migration is my problem" 
rather than "migration is somebody else's problem" (which is my understanding 
of how we are supposed to be doing KF deprecations to ease the 6 transition).

REPOSITORY
  R280 Prison

REVISION DETAIL
  https://phabricator.kde.org/D27989

To: vkrause, svuorela
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29357: Display rich text notification messages on Android

2020-05-11 Thread Volker Krause
vkrause retitled this revision from "Display rich text notification messages on 
Android (API level 24+)" to "Display rich text notification messages on 
Android".

REPOSITORY
  R289 KNotifications

BRANCH
  rich-text

REVISION DETAIL
  https://phabricator.kde.org/D29357

To: vkrause, tfella
Cc: z3ntu, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29357: Display rich text notification messages on Android (API level 24+)

2020-05-11 Thread Volker Krause
vkrause updated this revision to Diff 82566.
vkrause added a comment.


  Support API level < 24 as well.

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29357?vs=81729=82566

BRANCH
  rich-text

REVISION DETAIL
  https://phabricator.kde.org/D29357

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, tfella
Cc: z3ntu, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29575: holidayregion.cpp - provide translatable strings for the German regions.

2020-05-11 Thread Volker Krause
vkrause accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R175 KHolidays

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29575

To: winterz, vkrause
Cc: ltoscano, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29274: ECMGeneratePriFile: make the pri files relocatable

2020-05-08 Thread Volker Krause
vkrause accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29274

To: dfaure, vatra, kfunk, apol, vkrause
Cc: ablu, kossebau, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
bencreasy, michaelh, ngraham, bruns


D29342: Implement support for notification urgency on Android

2020-05-07 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R289:9a13dd26d1de: Implement support for notification urgency 
on Android (authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29342?vs=81695=82227#toc

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29342?vs=81695=82227

REVISION DETAIL
  https://phabricator.kde.org/D29342

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29415: Add holiday file for DE-BE (Germany/Berlin)

2020-05-05 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R175:c39d1eb12217: Add holiday file for DE-BE (Germany/Berlin) 
(authored by vkrause).

REPOSITORY
  R175 KHolidays

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29415?vs=81905=81999

REVISION DETAIL
  https://phabricator.kde.org/D29415

AFFECTED FILES
  holidays/holidays.qrc
  holidays/plan2/holiday_de-be_de

To: vkrause, winterz
Cc: winterz, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29415: Add holiday file for DE-BE (Germany/Berlin)

2020-05-04 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  The generic DE file doesn't really work anymore since Berlin got creative
  in adding non-standard public holidays.

REPOSITORY
  R175 KHolidays

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29415

AFFECTED FILES
  holidays/holidays.qrc
  holidays/plan2/holiday_de-be_de

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29358: Implement lock-screen visibility control on Android

2020-05-02 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This is only the backend part, lacking a proper frontend API this is
  using a custom hint for now. Android knows three levels for this:
  
  - public: visible completely on the lock screen
  - private: lock screen only shows that $app has notifications
  - secret: nothing shown on the lock screen at all

REPOSITORY
  R289 KNotifications

BRANCH
  pending

REVISION DETAIL
  https://phabricator.kde.org/D29358

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29335: Implement notification grouping on Android

2020-05-02 Thread Volker Krause
vkrause updated this revision to Diff 81731.
vkrause added a comment.


  Replace the simple ref count with a full child id tracking.
  
  The ref count got out of sync when an existing notification is updated, using 
a set fixes that.

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29335?vs=81725=81731

BRANCH
  grouping

REVISION DETAIL
  https://phabricator.kde.org/D29335

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29335: Implement notification grouping on Android

2020-05-02 Thread Volker Krause
vkrause added a comment.


  Still not good enough, updating existing notfication messes up the 
refcounter, resulting still in leftover group elements.

REPOSITORY
  R289 KNotifications

BRANCH
  grouping

REVISION DETAIL
  https://phabricator.kde.org/D29335

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29357: Display rich text notification messages on Android (API level 24+)

2020-05-02 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REPOSITORY
  R289 KNotifications

BRANCH
  pending

REVISION DETAIL
  https://phabricator.kde.org/D29357

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29357: Display rich text notification messages on Android (API level 24+)

2020-05-02 Thread Volker Krause
vkrause added a comment.


  Example: F8278136: Screenshot_20200502_112835.PNG 


REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D29357

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29335: Implement notification grouping on Android

2020-05-02 Thread Volker Krause
vkrause updated this revision to Diff 81725.
vkrause added a comment.


  Explicitly track if notification groups are still in use.
  
  This fixes group summaries staying active when we explicitly
  close a notification, rather then having the user or system
  dismiss it.

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29335?vs=81678=81725

BRANCH
  grouping

REVISION DETAIL
  https://phabricator.kde.org/D29335

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29335: Implement notification grouping on Android

2020-05-02 Thread Volker Krause
vkrause added a comment.


  This isn't good to go yet, there are corner cases where the group summary 
item stays around after closing the last notification, working on fixing this.

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29335

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29339: Implement updating of notifications on Android

2020-05-02 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R289:c5688295e45f: Implement updating of notifications on 
Android (authored by vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29339?vs=81686=81722#toc

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29339?vs=81686=81722

REVISION DETAIL
  https://phabricator.kde.org/D29339

AFFECTED FILES
  src/notifybyandroid.cpp
  src/notifybyandroid.h

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29323: Handle multi-line and rich-text notifications on Android

2020-05-02 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R289:9bfd98a3d3da: Handle multi-line and rich-text 
notifications on Android (authored by vkrause).

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29323?vs=81657=81721

REVISION DETAIL
  https://phabricator.kde.org/D29323

AFFECTED FILES
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause, nicolasfella
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29342: Implement support for notification urgency on Android

2020-05-01 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  While the notification levels map nicely, the behavior on Android with
  API level 26 or higher is slightly different from what one might expect:
  The urgency is configured on the notification channel the first time it
  is created, and then persisted together with the user's notification
  settings. That means that changes to the notification level after this
  has been used for the first time have no effect.

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29342

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29339: Implement updating of notifications on Android

2020-05-01 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29339

AFFECTED FILES
  src/notifybyandroid.cpp
  src/notifybyandroid.h

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29335: Implement notification grouping on Android

2020-05-01 Thread Volker Krause
vkrause added inline comments.

INLINE COMMENTS

> nicolasfella wrote in NotifyByAndroid.java:171
> Please use 
> https://developer.android.com/reference/android/os/Build.VERSION_CODES 
> instead of hardcoding numbers

That seems counter-productive to me, as the Android API documentation always 
speaks about API level numbers, so you'd need to do an additional translation 
to/from the letters in your head. So for that I find "26" more useful here than 
"O". It's also consistent with the rest of the code in this file.

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29335

To: vkrause, nicolasfella
Cc: nicolasfella, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29335: Implement notification grouping on Android

2020-05-01 Thread Volker Krause
vkrause added a comment.


  Collapsed: F8276057: Screenshot_20200501_161952.PNG 

  Expanded: F8276059: Screenshot_20200501_162043.PNG 


REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D29335

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29335: Implement notification grouping on Android

2020-05-01 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This is available starting at API level 20, which is below our minimal
  requirement. Grouping can be disabled by the already existing SkipGrouping
  flag.
  
  When enabled this puts all notifications from the same eventId in a group,
  which makes the display more compact by removing the otherwise duplicated
  app name.

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29335

AFFECTED FILES
  src/android/org/kde/knotifications/KNotification.java
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29323: Handle multi-line and rich-text notifications on Android

2020-05-01 Thread Volker Krause
vkrause added a comment.


  F8275264: Screenshot_20200501_124105.PNG 


REPOSITORY
  R289 KNotifications

REVISION DETAIL
  https://phabricator.kde.org/D29323

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29323: Handle multi-line and rich-text notifications on Android

2020-05-01 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  By default only a single line of the notification message is shown,
  for making longer messages readable we need to use the BigTextStyle
  to get expandable multi-line messages. In the single-line case this
  behaves as before.
  
  According to the documentation BigTextStyle also should enable rich
  text support, however that didn't seem to work here, so for now we
  strip out rich text to not show raw HTML tags.

REPOSITORY
  R289 KNotifications

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D29323

AFFECTED FILES
  src/android/org/kde/knotifications/NotifyByAndroid.java
  src/notifybyandroid.cpp

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29079: android: include the architecture on the apk name

2020-04-22 Thread Volker Krause
vkrause added a comment.


  +1, I can't judge the impact on the subsequent pipeline though, such as the 
fdroid repo handling.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D29079

To: apol, #android, #frameworks
Cc: vkrause, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
bencreasy, michaelh, ngraham, bruns


D28834: Add metadata properties to calendar

2020-04-14 Thread Volker Krause
vkrause added a comment.


  In D28834#648405 , @winterz wrote:
  
  > I don't know how things are done in frameworks but it seems to me that the 
KF5_VERSION (see top of kcalendarcore/CMakeLists.txt) needs to become 5.70.0 now
  
  
  This is handled automatically, no need to change this.

INLINE COMMENTS

> calendar.h:101
> +*/
> +enum CalendarType
> +{

As already noted in the previous review, "type" isn't the best naming for 
something that is about access control/permission IMHO.

A possible alternative name could be something like "AccessMode", or maybe even 
just bool isReadOnly.

REPOSITORY
  R172 KCalendar Core

BRANCH
  props

REVISION DETAIL
  https://phabricator.kde.org/D28834

To: nicolasfella, #frameworks, #kde_pim, vkrause, winterz
Cc: winterz, kde-pim, fbampaloukas, dcaliste, dvasin, rodsevich, vkrause, 
mlaurent, knauss, dvratil


D28400: [AdvancedQueryParser] Move semantic handling of tokens to SearchStore

2020-04-07 Thread Volker Krause
vkrause added inline comments.

INLINE COMMENTS

> bruns wrote in searchstore.cpp:82
> Thanks for the heads-up.
> 
> As you have noticed, the message is vague, so someone with access to one of 
> the affected systems should test it and submit a review.

I don't have either of those here to test it for sure, but I have fixed similar 
errors elsewhere recently for those platforms by just adding the  
include, so I think @kossebau is right.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D28400

To: bruns, #baloo, ngraham
Cc: vkrause, bcooksley, kossebau, kde-frameworks-devel, hurikhan77, lots0logs, 
LeGast00n, cblack, fbampaloukas, GB_2, domson, ashaposhnikov, michaelh, 
astippich, spoorun, ngraham, bruns, abrahams


D28577: Add StatusBarExtension(KParts::Part *) overloaded constructor.

2020-04-05 Thread Volker Krause
vkrause accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R306 KParts

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D28577

To: dfaure, vkrause, aacid, cgiboudeaux, kossebau
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


Re: New Framework Review: KDAV

2020-04-04 Thread Volker Krause
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.


D25984: Load translations

2020-03-19 Thread Volker Krause
vkrause added a comment.


  In D25984#589426 , @mart wrote:
  
  > ping, what's the current status of this?
  
  
  There's also https://phabricator.kde.org/D27595, which might address the 
same/a similar issue.

REPOSITORY
  R169 Kirigami

REVISION DETAIL
  https://phabricator.kde.org/D25984

To: broulik, #kirigami, #frameworks, kossebau, aacid
Cc: vkrause, mart, davidedmundson, plasma-devel, fbampaloukas, GB_2, domson, 
dkardarakos, ngraham, apol, ahiemstra


D28030: Also expose the true minimum size to QML

2020-03-15 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R280:e0dec83dd692: Also expose the true minimum size to QML 
(authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D28030?vs=77578=77650

REVISION DETAIL
  https://phabricator.kde.org/D28030

AFFECTED FILES
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27989: Add a new set of barcode size functions

2020-03-15 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R280:838f886c380f: Add a new set of barcode size functions 
(authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27989?vs=77441=77647

REVISION DETAIL
  https://phabricator.kde.org/D27989

AFFECTED FILES
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/quick/barcodequickitem.cpp

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27952: Simplify minimum size handling

2020-03-14 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R280:0d64bdd22e7c: Simplify minimum size handling (authored by 
vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27952?vs=77611=77612

REVISION DETAIL
  https://phabricator.kde.org/D27952

AFFECTED FILES
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27952: Simplify minimum size handling

2020-03-14 Thread Volker Krause
vkrause updated this revision to Diff 77611.
vkrause added a comment.


  Rebase and bump version numbers.

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27952?vs=77302=77611

BRANCH
  arcpatch-D27952

REVISION DETAIL
  https://phabricator.kde.org/D27952

AFFECTED FILES
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27909: Move barcode image scaling logic to AbstractBarcode

2020-03-14 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R280:ea1f6c1abeb0: Move barcode image scaling logic to 
AbstractBarcode (authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27909?vs=77158=77610

REVISION DETAIL
  https://phabricator.kde.org/D27909

AFFECTED FILES
  autotests/aztec/encoding/aztec-complete-big.png
  autotests/aztec/encoding/aztec-complete-compact1.png
  autotests/aztec/encoding/aztec-complete-compact3.png
  autotests/aztec/encoding/aztec-complete-compact4.png
  autotests/aztec/encoding/aztec-complete-full5.png
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/aztecbarcode.h
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27730: Add API to check whether a barcode is one- or two-dimensional

2020-03-14 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R280:3d4b8780a8d5: Add API to check whether a barcode is one- 
or two-dimensional (authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27730?vs=77607=77609

REVISION DETAIL
  https://phabricator.kde.org/D27730

AFFECTED FILES
  CMakeLists.txt
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/CMakeLists.txt
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27730: Add API to check whether a barcode is one- or two-dimensional

2020-03-14 Thread Volker Krause
vkrause updated this revision to Diff 77607.
vkrause added a comment.


  Rebase and bump version number to 5.69.

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27730?vs=77128=77607

BRANCH
  arcpatch-D27730

REVISION DETAIL
  https://phabricator.kde.org/D27730

AFFECTED FILES
  CMakeLists.txt
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/CMakeLists.txt
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D28030: Also expose the true minimum size to QML

2020-03-13 Thread Volker Krause
vkrause created this revision.
vkrause added a reviewer: svuorela.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  Useful in case you want to implement manual scaling there, for example.

REPOSITORY
  R280 Prison

BRANCH
  pending

REVISION DETAIL
  https://phabricator.kde.org/D28030

AFFECTED FILES
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27989: Add a new set of barcode size functions

2020-03-11 Thread Volker Krause
vkrause created this revision.
vkrause added a reviewer: svuorela.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  preferredSize() is an improvement over what minimumSize() used to do,
  with taking the device pixel ratio into account. Additionally it also
  works correctly for 1D codes now (ie. those are now scannable on a
  standard DPI screen).
  
  trueMinimumSize() is what minimumSize() should have been, ie. the absolute
  minimum amount of pixels needed to display the code. This is mainly useful
  for applications doing their own layouting/scaling logic, beyond what
  preferredSize() offers.
  
  minimumSize() becomes deprecated by this, the deprecation macros will
  follow once the current users have been adjusted.

REPOSITORY
  R280 Prison

BRANCH
  pending

REVISION DETAIL
  https://phabricator.kde.org/D27989

AFFECTED FILES
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/quick/barcodequickitem.cpp

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27916: Add Overpass QL highlighting

2020-03-10 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R216:fdc762d23fdc: Add Overpass QL highlighting (authored by 
vkrause).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D27916?vs=77179=77372#toc

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27916?vs=77179=77372

REVISION DETAIL
  https://phabricator.kde.org/D27916

AFFECTED FILES
  autotests/folding/highlight.overpassql.fold
  autotests/html/highlight.overpassql.html
  autotests/input/highlight.overpassql
  autotests/reference/highlight.overpassql.ref
  data/syntax/overpassql.xml

To: vkrause, dhaumann
Cc: dhaumann, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, 
GB_2, domson, michaelh, ngraham, bruns, demsking, cullmann, sars


D27952: Simplify minimum size handling

2020-03-09 Thread Volker Krause
vkrause added a comment.


  The deprecation version is off by one, but that will be fixed when rebasing 
the entire patch set on 5.69 once 5.68 is released.

REPOSITORY
  R280 Prison

REVISION DETAIL
  https://phabricator.kde.org/D27952

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27952: Simplify minimum size handling

2020-03-09 Thread Volker Krause
vkrause created this revision.
vkrause added a reviewer: svuorela.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  We don't need to track the minimum size separately anymore, so avoid this
  getting out of sync by removing it.

REPOSITORY
  R280 Prison

BRANCH
  pending

REVISION DETAIL
  https://phabricator.kde.org/D27952

AFFECTED FILES
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27916: Add Overpass QL highlighting

2020-03-07 Thread Volker Krause
vkrause updated this revision to Diff 77179.
vkrause added a comment.


  Highlight the {{bbox}} Overpass Turbo placeholder.

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27916?vs=77177=77179

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27916

AFFECTED FILES
  autotests/folding/highlight.overpassql.fold
  autotests/html/highlight.overpassql.html
  autotests/input/highlight.overpassql
  autotests/reference/highlight.overpassql.ref
  data/syntax/overpassql.xml

To: vkrause
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann


D27916: Add Overpass QL highlighting

2020-03-07 Thread Volker Krause
vkrause created this revision.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
vkrause requested review of this revision.

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27916

AFFECTED FILES
  autotests/folding/highlight.overpassql.fold
  autotests/html/highlight.overpassql.html
  autotests/input/highlight.overpassql
  autotests/reference/highlight.overpassql.ref
  data/syntax/overpassql.xml

To: vkrause
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, GB_2, 
domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann


D27909: Move barcode image scaling logic to AbstractBarcode

2020-03-07 Thread Volker Krause
vkrause created this revision.
vkrause added a reviewer: svuorela.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This removes any kind of scaling from the specific implementations, they
  now truly report the bare minimum size needed, as well as a corresponding
  image. AbstractBarcode scales this to the requested size, and, for now,
  adds the previous magic numbers to the minimum size.
  
  This is a further step towards allowing applications full control over
  scaling for properly handling high DPI scenarios.
  
  There's two noteworthy behavior changes in this:
  
  - minimumSize() now also works before calling toImage() for the first time.
  - toImage() returns valid results down to the actual minimum size, not only
  
  to what minimumSize() reports.

REPOSITORY
  R280 Prison

BRANCH
  pending

REVISION DETAIL
  https://phabricator.kde.org/D27909

AFFECTED FILES
  autotests/aztec/encoding/aztec-complete-big.png
  autotests/aztec/encoding/aztec-complete-compact1.png
  autotests/aztec/encoding/aztec-complete-compact3.png
  autotests/aztec/encoding/aztec-complete-compact4.png
  autotests/aztec/encoding/aztec-complete-full5.png
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/aztecbarcode.h
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27730: Add API to check whether a barcode is one- or two-dimensional

2020-03-06 Thread Volker Krause
vkrause updated this revision to Diff 77128.
vkrause added a comment.


  Alternative implementation for the barcode dimension API.

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27730?vs=76661=77128

BRANCH
  pending

REVISION DETAIL
  https://phabricator.kde.org/D27730

AFFECTED FILES
  CMakeLists.txt
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/CMakeLists.txt
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/qrcodebarcode.cpp
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27727: Remove empty/unused private classes on internal types

2020-03-04 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R280:10054afd8243: Remove empty/unused private classes on 
internal types (authored by vkrause).

REPOSITORY
  R280 Prison

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27727?vs=76657=76965

REVISION DETAIL
  https://phabricator.kde.org/D27727

AFFECTED FILES
  src/lib/code39barcode.cpp
  src/lib/code39barcode.h
  src/lib/code93barcode.cpp
  src/lib/code93barcode.h
  src/lib/datamatrixbarcode.cpp
  src/lib/datamatrixbarcode.h
  src/lib/qrcodebarcode.cpp
  src/lib/qrcodebarcode.h

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27730: Add API to check whether a barcode is one- or two-dimensional

2020-03-04 Thread Volker Krause
vkrause added a reviewer: svuorela.

REPOSITORY
  R280 Prison

REVISION DETAIL
  https://phabricator.kde.org/D27730

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27727: Remove empty/unused private classes on internal types

2020-03-04 Thread Volker Krause
vkrause added a reviewer: svuorela.

REPOSITORY
  R280 Prison

REVISION DETAIL
  https://phabricator.kde.org/D27727

To: vkrause, svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D26749: Support NDK r20 and Qt 5.14

2020-03-03 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R240:c9ebd3917e59: Support NDK r20 and Qt 5.14 (authored by 
vkrause).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D26749?vs=73822=76876

REVISION DETAIL
  https://phabricator.kde.org/D26749

AFFECTED FILES
  toolchain/Android.cmake
  toolchain/ECMAndroidDeployQt.cmake
  toolchain/deployment-file-qt514.json.in

To: vkrause, apol
Cc: flherne, apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
GB_2, bencreasy, michaelh, ngraham, bruns


D26749: Support NDK r20 and Qt 5.14

2020-03-02 Thread Volker Krause
vkrause retitled this revision from "WIP: Support NDK r20 and Qt 5.14" to 
"Support NDK r20 and Qt 5.14".

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D26749

To: vkrause, apol
Cc: flherne, apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
GB_2, bencreasy, michaelh, ngraham, bruns


D26749: WIP: Support NDK r20 and Qt 5.14

2020-03-01 Thread Volker Krause
vkrause added a comment.


  In D26749#620142 , @apol wrote:
  
  > Seems ready to land to me.
  
  
  It does seem to break poppler in the old setup here, not sure yet why though. 
If we land the docker change as well that is probably acceptable though.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D26749

To: vkrause, apol
Cc: flherne, apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
GB_2, bencreasy, michaelh, ngraham, bruns


D27730: Add API to check whether a barcode is one- or two-dimensional

2020-02-28 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This matters for user code doing some more advanced layouting or size
  computations, especially once we remove the hardcoded minimum sizes
  in here for proper high dpi support.

REPOSITORY
  R280 Prison

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27730

AFFECTED FILES
  CMakeLists.txt
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/CMakeLists.txt
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  src/lib/aztecbarcode.cpp
  src/lib/code128barcode.cpp
  src/lib/code39barcode.cpp
  src/lib/code93barcode.cpp
  src/lib/datamatrixbarcode.cpp
  src/lib/prison.h
  src/lib/qrcodebarcode.cpp
  src/quick/barcodequickitem.cpp
  src/quick/barcodequickitem.h
  tests/barcode.qml

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27727: Remove empty/unused private classes on internal types

2020-02-28 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This avoids unnecessary allocations. This also un-exports QRCodeBarcode,
  which is declared in a non-installed header file.

REPOSITORY
  R280 Prison

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27727

AFFECTED FILES
  src/lib/code39barcode.cpp
  src/lib/code39barcode.h
  src/lib/code93barcode.cpp
  src/lib/code93barcode.h
  src/lib/datamatrixbarcode.cpp
  src/lib/datamatrixbarcode.h
  src/lib/qrcodebarcode.cpp
  src/lib/qrcodebarcode.h

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27607: Deprecate KDBusConnectionPool

2020-02-28 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R271:417607275368: Deprecate KDBusConnectionPool (authored by 
vkrause).

REPOSITORY
  R271 KDBusAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27607?vs=76316=76652

REVISION DETAIL
  https://phabricator.kde.org/D27607

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/kdbusconnectionpool.cpp
  src/kdbusconnectionpool.h
  src/kdeinitinterface.cpp

To: vkrause, davidedmundson
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns


D27607: Deprecate KDBusConnectionPool

2020-02-28 Thread Volker Krause
vkrause added a comment.


  ping?

REPOSITORY
  R271 KDBusAddons

REVISION DETAIL
  https://phabricator.kde.org/D27607

To: vkrause
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns


D26749: WIP: Support NDK r20 and Qt 5.14

2020-02-26 Thread Volker Krause
vkrause added inline comments.

INLINE COMMENTS

> apol wrote in Android.cmake:173
> I did some testing and for me it works for arm64 but not for arm32.

I actually didn't test 64bit ARM here, only armv7 and x86, both work. What does 
break for you there?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D26749

To: vkrause
Cc: flherne, apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, 
GB_2, bencreasy, michaelh, ngraham, bruns


D27596: Load QM files from assets: URLs on Android

2020-02-26 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R240:040504da64aa: Load QM files from assets: URLs on Android 
(authored by vkrause).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27596?vs=76212=76476

REVISION DETAIL
  https://phabricator.kde.org/D27596

AFFECTED FILES
  modules/ECMQmLoader.cpp.in

To: vkrause, apol
Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, GB_2, 
bencreasy, michaelh, ngraham, bruns


D27596: Load QM files from assets: URLs on Android

2020-02-24 Thread Volker Krause
vkrause added a comment.


  In D27596#616554 , @apol wrote:
  
  > Don't we need an if Qt 5.13 elseif Qt 5.14?
  >
  > In other Qt versions it won't be in the assets...
  
  
  Are you sure about this? I had tested this on my Qt 5.13 setup and the files 
are in the same place there. I can't prove it with the binary factory apk 
though, translations don't seem to be included there at all?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D27596

To: vkrause
Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, GB_2, 
bencreasy, michaelh, ngraham, bruns


D27607: Deprecate KDBusConnectionPool

2020-02-24 Thread Volker Krause
vkrause updated this revision to Diff 76316.
vkrause added a comment.


  Set EXCLUDE_DEPRECATED_BEFORE_AND_AT.

REPOSITORY
  R271 KDBusAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27607?vs=76241=76316

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27607

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/kdbusconnectionpool.cpp
  src/kdbusconnectionpool.h
  src/kdeinitinterface.cpp

To: vkrause
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns


D27594: Remove unused KDBusConnectionPool include

2020-02-24 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R241:faace55f0bea: Remove unused KDBusConnectionPool include 
(authored by vkrause).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27594?vs=76207=76315

REVISION DETAIL
  https://phabricator.kde.org/D27594

AFFECTED FILES
  src/core/kdirnotify.cpp

To: vkrause, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27607: Deprecate KDBusConnectionPool

2020-02-23 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  As per T12722  this is no longer needed, 
QDBusConnection now behaves
  correctly in a multi-threaded scenario.
  
  All uses found by lxr have either been ported already, or have patches
  in review.

REPOSITORY
  R271 KDBusAddons

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27607

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/kdbusconnectionpool.cpp
  src/kdbusconnectionpool.h
  src/kdeinitinterface.cpp

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27596: Load QM files from assets: URLs on Android

2020-02-23 Thread Volker Krause
vkrause added a task: T12520: Qt 5.14.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D27596

To: vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, GB_2, bencreasy, 
michaelh, ngraham, bruns


D27596: Load QM files from assets: URLs on Android

2020-02-23 Thread Volker Krause
vkrause created this revision.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  This works with both the old and the new way of Qt's asset deployment, ie.
  with Qt 5.13 and Qt 5.14.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27596

AFFECTED FILES
  modules/ECMQmLoader.cpp.in

To: vkrause
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, GB_2, bencreasy, 
michaelh, ngraham, bruns


D27594: Remove unused KDBusConnectionPool include

2020-02-23 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  KDBusConnectionPool is about to be deprecated.

REPOSITORY
  R241 KIO

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27594

AFFECTED FILES
  src/core/kdirnotify.cpp

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27550: Support Qt 5.14 on Android

2020-02-22 Thread Volker Krause
This revision was automatically updated to reflect the committed changes.
Closed by commit R249:91c5e2ff604e: Support Qt 5.14 on Android (authored by 
vkrause).

REPOSITORY
  R249 KI18n

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27550?vs=76160=76161

REVISION DETAIL
  https://phabricator.kde.org/D27550

AFFECTED FILES
  src/kcatalog.cpp

To: vkrause, apol
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns


D27550: Support Qt 5.14 on Android

2020-02-22 Thread Volker Krause
vkrause updated this revision to Diff 76160.
vkrause added a comment.


  Improve compile-time conditional to only build the new code with Qt >= 5.14.

REPOSITORY
  R249 KI18n

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D27550?vs=76117=76160

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27550

AFFECTED FILES
  src/kcatalog.cpp

To: vkrause, apol
Cc: apol, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, 
bruns


D27550: Support Qt 5.14 on Android

2020-02-21 Thread Volker Krause
vkrause added a task: T12520: Qt 5.14.

REPOSITORY
  R249 KI18n

REVISION DETAIL
  https://phabricator.kde.org/D27550

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27550: Support Qt 5.14 on Android

2020-02-21 Thread Volker Krause
vkrause created this revision.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
vkrause requested review of this revision.

REVISION SUMMARY
  With Qt 5.14 asset files are no longer extracted into the filesystem, they
  are only available via assert: or qrc: URLs. Those however aren't supported
  by libintl, so copy catalogs to the cache folder on demand.
  
  Not ideal (libintl using the assert manager NDK API directly would probably
  be more efficient), but it's still better than 5.13, as unused catalogs
  aren't copied.

REPOSITORY
  R249 KI18n

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D27550

AFFECTED FILES
  src/kcatalog.cpp

To: vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


Re: Banning QNetworkAccessManager

2020-02-20 Thread Volker Krause
On Wednesday, 19 February 2020 10:04:11 CET Ben Cooksley wrote:
> On Wed, Feb 19, 2020 at 9:30 PM Volker Krause  wrote:
> > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > > > I agree on the problem of QNAM's default, see also
> > > > https://conf.kde.org/en/
> > > > akademy2019/public/events/135 on that subject.
> > > > 
> > > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > > > [...]
> > > > 
> > > > > Prior to now, i've taken the approach of advertising that
> > > > > QNetworkAccessManager is broken and needs a flag set within
> > > > > applications when used, however unfortunately this seems to have
> > > > > been
> > > > > an ineffective approach and cases of broken behaviour continue to
> > > > > appear (despite this brokeness being known about and advertised
> > > > > since
> > > > > back in the Qt 4.x series when this class was introduced)
> > > > > 
> > > > > Therefore, given the Qt Project is unlikely to change their position
> > > > 
> > > > > on this, I would like to propose the following:
> > > > The Qt Project is actually in favor of changing at least the
> > > > redirection
> > > > default to exactly what we want it to be.
> > > > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change,
> > > > and
> > > > got approval both by Lars and one of the maintainers. It is merely
> > > > stuck
> > > > in dealing with the unit test fallout in Qt's CI that somebody has to
> > > > take care of. Doesn't immediately help us of course, but claiming Qt
> > > > is
> > > > unwilling to change this is simply wrong.
> > > > 
> > > > > 1) That effective immediately, QNetworkAccessManager and it's
> > > > > children
> > > > > classes be banned and prohibited within KDE software, to be enforced
> > > > > by server side hooks.
> > > > > 2) That we fork QNetworkAccessManager and the associated classes
> > > > > within the appropriate Framework (to be determined), where the
> > > > > defective behaviour can then be corrected.
> > > > 
> > > > While this might solve the redirection problem, it brings us yet
> > > > another
> > > > then unmaintained HTTP implementation next to the one in KIO, which is
> > > > a
> > > > far bigger problem long term. We need less of those, not more.
> > > > 
> > > > To address the problem of people not using the correct defaults, I did
> > > > propose a much less extreme approach in the above mentioned talk at
> > > > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM
> > > > in
> > > > a low-tier frameworks that essentially just enables redirects and
> > > > HSTS.
> > > > QNAM's implementation isn't the problem after all, the defaults are.
> > > > 
> > > > Commit hooks warning about QNAM usage might still be a good idea, but
> > > > as a
> > > > warning only. Hard blocking QNAM-using code would block at least three
> > > > repos I spend a lot of time on currently, none of which even talks to
> > > > KDE
> > > > servers.
> > > > 
> > > > If you need to take more drastic measures against code not doing this
> > > > correctly regardless, you can do that my dropping the server-side
> > > > workarounds. Yes, that would break the affected application possibly,
> > > > but
> > > > at least it would not cause massive collateral damage for the people
> > > > using this correctly.
> > > > 
> > > > It would also help to know where specifically we have that problem, so
> > > > we
> > > > can actually solve it, and so we can figure out why we failed to fix
> > > > this
> > > > there earlier.
> > > 
> > > Just bringing this up again - it seems we've not had much movement on
> > > this aside from the Wiki page.
> > > 
> > > Examining that Qt merge request, it not only is targeted at just Qt
> > > 6.x, it also hasn't had any movement since the start of October 2019 -
> > > 4 months ago.
> > > Given that we are going to be on Qt 5.x for some time, that merge
> > > requ

Re: Banning QNetworkAccessManager

2020-02-19 Thread Volker Krause
On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote:
> On Mon, Feb 3, 2020 at 7:42 AM Volker Krause  wrote:
> > I agree on the problem of QNAM's default, see also
> > https://conf.kde.org/en/
> > akademy2019/public/events/135 on that subject.
> > 
> > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
> > [...]
> > 
> > > Prior to now, i've taken the approach of advertising that
> > > QNetworkAccessManager is broken and needs a flag set within
> > > applications when used, however unfortunately this seems to have been
> > > an ineffective approach and cases of broken behaviour continue to
> > > appear (despite this brokeness being known about and advertised since
> > > back in the Qt 4.x series when this class was introduced)
> > > 
> > > Therefore, given the Qt Project is unlikely to change their position
> > 
> > > on this, I would like to propose the following:
> > The Qt Project is actually in favor of changing at least the redirection
> > default to exactly what we want it to be.
> > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and
> > got approval both by Lars and one of the maintainers. It is merely stuck
> > in dealing with the unit test fallout in Qt's CI that somebody has to
> > take care of. Doesn't immediately help us of course, but claiming Qt is
> > unwilling to change this is simply wrong.
> > 
> > > 1) That effective immediately, QNetworkAccessManager and it's children
> > > classes be banned and prohibited within KDE software, to be enforced
> > > by server side hooks.
> > > 2) That we fork QNetworkAccessManager and the associated classes
> > > within the appropriate Framework (to be determined), where the
> > > defective behaviour can then be corrected.
> > 
> > While this might solve the redirection problem, it brings us yet another
> > then unmaintained HTTP implementation next to the one in KIO, which is a
> > far bigger problem long term. We need less of those, not more.
> > 
> > To address the problem of people not using the correct defaults, I did
> > propose a much less extreme approach in the above mentioned talk at
> > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM in
> > a low-tier frameworks that essentially just enables redirects and HSTS.
> > QNAM's implementation isn't the problem after all, the defaults are.
> > 
> > Commit hooks warning about QNAM usage might still be a good idea, but as a
> > warning only. Hard blocking QNAM-using code would block at least three
> > repos I spend a lot of time on currently, none of which even talks to KDE
> > servers.
> > 
> > If you need to take more drastic measures against code not doing this
> > correctly regardless, you can do that my dropping the server-side
> > workarounds. Yes, that would break the affected application possibly, but
> > at least it would not cause massive collateral damage for the people
> > using this correctly.
> > 
> > It would also help to know where specifically we have that problem, so we
> > can actually solve it, and so we can figure out why we failed to fix this
> > there earlier.
> 
> Just bringing this up again - it seems we've not had much movement on
> this aside from the Wiki page.
> 
> Examining that Qt merge request, it not only is targeted at just Qt
> 6.x, it also hasn't had any movement since the start of October 2019 -
> 4 months ago.
> Given that we are going to be on Qt 5.x for some time, that merge
> request can't be considered to be the 'fix' for this issue.

The targeting of Qt6 is due to this aiming at dev when that was still Qt 5.x, 
but you are right of course, somebody needs to do the work there to drive this 
to completion, no matter in which version it will actually land.

> We need a solution that will ensure software released today doesn't
> cause us pain in several years time, because as I illustrated in an
> earlier email to this thread, software has a habit of remaining in use
> for an extremely long amount of time (August 2014 being the release
> date of the Marble versions in question hitting that old URL).
> 
> The easiest path forward is to simply ban QNetworkAccessManager.

That might be the easiest path for you, but certainly not for me, given two of 
the modules I work on most atm are using QNAM (not even to talk to KDE 
infrastructure), and would suddenly no longer be allowed to be hosted here?

Also, I have yet to see a suggestion for a viable alternative to QNAM. The 
initially proposed fork would mean trading the possibility of broken redirect 
handling for an unmain

Re: New Framework Review: KDAV

2020-02-16 Thread Volker Krause
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

2020-02-15 Thread Volker Krause
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.


D27239: [android] Emit defaultActivated when tapping the notification

2020-02-08 Thread Volker Krause
vkrause accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R289 KNotifications

BRANCH
  defa

REVISION DETAIL
  https://phabricator.kde.org/D27239

To: nicolasfella, #frameworks, vkrause
Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns


D27187: update travel-family icons

2020-02-07 Thread Volker Krause
vkrause added a comment.


  Awesome work indeed, thanks! I've integrated that in the app, now trying to 
find all remaining uses of the old one elsewhere.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D27187

To: mbruchert, #vdg, ndavis
Cc: vkrause, ngraham, nicolasfella, ndavis, kde-frameworks-devel, LeGast00n, 
cblack, GB_2, michaelh, bruns


D26749: WIP: Support NDK r20 and Qt 5.14

2020-02-05 Thread Volker Krause
vkrause added a comment.


  Excellent news! Could you post your Kirigami patch somewhere maybe? Makes 
this easier to test here :)
  
  For icons we probably need a similar adjustment, I bet they got affected by 
the same Qt change. Same for translations I think, in ki18n.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D26749

To: vkrause
Cc: flherne, apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, 
bencreasy, michaelh, ngraham, bruns


Re: Banning QNetworkAccessManager

2020-02-03 Thread Volker Krause
On Monday, 3 February 2020 10:49:10 CET David Edmundson wrote:
> I updated:
> 
> https://community.kde.org/Policies/API_to_Avoid
> 
> Which had no mention of this.

Thanks for taking care of this! 

I'd propose a slightly different approach than the per-request all-or-nothing 
attribute mentioned in the wiki though, using the redirection policy on QNAM, 
which prevents redirects to non-TLS connections:

nam->setRedirectPolicy(QNetworkRequest::NoLessSafeRedirectPolicy);

And while we are at it, let's also enable HSTS:

nam->setStrictTransportSecurityEnabled(true); 
nam->enableStrictTransportSecurityStore(true); 


Regards,
Volker

signature.asc
Description: This is a digitally signed message part.


Re: Banning QNetworkAccessManager

2020-02-02 Thread Volker Krause
I agree on the problem of QNAM's default, see also https://conf.kde.org/en/
akademy2019/public/events/135 on that subject.

On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote:
[...]
> Prior to now, i've taken the approach of advertising that
> QNetworkAccessManager is broken and needs a flag set within
> applications when used, however unfortunately this seems to have been
> an ineffective approach and cases of broken behaviour continue to
> appear (despite this brokeness being known about and advertised since
> back in the Qt 4.x series when this class was introduced)
> 
> Therefore, given the Qt Project is unlikely to change their position
> on this, I would like to propose the following:

The Qt Project is actually in favor of changing at least the redirection 
default to exactly what we want it to be.
https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, and got 
approval both by Lars and one of the maintainers. It is merely stuck in 
dealing with the unit test fallout in Qt's CI that somebody has to take care 
of. Doesn't immediately help us of course, but claiming Qt is unwilling to 
change this is simply wrong.

> 1) That effective immediately, QNetworkAccessManager and it's children
> classes be banned and prohibited within KDE software, to be enforced
> by server side hooks.
> 2) That we fork QNetworkAccessManager and the associated classes
> within the appropriate Framework (to be determined), where the
> defective behaviour can then be corrected.

While this might solve the redirection problem, it brings us yet another then 
unmaintained HTTP implementation next to the one in KIO, which is a far bigger 
problem long term. We need less of those, not more.

To address the problem of people not using the correct defaults, I did propose 
a much less extreme approach in the above mentioned talk at Akademy, namely 
having a KNetworkAccessManager as a sub-class of QNAM in a low-tier frameworks 
that essentially just enables redirects and HSTS. QNAM's implementation isn't 
the problem after all, the defaults are.

Commit hooks warning about QNAM usage might still be a good idea, but as a 
warning only. Hard blocking QNAM-using code would block at least three repos I 
spend a lot of time on currently, none of which even talks to KDE servers.

If you need to take more drastic measures against code not doing this 
correctly regardless, you can do that my dropping the server-side workarounds. 
Yes, that would break the affected application possibly, but at least it would 
not cause massive collateral damage for the people using this correctly.

It would also help to know where specifically we have that problem, so we can 
actually solve it, and so we can figure out why we failed to fix this there 
earlier.

Regards,
Volker


signature.asc
Description: This is a digitally signed message part.


D26749: WIP: Support NDK r20 and Qt 5.14

2020-01-20 Thread Volker Krause
vkrause added inline comments.

INLINE COMMENTS

> apol wrote in Android.cmake:173
> Why's this better? Or how is it different?

It's "better" in the way that it actually works with NDK r20, while CMake 3.16 
failed to even pass the basic compiler checks. For a toolchain file shipped 
with a toolchain making adjustments for toolchain changes is of course possible 
immediately, while with CMake we have to wait for the next release if such 
changes are necessary.

It's unfortunately different in various variable names as well in some details 
of what it sets or doesn't set. That's where most of the changes in this file 
come from.

The main reason we didn't use this right from the start, and probably also the 
reason the toolchain file in CMake exists is that the NDK didn't have CMake 
support in older versions.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D26749

To: vkrause
Cc: apol, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, bencreasy, 
michaelh, ngraham, bruns


D26723: KCONFIG_ADD_KCFG_FILES: regenerate also on new version of kconfig_compiler

2020-01-19 Thread Volker Krause
vkrause accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R237 KConfig

BRANCH
  dependonkconfigcompiler

REVISION DETAIL
  https://phabricator.kde.org/D26723

To: kossebau, #frameworks, vkrause
Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns


  1   2   3   4   5   6   7   8   9   10   >