D23842: [KCompletion] Port away from deprecated methods in Qt 5.14

2020-12-21 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> kcombobox.cpp:363
> +connect(d->klineEdit, ::completionBoxActivated,
> +this, QOverload QString&>::of(::textActivated));
> +#endif

Why the `QOverload::of()` with `::textActivated`? 
Accidental copy?
After all the purpose of the new signals is to get rid of the overloading, no?

REPOSITORY
  R284 KCompletion

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

To: dfaure, cfeck, dhaumann, aacid, vkrause
Cc: kossebau, broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


Re: KDE review for KWeatherCore

2020-12-21 Thread Friedrich W. H. Kossebau
Am Montag, 21. Dezember 2020, 15:45:22 CET schrieb Nicolas Fella:
> On 12/21/20 3:19 PM, Friedrich W. H. Kossebau wrote:
> > My idea/proposal there is that the library internally makes use of that
> > demon. So code which uses KWeatherCore does not need to know that
> > implementation-wise there is a demon (which might also need to be a
> > build-time option, think app bundles who do not like separate demon
> > processes).
> > So the demon would not use KWeatherCore, but be a(n optional) backend part
> > of it.
> 
> Please keep in mind that having such a daemon would be challenging to
> impossible to implement on Android and possibly other platforms as well.

That's what I tried to hint at with "(which might also need to be a build-time 
option, think app bundles who do not like separate demon processes)."

> Let's not overengineer the wheel without having to and focus on use
> cases relevant for our current apps and less on hypothetical use cases.

A demon is not overengineered for this purpose IMHO, and I had thought quite a 
bit how to overhaul the Plasma weather dataengine to make it sanely reusable 
as system-wide service, just never got to the editor to implement things.
But those who do the code decide and can apply their favourite architectures 
and whatever makes reaching a working product for them faster :)

Cheers
Friedrich




Re: KDE review for KWeatherCore

2020-12-21 Thread Friedrich W. H. Kossebau
Am Montag, 21. Dezember 2020, 07:16:09 CET schrieb hanyoung:
> 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
> > programs/processes all interested in weather forecast data could share the
> > data
> 
>   The end goal is a daemon indeed, but we want to build the daemon upon the
> library. This would give us flexibility in the future if we don't want a
> daemon. At least KWeather and other projects can still benefit from the
> code.

My idea/proposal there is that the library internally makes use of that demon. 
So code which uses KWeatherCore does not need to know that implementation-wise 
there is a demon (which might also need to be a build-time option, think app 
bundles who do not like separate demon processes).
So the demon would not use KWeatherCore, but be a(n optional) backend part of 
it.

To give you more ideas: I would also envision there could be proxy servers one 
day. Think of big organizations with lots of devices at same location due to 
lots of people in same buildings, so interested in the same local weather 
data, like schools, office-heavy companies, they could have a single proxy 
server and all clients would just use that proxy, saving the weather/
environment service provider some bandwidth, also adding some privacy layer 
onto the provider. If KWeatherCore would be prepared to handle that scenario 
in one way or the other, even better.

> > but we want to make sure we don't end up with two things.
>   I admit there are some overlapped functionalities. But KWeatherCore isn't
> designed as a weather data provider as Weather DataEngine. Instead, it's
> trying to be the building block of weather related applications.

Consider a DataEngine to be some kind of Plasma-specific type of library, as 
in, as shared logic module, just with a normalized API. This technology though 
failed to stay in developers' hearts, and these days is deprecated and instead 
all DataEngines are turned into plain C++ libraries with specific API.
The Plasma weather dataengine from plasma-workspace/dataengines/weather might 
have already been turned into a library similar to kweathercore, just that the 
last maintainer (me) was attracted by other even more interesting stuff and 
no-one had picked up so far. See also https://phabricator.kde.org/T13349

Looking at the current API of KWeatherCore, e.g. 
KWeatherCore::WeatherForecastSource, I think the Plasma Weather DataEngine and 
KWeatherCore are very much overlapping, other than the one being a Plasma 
"library" and the other a normal C++ library.
With KWeatherCore now thankfully being created by yours, the weather data 
related features of the weather dataengine would be ideally merged into 
KWeatherCore, so that the weather dataengine itself can then be deprecated and 
all existing weather DataEngine consumers (like kdeplasma-addons/applets/
weather or some on https://store.kde.org/browse/cat/424) could be ported to 
something based on KWeatherCore (I guess there would be some kind of KWeather 
qml plugin then for these, next to the KWeatherCore library itself).

You will find the normalized data model used by the DataEngine here in the 
class documentation, which then would ideally be merged into the normalized 
data model of KWeatherCore, so the existing applets would not need that much 
porting but get data close to what they are using now:
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/dataengines/
weather/ions/ion.h
(that normalized data model BTW lacks support for sub-day-granularity for 
forecasts (like day & night as available with the Canadian service, resulting 
in bad hack and resulting display in the Plasma applets when using that 
service), so with room for improvements itself)

The weather dataengine also has a plugin mechanism (using DataEngines again 
for some perhaps random reason, just ignore that) to allow adding support for 
further weather data provider services by 3rd-party. Such an extension feature 
would be also nice to have with KWeatherCore. Some more info also here:
https://frinring.wordpress.com/2016/04/02/plasma-weather-widget-code-template-available-to-add-your-favorite-weather-data-provider/

Then as Volker already pointed out in good detail, using non-KDE service 
providers on the internet comes with lots of traps, related to privacy and 
terms of usage 

Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore

2020-12-20 Thread Friedrich W. H. Kossebau
(Added Han Young as BCC: based on code email address, as the task is not 
public, and not sure you are subscribed to the mailinglists)

Am Sonntag, 20. Dezember 2020, 12:05:46 CET schrieb David Edmundson:
> Please see https://community.kde.org/Policies/Application_Lifecycle about
> the process of adding things to frameworks.
> 
> As for plasma, we have a weather library there, so the comment about it
> being easier for new plasmoids doesn't hold directly. Maybe you can expand
> on what's different?

David, any chance you misremembered there being a weather library? If you 
refer to the stuff in plasma-workspace (which then e.g. drives the kde-
plasmaaddons weather applet), that is just a DataEngine.

As former contributor to the Weather DataEngine in plasma-workspace, and with 
the DataEngine concept being deprecated, also having seen at least the code 
copy used in a Marble plugin for overlaying weather reports on the map, having 
a library instead makes a lot sense. I would have written that myself, just 
had other things more attractive eating any resources :)
I guess Itinerary, KOrganizer and other date/location centric applications 
might also fancy access to weather forecast info optionally (Itinerary does 
already with custom code, no?)

But I would also recommend first going to "Extragear" (i.e. stand-alone 
releases) before entering KDE Framewprks, as that means not having to stick to 
the initial ABI/API from the first release on. Being a new library it's API is 
candidate for seeing some evolvement based on feedback by API consumers, and 
not having to bend over to keep compatibility to the initial API can make life 
easier. It might not be needed, but the option to be agile here allows for a 
better product.

BTW, I would also propose to consider doing a demon instead, so different 
programs/processes all interested in weather forecast data could share the 
data, would be also more nice to the weather data providing services to have a 
single process do optimized calls & caching of the data.

Cheers
Friedrich




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

2020-12-17 Thread Friedrich W. H. Kossebau
Am Freitag, 18. Dezember 2020, 00:31:45 CET schrieb Albert Astals Cid:
> El dijous, 17 de desembre de 2020, a les 21:16:57 CET, Ahmad Samir va 
escriure:
> > On 17/12/2020 22:06, David Faure wrote:
> > [...]
> > 
> > > Right. That's a reason to fix something indeed, but there are still two
> > > ways to fix that, if it was the only reason : either raise min req to
> > > Qt 5.14, or ask for a Qt 5.13 CI.
> > 
> > Ben said on IRC:
> > "I used 5.14 as a practical matter as 5.13 is essentially unavailable"
> 
> I'm fine going to 5.14, but saying that 5.13 is unavailable is just not the
> truth.

Guess it is a matter of defining "available" :)
AFAIK Qt 5.13 was not available just by the change of a data point in a table. 
It would have needed people investing their resources into scratching that 
itch to create respective custom packages for at least some of the CI-
supported operating systems. As well as potentially any other 3rd-party 
libraries/tools using Qt API that was built/packaged against newer Qt.

Cheers
Friedrich




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

2020-12-17 Thread Friedrich W. H. Kossebau
Am Donnerstag, 17. Dezember 2020, 21:06:23 CET schrieb David Faure:
> In general I might have asked for a more conservative approach; but
> currently anything we do to help with preparing the Qt 6 migration is a
> good thing, and having one less Qt version to support helps with that.
> 
> So, in those exceptional circumstances, I'm in favour, go for it.

Okay :) And it are those exceptional circumstances also which made me push for 
the bump here, otherwise I would have rather tried to have us get Qt 5.13 back 
onto KDE CI.

Albert, commit data tells me did the last bump. Could you go and do the bump 
to Qt 5.14 as well now, given you seem to have some setup for that?

I already adapted the respective policy like this now, based on the discussion 
(please fix any issues directly on the page, linked below):
"
With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 
versions would be released:
* 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 at the time, the date 
was moved to earlier mid-December 2020 (see discussion)
* Qt 5.15 LTS will be the minimum required version 18 months after its 
release, i.e. on 26 Nov 2021

The bumping of the minimum required version in the code is done at the begin 
of the release cycle of the next KF version affected, right after the release 
of the previous one.
"
* https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements 

Going to Qt 5.14 also means a bump in supported compilers, see
https://doc.qt.io/archives/qt-5.13/supported-platforms.html
vs.
https://doc.qt.io/qt-5.14/supported-platforms.html

So at least GCC 4.8 -> GCC 5, MSVC 2015 as before.
Can anyone tell what the supported clang version of Qt 5.14 is? 


Volker, leaving the stage now for you and the considerations to update the 
plan for when Qt 5.15 should become the minimum dependency :)

Cheers
Friedrich




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

2020-12-16 Thread Friedrich W. H. Kossebau
Hi,

Am Samstag, 12. Dezember 2020, 22:25:32 CET schrieb David Faure:
> Just a data point on this discussion. Every time we raise the min Qt
> version, we make life easier for KDE developers, and harder for others who
> might be thinking of integrating a framework into their project.
> 
> Just today I tried using a KF5 library to extend a single plugin in an
> existing webserver (which I don't control, and which is mostly written in
> python) [1]. That server is entirely set up with a docker environment on top
> of... debian buster, which has Qt 5.11.3.
> Fail.
> I'm going to have to apply a patch to the KF5 library as part of the
> Dockerfile, to port it back to Qt 5.11. No way I can convince them to change
> the base distribution, all I'll get as a reply is to port away from QtCore.
> 
> Obviously the 5.11 ship has sailed by now, and I know we can't support old
> versions forever, but this kind of experience makes me very wary of raising
> requirements too fast.

I am reading an objection to the proposed bump in these words, am I correct in 
doing that? Given you being KF release worker/manager and all your merits with 
KF, and also given no-one else so far has commented on this. I would accept 
that then and drop my request to adapt the current Qt compatibility road map.

I tested the waters at least.

Though please those who want to support Qt 5.13 for some more time, consider 
adding support for KDE CI then. It leaves a bad feeling in my stomach that KF 
5.77+ seems effectively for Qt 5.13 with a sticker "Good Luck!" right now. I 
fear that lowers the image with (potential) KF consumers, it does at least 
with me for other projects.
I (and possibly many other KF contributors) have no way to test against Qt 
5.13, so might introduce regressions/break things in the future, which feels 
bad :/

Cheers
Friedrich




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

2020-12-12 Thread Friedrich W. H. Kossebau
Am Samstag, 12. Dezember 2020, 22:25:32 CET schrieb David Faure:
> Just a data point on this discussion. Every time we raise the min Qt
> version, we make life easier for KDE developers, and harder for others who
> might be thinking of integrating a framework into their project.
> 
> Just today I tried using a KF5 library to extend a single plugin in an
> existing webserver (which I don't control, and which is mostly written in
> python) [1]. That server is entirely set up with a docker environment on top
> of... debian buster, which has Qt 5.11.3.
> Fail.
> I'm going to have to apply a patch to the KF5 library as part of the
> Dockerfile, to port it back to Qt 5.11. No way I can convince them to change
> the base distribution, all I'll get as a reply is to port away from QtCore.

The other option is to use not just the latest KF version, but some older one 
which gets along with what is available. Like KF 5.65, which seems the last 
one that had Qt 5.11 as min dep. Or simply the KF which is available for 
Buster (which seem 5.54?).

If that project is fine using old (now unmaintained by upstream) versions of 
other software, it should also be fine with using old versions of KF IMHO. Or 
did you need to use some feature only available in latest KF, with no option 
to work around and do some substitute? 

I am not sure that trying to be better than the rest of the stack pays back, 
Even more given the limited human resources we have. Just see how slowly the 
KF6 board moves forward.

So I think the very data point presented here is an exotic one. And rather 
recommends to do some bugfix-only branches at points in time when minimum 
dependency is raised, along versions which bigger LTS distributions rely on 
and trying to get downstream to help with maintaining those branches.

Cheers
Friedrich




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

2020-12-08 Thread Friedrich W. H. Kossebau
No time left to cut the reply short right now, please bear with me...

Am Montag, 7. Dezember 2020, 16:34:16 CET schrieb 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?

Revisiting the date of going to Qt 5.15 as min. dependency now and then to 
align to the real world makes sense to me.
Ideally in a separate thread though, please :)
As IMHO the decisions are related, but would not depend on each other (other 
than 5.14 < 5.15).

That discussion might also want to consider how much we are able to set the 
date and have distributions follow us, or how much we need to adjust to the 
world they create and in which the KF contributors and consumers live.

BTW, IMHO we should also bump the min version at the begin of the KF 
development cycle, for the usual reasons, not just on the very dates, which 
have been close to tagging/branching in the KF schedules. We would rather use 
those dates as needles, and then bump at the begin of the cycle for the first 
version released after the needle. (at least I expect KF contributors to not 
also only after that date being able to use the newer minimum Qt version). 
(the current Qt 5.14 proposal's date December 14th is derived from the timeout 
of the RFC, otherwise I would have proposed the bump execution to happen 
around version bump time, i.e. once the previous release happened).

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

Also no idea. My hope would be that in the assumed non-Qt-company patch 
collection the FLOSS world will create for Qt 5.15 (given there will be no 
further official Qt 5.15 releases, or where are we now?) someone also manages 
to do a fix for the QMdi on Windows regressions that popped up in Qt 5.13 (if 
I got the issue correctly). So Krita could use Qt 5.15 FLOSS fork with Windows 
and passed that hurdle. So far my bet on others resolving the issue outside KF 
spheres.
>From KF side we already screwed Krita with KF 5.77 now here. Going back to Qt 
5.12 as minimum dep for future KF versions... as much as I cheer Krita for the 
incredible awesome project it is, that would be a big price to pay by everyone 
else. Given Krita had forked some non-tier1 KF modules (for reasons I 
understand, and their product success confirms the decision) it also makes it 
harder for me to argue to have everyone sacrifice in the KF modules just for 
them by sticking to Qt 5.12 as min dep.
For now Krita is stuck with KF 5.76 as minimum KF version then for the Windows 
builds, and would need to backport patches for any important bug fixes. Given 
that current master has MIN_QT_VERSION 5.9.0 and MIN_FRAMEWORKS_VERSION 
5.44.0, building with not the latest KF modules on Windows might not be such a 
bummer, and perhaps those limits are not raised near KF 5.77 a lot until Krita 
considers Qt6 anyway?
(And did Wolthera explore the feasibility of Godot as UI toolkit as another 
approach to the problem? ;) )
But that is my uninformed view from the outside, Boud & fellows have to fill 
in here with their future plans and needs/desires/ideas.

Cheers
Friedrich




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

2020-12-07 Thread Friedrich W. H. Kossebau
Hi Rafael,

thanks for your quick reply.

Am Montag, 7. Dezember 2020, 06:48:44 CET schrieb Rafael Sadowski:
> On Sun Dec 06, 2020 at 08:32:36PM +0100, Adriaan de Groot wrote:
> > On Sunday, 6 December 2020 18:05:19 CET David Faure wrote:
> > > On dimanche 6 décembre 2020 17:39:38 CET Albert Astals Cid wrote:
> > > >  * MidnightBSD
> > > >  * openBSD
> > > > 
> > > > The BSDs are a bit more unfortunate.
> > > 
> > > Thanks for the information, Albert.
> > > 
> > > Apparently this means bumping the requirement to Qt 5.14 would break
> > > OpenBSD.
> 
> Will this Qt bump happen before or after the 5.77 release?

After, the bump to Qt 5.14 is currently proposed to happen Mid-December, so 
would be seen for release consumers first with released KF 5.78 in January 
2021.

For KF 5.77 another bump has just happened to Qt 5.13 (was Qt 5.12 before) as 
per dependency plan updated earlier this year*. Which then triggered this 
discussion whether with what we now see being used around us we should perhaps 
simplify our life (as e.g. there are lots of "#if Qt < 5.14 #else #endif" in 
the code) and go already to Qt 5.14 now.

*https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements

> Anyway, this is okay for OpenBSD. I'm working on a Qt
> 5.15.1 update (qt5-webengine makes me insane).

Very good (and all the best to recover once done ;) )

BTW, please consider subscribing to our special-purpose mailinglist:
https://mail.kde.org/mailman/listinfo/distributions
where such things are discussed with the big consumers of what is released by 
KDE. It is a low volume mailinglist, so should not be a big price to pay for 
being in good loop with upstream as well as your related packaging fellows.

FTR, the email asking about this topic there is
https://mail.kde.org/pipermail/distributions/2020-December/000894.html

Cheers
Friedrich




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

2020-12-06 Thread Friedrich W. H. Kossebau
Hi,

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
"

from previous

"
With Qt6 this changes a little bit again. We interpolate "as if" more Qt 5 
versions would be released: 
* Qt 5.13 will be the minimum required version 6 months after Qt 5.15, i.e. on 
26 Nov 2020
* Qt 5.14 will be the minimum required version 12 months after Qt 5.15, i.e. 
on 26 May 2021
* Qt 5.15 LTS will be the minimum required version 18 months after its 
release, i.e. on 26 Nov 2021
"

I also propose that if no objections pop up until Monday, December 14th, CET 
Noon, we then go that day and update the policy and have our dependency 
bumping service people execute the bump to Qt 5.14.

Your comments, please :)

Cheers
Friedrich




Re: Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?

2020-12-04 Thread Friedrich W. H. Kossebau
Hi,

thanks everyone for your replies so far, shaping the picture of where we are.

Am Dienstag, 1. Dezember 2020, 13:13:53 CET schrieb Friedrich W. H. Kossebau:
> last week KDE Frameworks master saw a bump in the required/expected minimal
> Qt version to Qt 5.13, following rules once agreed and noted here:
> https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements
> 
> I would like to challenge that former decision though and propose to instead
> go straight to Qt 5.14 as minimum requirement now.
> 
> 
> QUESTION:
> Would any of the distributions have an issue with requiring Qt 5.14 instead
> of Qt 5.13?

So far no-one of those who replied in the last three days would have issues*. 
Sounds promising.

Just, KF 5.77 is going to be tagged this upcoming WE. And meanwhile it would 
feel too rushed to me to push for a bump to Qt 5.14 as minimum version already 
now, I would feel better if people had something like 2 weeks time to comment 
on this (think being on vacation or only having 1 day per week for KDE).

So I will adapt and officially go to propose to do that bump in time for KF 
5.78 then. 

* The only project which has issues with Qt 5.14 is also having issues with Qt 
5.13 (Krita sees breakage with QMdi on Windows for Qt > 5.12)

Cheers
Friedrich




Would distributions have an issue if KF 5.77+ would require Qt >= 5.14 (instead of >= 5.13 as of now)?

2020-12-01 Thread Friedrich W. H. Kossebau
Hi,

last week KDE Frameworks master saw a bump in the required/expected minimal Qt 
version to Qt 5.13, following rules once agreed and noted here:
https://community.kde.org/Frameworks/Policies#Frameworks_Qt_requirements

I would like to challenge that former decision though and propose to instead 
go straight to Qt 5.14 as minimum requirement now.


QUESTION:
Would any of the distributions have an issue with requiring Qt 5.14 instead of 
Qt 5.13?


>From some quick checks using https://repology.org/ it seems that any 
distribution versions which currently use Qt 5.13 have also settled on some 
older KF version, so will not update to just KF 5.77 and thus be screwed.

Motivation:
* KDE CI not setup ATM to cover builds with Qt 5.13 (no build, no unit tests)
* Qt 5.14 added some new API, chance to miss out when using that in new code
* C++: no need to write #if QT_VERSION < QT_VERSION_CHECK(5, 14, 0) variants
* QML: no need to do hard-to-read generation tricks to support < Qt 5.14
* Qt 5.13 went out-of-support in June
* App bundle builders would rather use some recent Qt 5.14/5.15

So by restraining to Qt 5.13 as minimum version IMHO we would make/keep life 
complicated for KF contributors without adding any value for anyone.

With most of KDE Frameworks in my local checkout:
grep "QT_VERSION_CHECK(5, 14, 0)"  frameworks/*/src -r 2>/dev/null | \
grep "QT_VERSION " | wc -l
gives me "92", so there are quite some code variants which need support in 
current code.

>From the emails at least in 
>https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html I 
>could not see a discussion whether Qt 5.13 makes 
sense at all now, seems mainly the algorithm was applied. I propose to match 
the result to known real world needs now. Or teach me what I have missed here 
:)

Cheers
Friedrich




Would a min dep Qt 5.14 be more real-worldish? (Re: PSA: Frameworks depends on Qt 5.13 now)

2020-11-27 Thread Friedrich W. H. Kossebau
Am Freitag, 27. November 2020, 00:21:04 CET schrieb Nicolas Fella:
> Hi,
> 
> per our Qt dependency policy [0] Frameworks depends on Qt 5.13 6 months
> after the release of Qt 5.15, which is now.

Clueless question: why jump to Qt 5.13 and not Qt 5.14?

>From the discussion at least in 
>https://mail.kde.org/pipermail/kde-frameworks-devel/2020-July/112712.html I 
>could not see a discussion whether Qt 5.13 makes 
sense at all now, seems just the algorithm was applied. 

Do we have some overview which realistic distribution targets would require us 
to still support Qt 5.13 now? Or would it make more sense to jump to 5.14 as 
min dep straight?

Motivation to ask is that KDE CI right now does not yet cover Qt 5.13, but 
only Qt 5.14 & Qt 5.15.
So by "Martin's Law": no CI coverage -> feature (of min dependency) not 
existing.

Cheers
Friedrich




D26890: QXmlInputSource is deprecated in qt5.15. Port it to QXmlStreamReader

2020-11-02 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> kconfigloader.cpp:87
> +
> +if (reader.isEndDocument())
> +return false;

This logic is inverted., no? We should be at token document end when 
reader.atEnd() turns true. In any case on successful parse this condition is 
met here and false returned.

No caller seems to check the return value of ConfigLoaderHandler::parse(), thus 
nobody noticed?

REPOSITORY
  R237 KConfig

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

To: mlaurent, dfaure, apol
Cc: kossebau, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D19338: New location for KNSRC files

2020-10-30 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D19338#676680 , @asturmlechner 
wrote:
  
  > Hm, why was this new variable KDE_INSTALL_KNSRCDIR not put into 
KDEInstallDirs?
  
  
  On the other hand it makes sense that module-specific variables are provided 
by the CMake config file of the respective module. Which allows projects to use 
the module without having to use KDEInstallDirs, but e.g. GnuInstallDirs.

REPOSITORY
  R304 KNewStuff

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

To: leinir, #knewstuff, apol, ngraham, fvogt
Cc: asturmlechner, kossebau, kde-frameworks-devel, #knewstuff, LeGast00n, 
cblack, michaelh, ZrenBot, ngraham, bruns


D29281: Deprecate defunct functions

2020-07-14 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D29281#675955 , @davidre wrote:
  
  > This caused https://bugs.kde.org/show_bug.cgi?id=423003. I removed 
excluding the virtual method from the build in 
  >  
https://invent.kde.org/frameworks/krunner/commit/8f7ce559b84ee0c21de0256e6591793e4b95f411
  
  
  Gah, my bad for not catching this in the review. virtual methods need to be 
wrapped by the BUILD variant in the header.  See also 
https://api.kde.org/ecm/module/ECMGenerateExportHeader.html?highlight=virtual

REPOSITORY
  R308 KRunner

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

To: alex, #plasma, broulik, davidedmundson, vkrause, meven
Cc: davidre, kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


PSA: Qt logging category names of all KF modules have changed for KF >= 5.73 (current master)

2020-07-13 Thread Friedrich W. H. Kossebau
Hi,

as of this morning, latest master branch of all KDE Frameworks modules has 
seen a change of all the Qt logging category names they define, to now follow 
standardized patterns. Those are described over at
   https://community.kde.org/Frameworks/Frameworks_Logging_Policy

So everyone running KF daily master or later picking up the KF 5.73 release  
will notice the new category names in the log (and the need to update any 
local rules).

Please also make sure that any currently prepared patches for KF modules are 
adapted to the new patterns where needed and new ones using them from the 
start.

Motivation:
So far category names in KF modules were not following a consistent pattern, 
instead it was names like
* org.kde.attica
* org.kde.pim.kcalcore
* kf5.kconfig.core
* kf5.kconfigwidgets
* sonnet.core
* sonnet.plugins.aspell
* kf5.kemoticons.plugin_adium

As a result one could not "calculate" the name which would be used for a given 
library (or feature), but had to first look that up (or rely on 
kdebugsettings & maintained .categories file). Also was it not possible to 
rule all of KF in one go. And the log output with all the different prefixes/
namespaces made it harder to scan.

The polilcy now asks to use these patterns for the category names:

"kf".[.][.]
"kf"...[.]
"kf"..[.]
"kf"..[.]

So the examples from above become:
* kf.attica
* kf.calendarcore
* kf.config.core
* kf.configwidgets
* kf.sonnet.core
* kf.sonnet.clients.aspell
* kf.emoticons.adium

See for a more detailed description and reasoning the task
https://phabricator.kde.org/T12716

Sorry for any inconvenience this change might bring for you right now by 
having to tune your local logging settings to the new names, but in the long 
run you hopefully also gain from the consistent patterns.

Cheers
Friedrich

PS: I am still not satisfied with the current state, would also like that 
there is a central place in each repo to find any category names in use as 
well have them listed in the generated API documentation to ease 3rd-party 
use. I had some draft work, but not happy yet with my approaches, so put aside 
for a bit, will myself only look at later this year again. See for problem 
discussion https://phabricator.kde.org/T12741 (ignore solution part).




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

2020-06-22 Thread Friedrich W. H. Kossebau
kossebau closed this revision.

REPOSITORY
  R280 Prison

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

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


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

2020-06-22 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Okay :) Hm, need to update 71 to 72 though first, doing now.

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


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

2020-06-22 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Ping... :)

REPOSITORY
  R280 Prison

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

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


Moving ring-kde to unmaintained (was: Re: Shift for parts of the CI system to Qt 5.15)

2020-06-20 Thread Friedrich W. H. Kossebau
Am Samstag, 20. Juni 2020, 12:25:42 CEST schrieb Ben Cooksley:
> On Sat, Jun 20, 2020 at 8:13 PM Volker Krause  wrote:
> > On Saturday, 20 June 2020 08:20:18 CEST Ben Cooksley wrote:
> > > - ring-kde
> > 
> > build errors seem to be in stuff downloaded by cmake!?
> 
> Indeed, this seems to be a bit concerning.
> 
> I'm wondering if we should discontinue the CI support for this project?

Seems ring-kde is unmaintained, it has not seen any development since March 
2019, also missed to follow the renaming of GNU Ring to Jami on 18 December 
2018 (by what wikipedia tells).

So +1 for tagging the repo as unmaintained, and thus also removing from CI.

Cheers
Friedrich




D27396: support icon.width/height

2020-06-19 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> kossebau wrote in TabButton.qml:61
> @mart Why did you remove the color here? Seems unrelated to size?
> This broke things e.g. with  Breeze Dark (as can be seen e.g. with the 
> weather widget's tab buttons (use BBC service to have tabs).

Created a merge request to restore this, as I could not find a reason:
https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/15

REPOSITORY
  R242 Plasma Framework (Library)

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

To: mart, #plasma, broulik
Cc: kossebau, broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D27396: support icon.width/height

2020-06-19 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> TabButton.qml:61
>  opacity: enabled || control.highlighted || control.checked ? 1 : 
> 0.4
> -color: control.activeFocus && !control.down ? 
> theme.highlightedTextColor : theme.buttonTextColor
>  horizontalAlignment: Text.AlignHCenter

@mart Why did you remove the color here? Seems unrelated to size?
This broke things e.g. with  Breeze Dark (as can be seen e.g. with the weather 
widget's tab buttons (use BBC service to have tabs).

REPOSITORY
  R242 Plasma Framework (Library)

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

To: mart, #plasma, broulik
Cc: kossebau, broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


Re: New Framework Review: KDAV

2020-06-18 Thread Friedrich W. H. Kossebau
Am Freitag, 19. Juni 2020, 01:16:20 CEST schrieb Friedrich W. H. Kossebau:
> Will commit the ECMAddQch stuff once https://invent.kde.org/pim/kdav/-/
> merge_requests/1 is in, to not block this more due to resulting new merge
> conflicts.

And while I was typing & sending, that got merged at the same time it seems. 
So landing now as well...

Cheers
Friedrich






Re: New Framework Review: KDAV

2020-06-18 Thread Friedrich W. H. Kossebau
Am Samstag, 4. April 2020, 16:20:21 CEST schrieb Kevin Ottens:
> Overall apidox would likely need a big pass of cleanups as well.

I locally prepared the addition of ECMAddQch usage for KDAV tonight, and while 
testing the output already did some small bits of minor cleanup (consistent 
casing of terms like URL, ETag, etc. in the texts), documenting CamelCase 
includes of classes as well triggering the documentation of namespace KDAV.

One thing which should get fixed by someone with insights are all the 
remaining references to some "ResourceBase::retrieveItems()" in the docs 
(simply grep for the string to find those). That needs more context, or better 
some generalization what is meant there (seems something-Akonadi specific?).

Will commit the ECMAddQch stuff once https://invent.kde.org/pim/kdav/-/
merge_requests/1 is in, to not block this more due to resulting new merge 
conflicts.

Cheers
Friedrich




D29397: KPreviewJob : Support for DeviceRatioPixel

2020-06-01 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Thanks for starting the discussion about the spec, by what I saw on the 
mailinglist. Hopefully that soon gets traction by others.
  
  To not have that block this improvement, you could in parallel for now use a 
"kde" namespaced directories, say "*@kde2x/", where we/you could just use the 
for-now-KF-only theme extension. And once there is an agreed specification 
extension, the code could be switched to just any non-namespace shared hidpi 
folder matching whatever the specification ended up to be.

REPOSITORY
  R241 KIO

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

To: meven, dfaure, broulik, #frameworks, ngraham
Cc: elvisangelaccio, kossebau, davidedmundson, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


D29051: Add ecm_generate_dbus_service_file

2020-05-29 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  A unit test would be good to have. The test for ECMGeneratePkgConfigFile 
might be a sample for this.

INLINE COMMENTS

> ECMGenerateDBusServiceFile.cmake:17
> +#
> +# A D-Bus service file ``.service` will will be generated and 
> installed
> +# in the relevant D-Bus config location.

Computer says: 
.../extra-cmake-modules/modules/ECMGenerateDBusServiceFile.cmake:17: WARNING: 
Inline literal start-string without end-string.

> ECMGenerateDBusServiceFile.cmake:20
> +#
> +#  must be an absolute path to the service executable. When 
> using it with
> +# ``KDEInstallDirs` it needs to be the ``_FULL_`` variant.

I would propopse "to the installed service executable.", to avoid the 
misunderstanding this is about the copy in the build system.

> ECMGenerateDBusServiceFile.cmake:21
> +#  must be an absolute path to the service executable. When 
> using it with
> +# ``KDEInstallDirs` it needs to be the ``_FULL_`` variant.
> +#

Same issue: KDEInstallDirs misses double single quotes after it.

> ECMGenerateDBusServiceFile.cmake:23
> +#
> +# On Windows, only the file name of  is used since D-Bus 
> service executables
> +# are to be installed in the same directory as the D-Bus daemon.

Perhaps phrase it like: "Note: On Windows, the macro will only use the file 
name part of  since D-Bus service executables are to be installed 
in the same directory as the D-Bus daemon."
Current text still leaves chance to misunderstand that the user in "is used" is 
the macro caller, not the macro itself :)

REPOSITORY
  R240 Extra CMake Modules

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

To: broulik, #frameworks, davidedmundson, kossebau, kfunk, habacker
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29003: Use Q_EMIT and build with QT_NO_KEYWORDS

2020-05-25 Thread Friedrich W. H. Kossebau
kossebau closed this revision.

REPOSITORY
  R275 KItemModels

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

To: junghans, kossebau, dfaure, apol
Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29003: Use Q_EMIT and build with QT_NO_KEYWORDS

2020-05-25 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Looking at D28915 , seems you are only 
collecting to earn push rights so far :), so going to push for you with the 
author info taken from there.

REPOSITORY
  R275 KItemModels

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

To: junghans, kossebau, dfaure, apol
Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29397: KPreviewJob : Support for DeviceRatioPixel

2020-05-25 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D29397#673830 , @ngraham wrote:
  
  > The approach makes sense then. I agree that making high DPI a part of the 
FDO spec would be nice, but IMO that shouldn't block this. The approach 
currently taken is logical and it could be submitted as an extension to the 
spec later.
  
  
  It might be seen logical to us from our current POV, but better to do as 
desktop developer generations have done before and try to get others on board 
from the start, once there is a first plan. Would we want others do just extend 
specs on their own and start to write stuff without namespacing onto common 
data grounds? I suspect: no :) So we better behave as well as we would like 
others to do.

REPOSITORY
  R241 KIO

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

To: meven, dfaure, broulik, #frameworks, ngraham
Cc: elvisangelaccio, kossebau, davidedmundson, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


D29397: KPreviewJob : Support for DeviceRatioPixel

2020-05-25 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  @meven Have you already got in contact with the other users/maintainers of he 
thumnbail cache spec about the idea to extend it with support for high dpi? If 
not, please consider to do so, so things will also work cross-toolkit/platforms 
in the future there, by being based on an agreed & formalized specification. 
Not being involved here or having full understanding of the topic, but I would 
guess your approach with the separate x2 should run into "make sense" 
responses, so the additional effort might be low for the gain of being based on 
an official spec.
  
  This would be discussed on 
https://lists.freedesktop.org/mailman/listinfo/xdg, possible best by cc:ing 
other potential parties interested in highdpi thumbnails, would need to be 
researched, possibly some Dolphin contributors know their counterparts in 
non-KDE FLOSS projects

REPOSITORY
  R241 KIO

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

To: meven, dfaure, broulik, #frameworks, ngraham
Cc: elvisangelaccio, kossebau, davidedmundson, kde-frameworks-devel, LeGast00n, 
cblack, michaelh, ngraham, bruns


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

2020-05-24 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D29747#671169 , @svuorela wrote:
  
  > I think we should wait a bit with formally deprecating. I like add the new, 
wait a bit, then deprecate.
  
  
  `@deprecated since 5.69 Prefer preferredSize() or trueMinimumSize().` is no 
formal deprecation? It would be for me though, thus I am puzzled why the reader 
of the API dox & the compiler are differently instructed here currently. Could 
you elaborate? :)

REPOSITORY
  R280 Prison

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

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


D28528: UDSEntry: add constructor variant with std::initializer_list

2020-05-24 Thread Friedrich W. H. Kossebau
kossebau abandoned this revision.
kossebau added a comment.


  As I am not sure about the risk introduced  by the just-works-currently 
alignment in the union, I would rather discard this patch for now. Going from 
union to having both fields increases the runtime for what I measured, despite 
the reserve(), so also not eager to add that just for some syntactic sugar.
  Happy to have somebody else pick this up though, just not continuing myself.

INLINE COMMENTS

> dfaure wrote in udsentry.h:132
> Why not simply QString*?

How would you see `QString*` be used here?

> dfaure wrote in udsentrybenchmark.cpp:141
> std::move(entry) if you want to skip the copying?

This test is a copy from UDSEntryBenchmark::createSmallEntries() just with 
different UDSEntry constructor so I did not question things :)
Though append() might be what the benchmark is about?

REPOSITORY
  R241 KIO

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

To: kossebau, #frameworks, dfaure, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29003: Use Q_EMIT and build with QT_NO_KEYWORDS

2020-05-24 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  @junghans Hi. Do you have push rights, or do you need someone to merge your 
patch?

REPOSITORY
  R275 KItemModels

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

To: junghans, kossebau, dfaure, apol
Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, 
bruns


D29600: Fix build with KF set to EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT

2020-05-24 Thread Friedrich W. H. Kossebau
kossebau closed this revision.

REPOSITORY
  R242 Plasma Framework (Library)

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

To: kossebau, #plasma, mart, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29574: Use KSERVICE_DEPRECATED_VERSION_BELATED

2020-05-24 Thread Friedrich W. H. Kossebau
kossebau closed this revision.

REPOSITORY
  R309 KService

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

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


D29281: Deprecate defunct functions

2020-05-22 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> abstractrunner.h:154
>   * is called, the runner should return true
> + * @deprecated Since 5,0, this feature has been defunct
>   */

Should be "5.0", not "5,0" here in the API dox text and elsewhere, no? (dot 
instead of comma)

> abstractrunner.h:156
>   */
> +KRUNNER_DEPRECATED_VERSION(5, 71, "No longer use, feature removed")
>  bool hasRunOptions();

ECMGenerateExportHeader now (for 5.71) features support for using a different 
version number to be shown in the compiler warning: 
KRUNNER_DEPRECATED_VERSION_BELATED

So you could make this:

  KRUNNER_DEPRECATED_VERSION_BELATED(5, 71,  5, 0, "No longer use, feature 
removed")

REPOSITORY
  R308 KRunner

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

To: alex, #plasma, broulik, davidedmundson, vkrause, meven
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29797: Unbreak generation with dep diagrams with Python 3 (break Py2)

2020-05-19 Thread Friedrich W. H. Kossebau
kossebau closed this revision.

REPOSITORY
  R264 KApiDox

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

To: kossebau, #frameworks, ochurlaud, ognarb, cblack, winterz, francescorios
Cc: asturmlechner, kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, 
gennad, fbampaloukas, michaelh, ngraham, bruns, skadinna


D29797: Unbreak generation with dep diagrams with Python 3 (break Py2)

2020-05-19 Thread Friedrich W. H. Kossebau
kossebau retitled this revision from "[RAW PATCH] Unbreak generation with dep 
diagrams with Python 3 (& break P2 :) )" to "Unbreak generation with dep 
diagrams with Python 3 (break Py2)".
kossebau edited the summary of this revision.

REPOSITORY
  R264 KApiDox

BRANCH
  makedepworkwithpython3

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

To: kossebau, #frameworks, ochurlaud, ognarb, cblack, winterz, francescorios
Cc: asturmlechner, kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, 
gennad, fbampaloukas, michaelh, ngraham, bruns, skadinna


D29797: [RAW PATCH] Unbreak generation with dep diagrams with Python 3 (& break P2 :) )

2020-05-19 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Patch worked fine also on real server run the last two nights. So going to 
push later today once at my respective development setup. Will push as is, 
given safe_load() is now also used without any conditions for the new 
invent.kde.org git helper :) so doing as the real Python developers do.

REPOSITORY
  R264 KApiDox

BRANCH
  makedepworkwithpython3

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

To: kossebau, #frameworks, ochurlaud, ognarb, cblack, winterz, francescorios
Cc: asturmlechner, kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, 
gennad, fbampaloukas, michaelh, ngraham, bruns, skadinna


D29797: [RAW PATCH] Unbreak generation with dep diagrams with Python 3 (& break P2 :) )

2020-05-17 Thread Friedrich W. H. Kossebau
kossebau added reviewers: winterz, francescorios.

REPOSITORY
  R264 KApiDox

BRANCH
  makedepworkwithpython3

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

To: kossebau, #frameworks, ochurlaud, ognarb, cblack, winterz, francescorios
Cc: asturmlechner, kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, 
gennad, fbampaloukas, michaelh, ngraham, bruns, skadinna


D29797: [RAW PATCH] Unbreak generation with dep diagrams with Python 3 (& break P2 :) )

2020-05-17 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Bah, I patched the wrong kapidox on the server, so last nights run still 
failed. Oh well... not sure I will have time in the evening for processing this 
patch, but at least now getting the diff applied also on the right kapidox, so 
next server check tomorrow.

REPOSITORY
  R264 KApiDox

BRANCH
  makedepworkwithpython3

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

To: kossebau, #frameworks, ochurlaud, ognarb, cblack
Cc: asturmlechner, kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, 
gennad, fbampaloukas, michaelh, ngraham, bruns, skadinna


D29797: [RAW PATCH] Unbreak generation with dep diagrams with Python 3 (& break P2 :) )

2020-05-16 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  I just applied the diff as-is to the working checkout of kapidox on the 
server, to see if the patch also works for the setup of the nightly run, other 
than my separate testing which might have missed any special environment setup. 
So tomorrow before noon CEST we should have proof this patch catches all issues.
  So no immediate pressure to get this patch out ASAP to also get api.kde.org 
running again :)
  
  Thanks for the additional replies, will look with attention tomorrow, afk 
this evening now.

REPOSITORY
  R264 KApiDox

BRANCH
  makedepworkwithpython3

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

To: kossebau, #frameworks, ochurlaud, ognarb, cblack
Cc: kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, gennad, 
fbampaloukas, michaelh, ngraham, bruns, skadinna


D29797: [RAW PATCH] Unbreak generation with dep diagrams with Python 3 (& break P2 :) )

2020-05-16 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Thanks for the (first) review :)
  
  Open questions I have are these:
  a) how to properly check for the presence of the yaml.safe_load() method? and 
whether to support a fallback to load() otherwise? It was only introduced at a 
certain version of pyyaml
  b) by supposedly breaking support for Python 2, how to properly catch any 
usage of python2 now?

REPOSITORY
  R264 KApiDox

BRANCH
  makedepworkwithpython3

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

To: kossebau, #frameworks, ochurlaud, ognarb, cblack
Cc: kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, gennad, 
fbampaloukas, michaelh, ngraham, bruns, skadinna


D29797: [RAW PATCH] Unbreak generation with dep diagrams with Python 3 (& break P2 :) )

2020-05-16 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, ochurlaud, ognarb.
Herald added projects: Frameworks, Documentation.
Herald added subscribers: kde-doc-english, kde-frameworks-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  This patch makies kapidox work for me when also generating dependency
  diagrams, both locally with what openSUSE TW provides as well as what there
  is now on the updated zivo (api.kde.org).
  
  Uploaded for first feedback, surely needs more refinement.
  
  Not being a real Python developer myself, this is just naive sample-based 
hackery and was
  not tested against Python2 (possibly breaking things due to the string
  stuff). Though I guess everyone agrees we should simply drop now the Python2
  support from kapidix, with api.kde.org server no longer needing it.

REPOSITORY
  R264 KApiDox

BRANCH
  makedepworkwithpython3

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

AFFECTED FILES
  src/kapidox/depdiagram/framework.py
  src/kapidox/depdiagram/frameworkdb.py
  src/kapidox/depdiagram/generate.py
  src/kapidox/depdiagram/gvutils.py
  src/kapidox/preprocessing.py

To: kossebau, #frameworks, ochurlaud, ognarb
Cc: kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, gennad, 
fbampaloukas, michaelh, ngraham, bruns, skadinna


D29502: kwidgetsaddons: Add a named colors support in KColorCombo.

2020-05-16 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> kcolorcombo.cpp:222
> +namedColors.reserve(colors.size());
> +for (auto color : colors) {
> +namedColors.append({QString(), color});

`auto& ` as we just want a reference, avoids a copy constructor call each time.

> kcolorcombo.cpp:253
> +list.reserve(d->colorList.size());
> +for (auto color : d->colorList) {
> +list.append({color.second});

`auto& ` as we just want a reference, avoids a copy constructor call each time.

> kcolorcombo.cpp:264
> +ColorList list;
> +for (int index = 0; index < STANDARD_PALETTE_SIZE; ++index) {
> +list += {QString(), standardColor(index)};

list.reserve(STANDARD_PALETTE_SIZE);

REPOSITORY
  R236 KWidgetsAddons

BRANCH
  named_color_support

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

To: araujoluis, tcanabrava, patrickelectric, hindenburg, ngraham, #vdg
Cc: kossebau, cblack, broulik, cfeck, kde-frameworks-devel, LeGast00n, 
michaelh, ngraham, bruns


D29502: kwidgetsaddons: Add a named colors support in KColorCombo.

2020-05-16 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Isn't the recommendation to rather avoid using things like QPair, and instead 
used properly defined structs? And ideally non-nested ones, to help with cases 
of forward declarations? 
  Even QPair's API dox says so: 
  "The advent of C++11 automatic variable type deduction (auto) shifts the 
emphasis from the type name to the name of functions and members. Thus, QPair, 
like std::pair and std::tuple, is mostly useful in generic (template) code, 
where defining a dedicated type is not possible."
  
  Code which uses ".first" and ".second" is harder to understand. And any users 
of the new API who want to pass in named colors but who cannot make use of 
auto-derived type name or init-list constructors, so have to explicitly write 
the name would also prefer some named type over QPair. So 
please reconsider using some non-nested struct, perhaps named e.g. 
"KNamedColor".
  The alias "ColorList" might be also confusing, as it misses to point out this 
is a list of named colors, not just a list of colors (one might naively think 
of QList). "NamedColorList" would be less ambiguous.
  
  And as long as we are Qt5 at least., QVector would also be favourable here 
over QList given the size of the list item type and given that insertions are 
not expected to be typically done on this type.

REPOSITORY
  R236 KWidgetsAddons

BRANCH
  named_color_support

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

To: araujoluis, tcanabrava, patrickelectric, hindenburg, ngraham, #vdg
Cc: kossebau, cblack, broulik, cfeck, kde-frameworks-devel, LeGast00n, 
michaelh, ngraham, bruns


D29558: Add KIO::OpenUrlJob::setShowOpenWithDialog as replacement for KRun::displayOpenWithDialog

2020-05-15 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> openurljob.h:119
> + * a different implementation on Windows.
> + *
> + * @param b whether to only show the "open with" dialog.

Please mention explicit what the default is (false),  to remove any ambiguity.

Some other setters might want to have this stated as well, btw.

REPOSITORY
  R241 KIO

BRANCH
  2020_05_displayOpenWithDialog

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

To: dfaure, ahmadsamir, broulik, svuorela
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29558: Add KIO::OpenUrlJob::setShowOpenWithDialog as replacement for KRun::displayOpenWithDialog

2020-05-15 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> ahmadsamir wrote in openurljob.h:120
> It seems that we shouldn't end @param with a ".", according to @kossebau 
> anyway...

You meant, according to 
https://community.kde.org/Frameworks/Frameworks_Documentation_Policy#Document_Public_and_Protected_Members
 :)

REPOSITORY
  R241 KIO

BRANCH
  2020_05_displayOpenWithDialog

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

To: dfaure, ahmadsamir, broulik, svuorela
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


Re: Request for ktexteditor patch release

2020-05-15 Thread Friedrich W. H. Kossebau
Am Freitag, 15. Mai 2020, 12:03:08 CEST schrieb David Faure:
> On vendredi 15 mai 2020 11:01:04 CEST Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > I would like to ask for a 5.70 patch release for ktexteditor, with
> > 972da14f486a83556e192d09bb18a2500728895a cherry-picked.
> > 
> > Not a crasher, but preventing the pickup of any global view setting
> > changes
> > after a kate/kdevelop session close & open cycle for existing document
> > views, which has been hit and reported by a few people already the last
> > days.
> 
> Thanks for the notification. Done:
> 
> ktexteditor v5.70.1
> 5e6ea19f95a36e21473c00a8d30cbea0f150a13f
> c7b568e75c147161992f8875fe36fb46885bccddb63c22edaf81071583f4204c 
> sources/ktexteditor-5.70.1.tar.xz

Merci.

> Please add a description of the bug in www/info/kde-frameworks-5.70.0.php
> (or give me a patch if you can't push).

No checkout of the respective repo, so possibly fastest if I give you the raw 
data here:
* KTextEditor global view setting changes ignored after session reopening 
(Kate, KDevelop)
https://bugs.kde.org/show_bug.cgi?id=421375

> Also, please make sure to write a unittest for this regression so we catch
> it next time.

Yup. 

Cheers
Friedrich




Request for ktexteditor patch release

2020-05-15 Thread Friedrich W. H. Kossebau
Hi,

I would like to ask for a 5.70 patch release for ktexteditor, with 
972da14f486a83556e192d09bb18a2500728895a cherry-picked.

Not a crasher, but preventing the pickup of any global view setting changes 
after a kate/kdevelop session close & open cycle for existing document views, 
which has been hit and reported by a few people already the last days.

Cheers
Friedrich




D27844: Store and fetch complete view config in and from session config

2020-05-15 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D27844#671380 , @dhaumann wrote:
  
  > I suggest to revert, and send a notification with the change to 
kde-distro-packa...@kde.org to avoid that many users break their configuration.
  
  
  Okay, doing now.

REPOSITORY
  R39 KTextEditor

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

To: kossebau, #kate, loh.tar, cullmann, dhaumann
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann


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

2020-05-14 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D29747#671169 , @svuorela wrote:
  
  > I think we should wait a bit with formally deprecating. I like add the new, 
wait a bit, then deprecate.
  
  
  So you propose to also remove the `@deprecated` from the API dox?
  
  And wait, for what to happen?

REPOSITORY
  R280 Prison

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

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


D27844: Store and fetch complete view config in and from session config

2020-05-14 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Seems this change has some sideeffects I did not experience when I played 
with this, but which are now uncovering as it hits people usinjg KF 5.70 :
  config seems to write any settings, also the ones inherited from global 
defaults, as view-specific settings, and when reading them in again on session 
restart, they all become view-specific overrides, thus no longer influencable 
by global settings. Is that due to some other change elsewhere, or did I just 
completely miss this?
  
  Possibly though this was mentioned before though:
  
  In D27844#624950 , @dhaumann wrote:
  
  > I guess we can give this a try. As I understand, though, with this patch 
you will never be able to use e.g. a global zoom once you change the zoom of a 
view. This was different before this patch.
  
  
  If so, I did not get the message, as I was focussed on the property itself, 
"zoom", which is not covered by the settings handled here.
  
  So, what to do? I would argue that revert would be the best option for now, 
as the sideeffects are more grave than what this patch tried to solve.

REPOSITORY
  R39 KTextEditor

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

To: kossebau, #kate, loh.tar, cullmann, dhaumann
Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, 
michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann


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

2020-05-14 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> abstractbarcode.h:69
>   */
> +PRISON_DEPRECATED_VERSION_BELATED(5, 71, 5, 69, "Use preferredSize() or 
> trueMinimumSize()")
>  QSizeF minimumSize() const;

D29573  bringing _BELATED only landed a few 
days ago, but can already serve here for another case :)

REPOSITORY
  R280 Prison

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

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


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

2020-05-14 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, svuorela, vkrause.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REPOSITORY
  R280 Prison

BRANCH
  fullydeprecateminimumsize

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

AFFECTED FILES
  autotests/aztecbarcodetest.cpp
  autotests/code128barcodetest.cpp
  src/lib/CMakeLists.txt
  src/lib/abstractbarcode.cpp
  src/lib/abstractbarcode.h
  tests/barcodeexamplewidget.cpp

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


D27989: Add a new set of barcode size functions

2020-05-14 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D27989#670659 , @vkrause wrote:
  
  > 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).
  
  
  For projects who cannot/do not want yet to adapt to deprecated API (e.g. 
because they do not fancy #if version #else #endif), they can make use of the 
built-in features with the deprecation system to deactivate warnings for any 
API which was set as deprecated initially only after a certain version:
  
  - QT_DEPRECATED_WARNINGS_SINCE (as in, show warnings for API deprecated at 
least since or already in older versions)
  - KF_DEPRECATED_WARNINGS_SINCE (same as above, KF_ being the group default, 
with KFOO_ allowing to fine-tune per module)
  
  Both are by default set to the number of the current version (so all warnings 
are shown), but if using QT_DISABLE_DEPRECATED_BEFORE or 
KF_DISABLE_DEPRECATED_BEFORE_AND_AT (& KFOO_DISABLE_DEPRECATED_BEFORE_AND_AT) 
those are defaulting instead to the version given in those macro, so 
automatically disabling any warnings for API deprecated in newer versions. One 
has to actively overwrite that to see warnings again (like e..g done for KF 
modules gloibally in 
https://phabricator.kde.org/source/extra-cmake-modules/browse/master/kde-modules/KDEFrameworkCompilerSettings.cmake$68
  
add_definitions(
-DQT_DEPRECATED_WARNINGS_SINCE=0x06
-DKF_DEPRECATED_WARNINGS_SINCE=0x06
)
  
  So the idea here is to allow to disable warnings for API deprecations one 
does not want to care about (yet). So unwanted noise should be design not be a 
reason here to delay adding the compiler warning macro and the compiler 
visibility wrapper. Note: Qt is lacking a bit here and there, some deprecations 
are not properly tagged to support that. KF instead shines there :)
  
  For being silent about the warnings while still doing patches all yourself: 
while of course it is nice/recommended to help all KDE projects to adapt to 
some new API by the persons who introduced it, it also is good to get some real 
world feedback by having people with other mindsets who try to make use of the 
new API, and who thus might discover issues with the new API or its 
documentation. And some people are just fine to help out for their own projects 
to jump to latest best API as well, so they would be happy to learn about as 
early as possible by having the compiler points things out.
  
  See e.g. how KRun is deprecated currently. Are people upset about the 
approach? I do not think so. Because they see David going around and helping 
with the ports. And they see how the new async API is better.
  
  So, no harm here in having the compiler from day one inform interested 
developers about the deprecation. IMHO, but also covered by what is done 
elsewhere :) Actually, it is part of the design with the control about compiler 
warnings by version.

REPOSITORY
  R280 Prison

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

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


D29708: Introduce EXCLUDE_DEPRECATED_BEFORE_AND_AT

2020-05-13 Thread Friedrich W. H. Kossebau
This revision was automatically updated to reflect the committed changes.
Closed by commit R241:391351a6be0e: Introduce EXCLUDE_DEPRECATED_BEFORE_AND_AT 
(authored by kossebau).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29708?vs=82730=82806

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

AFFECTED FILES
  CMakeLists.txt
  autotests/CMakeLists.txt
  autotests/clipboardupdatertest.cpp
  autotests/kfilewidgettest.cpp
  autotests/krununittest.cpp
  autotests/krununittest.h
  autotests/kurlnavigatortest.cpp
  autotests/kurlnavigatortest.h
  src/core/CMakeLists.txt
  src/core/copyjob.cpp
  src/core/global.cpp
  src/core/idleslave.cpp
  src/core/job.cpp
  src/core/kfileitem.cpp
  src/core/ksambashare.cpp
  src/core/ksambashare_p.h
  src/core/ksslcertificatemanager.cpp
  src/core/ksslcertificatemanager.h
  src/core/ksslcertificatemanager_p.h
  src/core/ksslerror_p.h
  src/core/ksslerroruidata.cpp
  src/core/ktcpsocket.cpp
  src/core/scheduler.cpp
  src/core/slavebase.cpp
  src/core/slaveinterface.cpp
  src/core/statjob.cpp
  src/core/transferjob.cpp
  src/core/udsentry.cpp
  src/filewidgets/CMakeLists.txt
  src/filewidgets/kfilepreviewgenerator.cpp
  src/filewidgets/kfilewidget.cpp
  src/filewidgets/kurlnavigator.cpp
  src/kssld/kssld.cpp
  src/widgets/CMakeLists.txt
  src/widgets/accessmanager.cpp
  src/widgets/kdirmodel.cpp
  src/widgets/kpropertiesdialog.cpp
  src/widgets/krun.cpp
  src/widgets/ksslinfodialog.cpp
  src/widgets/ksslinfodialog.h
  src/widgets/kurifilter.cpp
  src/widgets/kurlrequester.cpp
  src/widgets/kurlrequester.h
  src/widgets/kurlrequesterdialog.cpp
  src/widgets/paste.cpp
  src/widgets/previewjob.cpp
  src/widgets/renamedialog.cpp
  src/widgets/sslui.cpp
  src/widgets/thumbcreator.cpp
  tests/CMakeLists.txt

To: kossebau, #frameworks, dfaure, meven, ahmadsamir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29707: Remove deprecation tag from SlaveBase::config() for now

2020-05-13 Thread Friedrich W. H. Kossebau
This revision was automatically updated to reflect the committed changes.
Closed by commit R241:c7b164496354: Remove deprecation tag from 
SlaveBase::config() for now (authored by kossebau).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29707?vs=82729=82799

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

AFFECTED FILES
  src/core/slavebase.h

To: kossebau, #frameworks, meven, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D27989: Add a new set of barcode size functions

2020-05-13 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  > 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.

REPOSITORY
  R280 Prison

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

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


D29573: ECMGenerateExportHeader: add generation of *_DEPRECATED_VERSION_BELATED()

2020-05-13 Thread Friedrich W. H. Kossebau
This revision was automatically updated to reflect the committed changes.
Closed by commit R240:cc8bccadcdb9: ECMGenerateExportHeader: add generation of 
*_DEPRECATED_VERSION_BELATED() (authored by kossebau).

REPOSITORY
  R240 Extra CMake Modules

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29573?vs=82393=82764

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

AFFECTED FILES
  modules/ECMGenerateExportHeader.cmake

To: kossebau, #frameworks, #build_system, dfaure
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29708: Introduce EXCLUDE_DEPRECATED_BEFORE_AND_AT

2020-05-13 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  @dfaure So far I had no idea how to introduce a simple variant of the 
deprecation macros to support just disabling latest. For one would this make 
things more complex as there would be yet another approach. And things would be 
also become a bit unreliable on the library consumer side, as any version-less 
BUILD_DEPRECATED would no longer be bound to a version and thus to a certain 
set of API.
  
  And as said in the commit message, the current version-based 
EXCLUDE_DEPRECATED_BEFORE_AND_AT can also be used with KIO, if we simply just 
give no guarantee that this works with any version, but only with some, with 
better chances for future versions (if people now make sure things build 
without deprecated API and do not reintroduce the use of already deprecated 
API) :)
  
  Using this patch with EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT shows that 
there are lots of KRun::run* usages in non-deprecated API sadly in KIO :(

REPOSITORY
  R241 KIO

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

To: kossebau, #frameworks, dfaure, meven, ahmadsamir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29708: Introduce EXCLUDE_DEPRECATED_BEFORE_AND_AT

2020-05-13 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, dfaure, meven, ahmadsamir.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Not all versions of the past will work as value, mainly to be used with
  values "0" or "CURRENT". If any new deprecations are done without
  having code starting to use older deprecated API, in the future any
  versions >= 5.71.0 should work also reliably.
  
  Currently a build with EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT does
  not yet work, some API deprecated is still used internally by
  code behind non-deprecated API. Building with CURRENT will show by the
  failed build which those are.

TEST PLAN
  Builds with values 0, 5.70.0 (with D29707 
).

REPOSITORY
  R241 KIO

BRANCH
  excludedeprecated

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

AFFECTED FILES
  CMakeLists.txt
  autotests/CMakeLists.txt
  autotests/clipboardupdatertest.cpp
  autotests/kfilewidgettest.cpp
  autotests/krununittest.cpp
  autotests/krununittest.h
  autotests/kurlnavigatortest.cpp
  autotests/kurlnavigatortest.h
  src/core/CMakeLists.txt
  src/core/copyjob.cpp
  src/core/global.cpp
  src/core/idleslave.cpp
  src/core/job.cpp
  src/core/kfileitem.cpp
  src/core/ksambashare.cpp
  src/core/ksambashare_p.h
  src/core/ksslcertificatemanager.cpp
  src/core/ksslcertificatemanager.h
  src/core/ksslcertificatemanager_p.h
  src/core/ksslerror_p.h
  src/core/ksslerroruidata.cpp
  src/core/ktcpsocket.cpp
  src/core/scheduler.cpp
  src/core/slavebase.cpp
  src/core/slaveinterface.cpp
  src/core/statjob.cpp
  src/core/transferjob.cpp
  src/core/udsentry.cpp
  src/filewidgets/CMakeLists.txt
  src/filewidgets/kfilepreviewgenerator.cpp
  src/filewidgets/kfilewidget.cpp
  src/filewidgets/kurlnavigator.cpp
  src/kssld/kssld.cpp
  src/widgets/CMakeLists.txt
  src/widgets/accessmanager.cpp
  src/widgets/kdirmodel.cpp
  src/widgets/kpropertiesdialog.cpp
  src/widgets/krun.cpp
  src/widgets/ksslinfodialog.cpp
  src/widgets/ksslinfodialog.h
  src/widgets/kurifilter.cpp
  src/widgets/kurlrequester.cpp
  src/widgets/kurlrequester.h
  src/widgets/kurlrequesterdialog.cpp
  src/widgets/paste.cpp
  src/widgets/previewjob.cpp
  src/widgets/renamedialog.cpp
  src/widgets/sslui.cpp
  src/widgets/thumbcreator.cpp
  tests/CMakeLists.txt

To: kossebau, #frameworks, dfaure, meven, ahmadsamir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29707: Remove deprecation tag from SlaveBase::config() for now

2020-05-13 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, meven, dfaure.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  There is no migration path for all current usages of config()

REPOSITORY
  R241 KIO

BRANCH
  removedeprecatetagfromslavebaseconfig

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

AFFECTED FILES
  src/core/slavebase.h

To: kossebau, #frameworks, meven, dfaure
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D23523: [SlaveBase] Use QMap instead of KConfig to store ioslave config

2020-05-13 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> slavebase.h:355
>   */
> -KConfigGroup *config();
> +KIOCORE_DEPRECATED KConfigGroup *config();
>  

Given there are still a few usages of config() left which seem not easily 
replaceable, it would be better to remove the deprecation tag for the compiler, 
to not have false warnings on those places (see e.g. http.cpp for certain 
usages still).
A deprecation tag should be only set if there is a full migration path 
available ideally, otherwise people will run into warnings they cannot do 
something about.

REPOSITORY
  R241 KIO

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

To: meven, davidedmundson, dfaure, #frameworks
Cc: kossebau, broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D29414: Be noisy about deprecated KPageWidgetItem::setHeader(empty-non-null string)

2020-05-11 Thread Friedrich W. H. Kossebau
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R236:a5692448a750: Be noisy about deprecated 
KPageWidgetItem::setHeader(empty-non-null string) (authored by kossebau).

REPOSITORY
  R236 KWidgetsAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29414?vs=81902=82613

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

AFFECTED FILES
  src/kpagewidgetmodel.cpp
  src/kpagewidgetmodel.h

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


Re: kcoreaddons_add_plugin executable/plugin directory conflict

2020-05-11 Thread Friedrich W. H. Kossebau
Am Montag, 11. Mai 2020, 10:21:10 CEST schrieb Daniel Vrátil:
> Hi all,
> 
> I'm moving some plugins in kaddressbook and I ran into a problem with
> kcoreaddons_add_plugin:

Problem found because you require ECM >= 5.38, triggering the use of the 
CMAKE_BUILD_DIR/bin as executable artifact placement dir by KDECMakeSettings, 
compare https://api.kde.org/ecm/kde-module/KDECMakeSettings.html#build-settings

> I have this in the plugin CMakeLists.txt:
> 
> kaddressbook_add_plugin(
>   kaddressbook_importexportvcardplugin
>   JSON kaddressbook_importexportvcardplugin.json
>   SOURCES ${kaddressbook_importexport_vcard_SRCS}
>   INSTALL_NAMESPACE kaddressbook/importexportplugin
> )
> 
> When I run make on the entire project, it fails with
> 
> [ 65%] Linking CXX shared module ../../../../bin/kaddressbook/
> importexportplugin/kaddressbook_importexportvcardplugin.so
> ld: error: cannot open output file ../../../../bin/kaddressbook/
> importexportplugin/kaddressbook_importexportvcardplugin.so: Not a directory
> 
> Alternatively, if a plugin gets created first, it fails on
> 
> [ 96%] Linking CXX executable ../bin/kaddressbook
> ld: error: cannot open output file ../bin/kaddressbook: Is a directory
> 
> I realized the problem is that CMake is unable to create the plugin in
> $BUILDDIR/bin/kaddressbook/importexportplugin/ directory, because there's
> already $BUILDDIR/bin/kaddressbook executable (or vice versa).
> 
> I would assume this is a very common problem - having plugins "namespaced"
> in the same directory as is the name of the program (and executable).
> Should the macro maybe put the plugins into
> "$BUILDDIR/bin/plugins/$INSTALL_NAMESPACE/"? Would that make the lookup any
> more complicated?
> 
> Is there some known solution/workaround to this? I'd prefer not to have to
> rename the executable or the plugins namespaces, since having different name
> for the program and the plugin "namespace" somewhat defeats the purpose of
> a namespace...

kdeconnect solved this by renaming before, but not with much happiness.

Okular recently in some (later discarded) patches raising min ECM was about to 
hit the same issue as well, there the hint by David was to manually overwrite 
the LIBRARY_OUTPUT_DIRECTORY property for the plugin targets.

Open question is how any changed path there effects the goal of being able to 
run tests against the uninstalled plugins...

Cheers
Friedrich




D28765: KSettings::Dialog: add support for KPluginInfos without a KService

2020-05-10 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> dfaure wrote in kcmoduleinfo.h:131
> It's complicated.
> 
> 1. If you use the QString constructor, you know service() is usable. That's 
> the case for all users of KCModuleInfo except KCModuleLoader. [Not that there 
> are many]
> 
> 2. Even KCModuleLoader calls service(), to test for noDisplay().
> 
> The whole concept of NoDisplay only makes sense for desktop files, unless we 
> want to have that in JSON metadata as well. I suppose we do, but this 
> currently seems to be completely missing (e.g. from KPluginMetaData, if we 
> want this in all plugins, not just KCMs). We'd have to duplicate the logic 
> currently in KService::noDisplay().
> 
> Any volunteers to look into this? :-)

As I just ran into this code, a short reminder: it would be a regression not to 
have a noDisplay check in the case of pure JSON metadata, as the current code 
of KService::;noDisplay() also asks KAuth whether the page should be shown 
(`KAuthorized::authorizeControlModule(storageId())`), which some KIOSK systems 
or admins might rely on, but also `showInCurrentDesktop()` & 
`showOnCurrentPlatform()`, which also still make sense, for what I can tell.

REPOSITORY
  R295 KCMUtils

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

To: dfaure, pino, broulik, mart, davidedmundson, ngraham, svuorela
Cc: kossebau, svuorela, cblack, kde-frameworks-devel, LeGast00n, michaelh, 
ngraham, bruns


D29600: Fix build with KF set to EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT

2020-05-10 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Building all of KF with EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT set, so 
dropping any deprecated API from the build, serves as a small sanity check to 
see if the future (like KF6) is well prepared and there is no hidden 
undeprecated functional dependency on deprecated API. Only backward-compatibel 
functionality should still rely on any deprecated API. Or otherwise the 
deprecation should be undone possibly.
  
  No oversight over Plasma these days, so cannot tell what parts are still 
depending on metadata fetched from desktop files via KService. But given such 
API has been deprecated since KF 5.0 it might be time to complete any missing 
adaption. 
  So any changes done here are solely based on "it builds without deprecated 
API used" :)

REPOSITORY
  R242 Plasma Framework (Library)

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

To: kossebau, #plasma, mart, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29600: Fix build with KF set to EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT

2020-05-10 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Plasma, mart, apol.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  NO_CHANGELOG

REPOSITORY
  R242 Plasma Framework (Library)

BRANCH
  fixbuildwithoutdeprecated

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

AFFECTED FILES
  src/plasma/pluginloader.cpp
  src/plasma/private/containmentactions_p.h

To: kossebau, #plasma, mart, apol
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29572: Build with EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT

2020-05-09 Thread Friedrich W. H. Kossebau
This revision was automatically updated to reflect the committed changes.
Closed by commit R309:c8c10b76931a: Build with 
EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT (authored by kossebau).

REPOSITORY
  R309 KService

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29572?vs=82392=82403

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

AFFECTED FILES
  autotests/kplugininfotest.cpp
  autotests/kservicetest.cpp
  autotests/kservicetest.h
  src/services/kmimetypetrader.cpp
  src/services/kservicefactory.cpp
  src/services/kserviceoffer.cpp
  src/services/kserviceoffer.h
  src/services/kservicetypeprofile.cpp
  src/services/kservicetypeprofile.h
  src/services/kservicetypetrader.cpp
  src/sycoca/kbuildservicefactory.cpp
  src/sycoca/kmimeassociations.cpp

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


D29573: ECMGenerateExportHeader: add generation of *_DEPRECATED_VERSION_BELATED()

2020-05-09 Thread Friedrich W. H. Kossebau
kossebau added a dependent revision: D29574: Use 
KSERVICE_DEPRECATED_VERSION_BELATED.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  addbelated

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

To: kossebau, #frameworks, #build_system, dfaure
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29574: Use KSERVICE_DEPRECATED_VERSION_BELATED

2020-05-09 Thread Friedrich W. H. Kossebau
kossebau added a dependency: D29573: ECMGenerateExportHeader: add generation of 
*_DEPRECATED_VERSION_BELATED().

REPOSITORY
  R309 KService

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

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


D29574: Use KSERVICE_DEPRECATED_VERSION_BELATED

2020-05-09 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, dfaure.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REPOSITORY
  R309 KService

BRANCH
  usebelated

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

AFFECTED FILES
  src/services/kserviceaction.h

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


D29573: ECMGenerateExportHeader: add generation of *_DEPRECATED_VERSION_BELATED()

2020-05-09 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, Build System, dfaure.
Herald added projects: Frameworks, Build System.
Herald added subscribers: kde-buildsystem, kde-frameworks-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Now and then tagging some API as deprecated for the compiler is forgotten.
  Doing this retractivitly in newer versions but using the official version
  might break build setups configured to only show warnings up to a certain
  version and otherwise fail a build, using -Werror=deprecated-declarations.
  
  To allow retroactive tagging of API for compiler warnings, and showing the
  official version in the warniung message, while reacting only to warning
  controls for the current version where the tag is added, avoids any such
  annoying experiences, without wrong version info at the same time.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  addbelated

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

AFFECTED FILES
  modules/ECMGenerateExportHeader.cmake

To: kossebau, #frameworks, #build_system, dfaure
Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, 
michaelh, ngraham, bruns


D29572: Build with EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT

2020-05-09 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, dfaure.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  To also support EXCLUDE_DEPRECATED_BEFORE_AND_AT=5.69.0 properly some
  more if-elif would have been needed, making the code more hard to read.
  Based on dicussion on #kde-devel with dfaure that has been left out,
  for some future non-version-based *_BUILD_DEPRECATED.
  So the focus already is on building without any own deprecated API,
  no-one is expected to use EXCLUDE_DEPRECATED_BEFORE_AND_AT with a
  certain version != CURREENT or 0.

TEST PLAN
  Builds with EXCLUDE_DEPRECATED_BEFORE_AND_AT set to 0 (default) or CURRENT,
  all unit tests pass.

REPOSITORY
  R309 KService

BRANCH
  buildwithoutdeprecated

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

AFFECTED FILES
  autotests/kplugininfotest.cpp
  autotests/kservicetest.cpp
  autotests/kservicetest.h
  src/services/kmimetypetrader.cpp
  src/services/kservicefactory.cpp
  src/services/kserviceoffer.cpp
  src/services/kserviceoffer.h
  src/services/kservicetypeprofile.cpp
  src/services/kservicetypeprofile.h
  src/services/kservicetypetrader.cpp
  src/sycoca/kbuildservicefactory.cpp
  src/sycoca/kmimeassociations.cpp

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


D29561: Add missing compiler deprecation tag for 5-args KServiceAction constructor

2020-05-09 Thread Friedrich W. H. Kossebau
This revision was automatically updated to reflect the committed changes.
Closed by commit R309:429c80c96142: Add missing compiler deprecation tag for 
5-args KServiceAction constructor (authored by kossebau).

REPOSITORY
  R309 KService

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29561?vs=82369=82370

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

AFFECTED FILES
  src/CMakeLists.txt
  src/services/kserviceaction.h

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


D29561: Add missing compiler deprecation tag for 5-args KServiceAction constructor

2020-05-09 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, dfaure.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REPOSITORY
  R309 KService

BRANCH
  addmissingdeprecationtag

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

AFFECTED FILES
  src/CMakeLists.txt
  src/services/kserviceaction.h

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


D29370: Use UI marker context in more tr() calls

2020-05-08 Thread Friedrich W. H. Kossebau
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R289:d256eaf8d8ed: Use UI marker context in more tr() calls 
(authored by kossebau).

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29370?vs=81762=82330

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

AFFECTED FILES
  src/kstatusnotifieritem.cpp

To: kossebau, #frameworks, #localization, broulik
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29369: Use UI marker context in more tr() calls

2020-05-08 Thread Friedrich W. H. Kossebau
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R294:1d8d223745eb: Use UI marker context in more tr() calls 
(authored by kossebau).

REPOSITORY
  R294 KBookmarks

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29369?vs=81761=82329

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

AFFECTED FILES
  src/kbookmarkcontextmenu.cpp
  src/kbookmarkmenu.cpp
  src/konqbookmarkmenu.cpp

To: kossebau, #frameworks, #localization
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29368: Use UI marker context in more tr() calls

2020-05-08 Thread Friedrich W. H. Kossebau
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R284:5b08593fc0c4: Use UI marker context in more tr() calls 
(authored by kossebau).

REPOSITORY
  R284 KCompletion

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29368?vs=81760=82328

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

AFFECTED FILES
  src/khistorycombobox.cpp
  src/klineedit.cpp

To: kossebau, #frameworks, #localization
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29367: Use UI marker context in more tr() calls

2020-05-08 Thread Friedrich W. H. Kossebau
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R276:df9e5d3bb765: Use UI marker context in more tr() calls 
(authored by kossebau).

REPOSITORY
  R276 KItemViews

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29367?vs=81759=82327

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

AFFECTED FILES
  src/kfilterproxysearchline.cpp
  src/ktreewidgetsearchline.cpp

To: kossebau, #frameworks, #localization, davidedmundson
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29363: Use UI marker context in more tr() calls

2020-05-08 Thread Friedrich W. H. Kossebau
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R236:5904c475cb37: Use UI marker context in more tr() calls 
(authored by kossebau).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29363?vs=81744=82326#toc

REPOSITORY
  R236 KWidgetsAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29363?vs=81744=82326

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

AFFECTED FILES
  src/kactionselector.cpp
  src/kassistantdialog.cpp
  src/kcharselect.cpp
  src/kcolorcombo.cpp
  src/kdatepicker.cpp
  src/kdatetimeedit.cpp
  src/keditlistwidget.cpp
  src/kfontchooser.cpp
  src/kfontchooserdialog.cpp
  src/kfontrequester.cpp
  src/kmessagewidget.cpp
  src/kmimetypechooser.cpp
  src/knewpassworddialog.cpp
  src/knewpasswordwidget.ui
  src/kpassworddialog.cpp
  src/kpassworddialog.ui
  src/kpasswordlineedit.cpp
  src/kpixmapregionselectordialog.cpp
  src/kpixmapregionselectorwidget.cpp
  src/ksqueezedtextlabel.cpp

To: kossebau, #frameworks, #localization, cfeck
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29414: Be noisy about deprecated KPageWidgetItem::setHeader(empty-non-null string)

2020-05-08 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Ping? If no-one objects would push upcoming Monday, May 11th.

REPOSITORY
  R236 KWidgetsAddons

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

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


D29541: KBookmarkMenuTest: extend unittest to cover undeprecated API

2020-05-08 Thread Friedrich W. H. Kossebau
This revision was automatically updated to reflect the committed changes.
Closed by commit R294:50c5c2fd7e5c: KBookmarkMenuTest: extend unittest to cover 
undeprecated API (authored by kossebau).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D29541?vs=82300=82308#toc

REPOSITORY
  R294 KBookmarks

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D29541?vs=82300=82308

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

AFFECTED FILES
  autotests/kbookmarkmenutest.cpp

To: kossebau, #frameworks, nicolasfella, dfaure, ahmadsamir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29541: KBookmarkMenuTest: extend unittest to cover undeprecated API

2020-05-08 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, nicolasfella, dfaure, ahmadsamir.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REPOSITORY
  R294 KBookmarks

BRANCH
  extendunittestfornudeprecated

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

AFFECTED FILES
  autotests/kbookmarkmenutest.cpp

To: kossebau, #frameworks, nicolasfella, dfaure, ahmadsamir
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29397: KPreviewJob : Support for DeviceRatioPixel

2020-05-08 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  In D29397#666134 , @meven wrote:
  
  > In D29397#666132 , @kossebau 
wrote:
  >
  > > For another stupid question (the first one was already asked by someone 
else and answered :) ):
  > >  Given some generated thumbnails are cached, does the thumbnail cache 
specification support logical resolution?
  >
  >
  > I am evolving here the specification : the images stored are stored with 
their HiDpi size (width * dpr, height * dpr), and then some metadata is written.
  
  
  Specification as in, 
https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html?
 So there is some work on extending the specs not yet reflected on that page?
  How is the metadata written?
  
  >> How would cached thumbnails work cross-screen?
  > 
  > Cache thumbnails with low dpr will look blurry on hidpi screen, other than 
that's not an issue.
  
  Cached thumbnails rendered for hidpi (so e.g. being 256x256 with bigger 
details due to hidpi context) , but used for lowdpi elsewhere will be an issue 
as well. E.g. when it comes to text rendered with minfontsize like in case of 
plain text documents, it will be too large then.
  
  I wonder if the thumbnail cache would not need the same extension like the 
icon spec had, with a @2x variant, to make up for that. There are still a lot 
of lowdpi devices out there, and they are getting mixed.

REPOSITORY
  R241 KIO

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

To: meven, dfaure, broulik, #frameworks
Cc: kossebau, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D29397: KPreviewJob : Support for DeviceRatioPixel

2020-05-08 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  For another stupid question (the first one was already asked by someone else 
and answered :) ):
  Given some generated thumbnails are cached, does the thumbnail cache 
specification support logical resolution? How would cached thumbnails work 
cross-screen?

REPOSITORY
  R241 KIO

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

To: meven, dfaure, broulik, #frameworks
Cc: kossebau, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, 
michaelh, ngraham, bruns


D29363: Use UI marker context in more tr() calls

2020-05-05 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Thanks Albert (& Luigi) for review. With no-one objecting, I would proceed to 
push this upcoming WE, 9/10th May, to be early in the cycle still.

REPOSITORY
  R236 KWidgetsAddons

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

To: kossebau, #frameworks, #localization, cfeck
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29427: [KBookmarkMenu] Assign m_actionCollection early to prevent crash

2020-05-04 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  5.70 wants this as appended commit, no?

REPOSITORY
  R294 KBookmarks

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

To: ahmadsamir, #frameworks, dfaure, kossebau, nicolasfella
Cc: rikmills, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D28800: Always create actioncollection

2020-05-04 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> kbookmarkmenu.cpp:69
>  {
>  m_actionCollection = actionCollection;
>  }

This resetting of m_actionCollection in the constructor taking an 
actionCollection still results in issues, as this  KBookmarkMenu constructor 
taking an actionCollection calls the other constructors not taking an 
actioncollection, but only resets the m_actionCollection afterwards.

As a result the addActions() call in the other constructor will operate on an 
actionCollection object which is then hidden here again. And also the 
actionCollection passed will not have any actions added.

So any code which tries to access actions unconditionally from the 
actionCollection using the action id, like "add_bookmark", will get a nullptr 
and then go boom.

Like happens for Konsole which got built still using the old constructor taking 
a actionCollection, see https://bugs.kde.org/show_bug.cgi?id=420820

REPOSITORY
  R294 KBookmarks

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

To: nicolasfella, #frameworks, dfaure, stefanocrocco
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29414: Be noisy about deprecated KPageWidgetItem::setHeader(empty-non-null string)

2020-05-04 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, cfeck.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REPOSITORY
  R236 KWidgetsAddons

BRANCH
  warnaboutdeprecatedemptynonnullheader

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

AFFECTED FILES
  src/kpagewidgetmodel.cpp
  src/kpagewidgetmodel.h

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


D29390: Respect QIcon::fallbackSearchpaths()

2020-05-03 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> aacid wrote in kiconloader.cpp:1142
> I just realized that function is private, not really easy to use :/
> 
> anyhow do you think we should remove svgz?
> 
> Also i think using
> 
> const QStringList extensions = { QStringLiteral(".png"), 
> QStringLiteral(".svg"), QStringLiteral(".svgz"), QStringLiteral(".xpm") };
> 
> should be a bit faster

You could make this even a stack-only array, even more fast due to no heap 
alloc ;)

  const QString extensions[] = { QStringLiteral(".png"), 
QStringLiteral(".svg"), QStringLiteral(".svgz") << QStringLiteral(".xpm" };

REPOSITORY
  R302 KIconThemes

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

To: nicolasfella, #plasma, #frameworks
Cc: kossebau, aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, 
ngraham, bruns


D29391: Introduce setWindow and CloseWhenWindowActivated

2020-05-03 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> knotification.h:582
>  
> +/** Sets the window associated with this notification.
> + *  This is relevant when using the CloseWhenWindowActivated flag.

And some remarks from a local API docs pedant :)

Please place the text not on the first line after "/**", but the second line 
only (for consistency at least). Also keep indent at one space in the following 
lines then again afte the asterisk.

Also wants a "@since" note, same with the getter :) Them being jealous on the 
one you gave to the flag.

I would also propose to place these methods for the new property before the two 
methods tagged with "@internal", to keep some ordering in the list of methods 
for the human reader of the code.

REPOSITORY
  R289 KNotifications

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

To: nicolasfella, #frameworks, broulik
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29385: Introduce KIO::OpenUrlJob, a rewrite and replacement for KRun

2020-05-03 Thread Friedrich W. H. Kossebau
kossebau added a comment.


  Quick first nitpicks from initial scan what this patch is about, without 
having looked closer.

INLINE COMMENTS

> openurljobtest.cpp:108
> +{
> +std::for_each(m_filesToRemove.begin(), m_filesToRemove.end(), [](const 
> QString & f) {
> +QFile::remove(f);

why no simple range-based for loop?

> openurljob.h:73
> + */
> +void setRunFlags(ApplicationLauncherJob::RunFlags runFlags);
> +

Makes me wonder if those runflags should not be rather part of KIO namespace, 
to decouple classes here.

> openurljob.h:96
> + */
> +void setRunExecutables(bool allow);
> +

Could this and the following bool flags be turned into some flags instead? Just 
wondering, not looked further.

Also wondering if there should not be some getter as well, when using a flagset 
that would be just a single method/symbol.

> openurljob.h:127
> + */
> +void mimetypeFound(const QString );
> +

-> "mimeTypeFound"? would match other casing.

> openurljobhandlerinterface.cpp:34
> +
> +OpenUrlJobHandlerInterface::~OpenUrlJobHandlerInterface()
> +{

`= default;` instead?

> openurljobhandlerinterface.h:33
> +/**
> + * @brief The OpenUrlJobHandlerInterface class allows OpenUrlJob to
> + * prompt the user about which application to use to open URLs that do not

Please prepend a line

  * @class OpenUrlJobHandlerInterface openurljobhandlerinterface.h 


at the top, to trick doxygen into documenting the full CamelCase include.

> openurljobhandlerinterface.h:54
> + */
> +virtual ~OpenUrlJobHandlerInterface();
> +

override instead?

> openurljobhandlerinterface.h:84
> +private:
> +class Private;
> +Private *const d;

Prevent use of nested Private class here, declare a class 
OpenUrlJobHandlerInterfacePrivate outside, also use QScopedPointer for 
consistency and preparedness in case there ever is an actual object.

> widgetsopenurljobhandler.h:45
> +private:
> +class Private;
> +Private *const d;

Do not use embedded Private class. Also pimp needed here, given not a public 
class?

REPOSITORY
  R241 KIO

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

To: dfaure, ahmadsamir, broulik, meven, kossebau, davidedmundson, nicolasfella, 
svuorela
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29369: Use UI marker context in more tr() calls

2020-05-03 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> aacid wrote in kbookmarkmenu.cpp:288
> @title:inmenu?

Nope, this is a normal action/menu entry, the variable name is misleading here 
a bit. See below e.g. for the slot added.

REPOSITORY
  R294 KBookmarks

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

To: kossebau, #frameworks, #localization
Cc: aacid, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29347: KAuthorized: export method to reload restrictions

2020-05-03 Thread Friedrich W. H. Kossebau
kossebau added inline comments.

INLINE COMMENTS

> kauthorized.cpp:247
>  
> -static void initUrlActionRestrictions()
> +KCONFIGCORE_EXPORT void reloadUrlActionRestrictions()
>  {

Please also add a note next to this that it is for unit test, so people are not 
wondering about this random KCONFIGCORE_EXPORT and first have to research 
commit history.

REPOSITORY
  R237 KConfig

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

To: dfaure, aacid, apol, mdawson
Cc: kossebau, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29370: Use UI marker context in more tr() calls

2020-05-02 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, Localization, broulik.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REPOSITORY
  R289 KNotifications

BRANCH
  usemoreuicontextmarker

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

AFFECTED FILES
  src/kstatusnotifieritem.cpp

To: kossebau, #frameworks, #localization, broulik
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns


D29369: Use UI marker context in more tr() calls

2020-05-02 Thread Friedrich W. H. Kossebau
kossebau created this revision.
kossebau added reviewers: Frameworks, Localization.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
kossebau requested review of this revision.

REVISION SUMMARY
  Also fix lowercase "toolbar" in action text to Title Capitalization

REPOSITORY
  R294 KBookmarks

BRANCH
  usemoreuicontextmarker

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

AFFECTED FILES
  src/kbookmarkcontextmenu.cpp
  src/kbookmarkmenu.cpp
  src/konqbookmarkmenu.cpp

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


  1   2   3   4   5   6   7   8   9   10   >