D7700: Show list of tags in PlacesView

2021-11-24 Thread Friedrich W. H. Kossebau
kossebau added inline comments. INLINE COMMENTS > kfileplacesitem.cpp:351 > +{ > +KBookmark bookmark = createSystemBookmark(manager, tag, tag, > QUrl(QStringLiteral("tags:/") + tag), QStringLiteral("tag")); > +bookmark.setMetaDataItem(QStringLiteral("tag"), tag); @nicolasfella Hi. this

Re: Fwd: KDE CI: Administration » Dependency Build Applications kf5-qt5 FreeBSDQt5.15 - Build # 127 - Still Failing!

2021-11-18 Thread Friedrich W. H. Kossebau
Am Donnerstag, 18. November 2021, 18:37:37 CET schrieb Volker Krause: > I looked into this and it seems the problem had already been addressed prior > to your email, so all I ended up doing is pressing the rebuild button. > > > The change starting this was

Making Grantlee a KF5 Framework, take 2

2021-10-05 Thread Friedrich W. H. Kossebau
Hi (especially those who would be in contact with Stephen, see end). OLD PLANS REVISITED The old plan was to turn the two libraries part of Grantlee (main one being for text templating, second one for markup generation, see grantlee.org) into KF modules in time for KF6. With KF6 still some

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

2021-09-16 Thread Friedrich W. H. Kossebau
kossebau added a comment. In D19565#678804 , @alex wrote: > However the option seems pretty unused, even from a github search: https://github.com/search?q=HeaderExtension%3D+extension%3Akcfgc=Code=advsearch== In comparison to how many

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

2021-09-16 Thread Friedrich W. H. Kossebau
kossebau added a comment. In D19565#678799 , @alex wrote: > I am wondering if there is really a need for it. SourceExtension seems completely unused and HeaderExtension is only used in okteta. > > Though in KDE code, Qt code (and most other

Re: KApiDox move from dedicated server to Jenkins

2021-09-10 Thread Friedrich W. H. Kossebau
Am Freitag, 10. September 2021, 19:23:47 CEST schrieb Frederik Schwarzer: > Hi, > > we have been working on getting KApiDox to run on Jenkins. This work has > been taken way longer than I expected but has now reached a state close > to finished. :) Congrats on moving forwards, thanks for the

Re: KF API Documentation proposed, small, addition

2021-09-09 Thread Friedrich W. H. Kossebau
Am Donnerstag, 9. September 2021, 23:23:29 CEST schrieb Ahmad Samir: > On 09/09/2021 22:47, Friedrich W. H. Kossebau wrote: > > Am Donnerstag, 9. September 2021, 22:35:05 CEST schrieb Ahmad Samir: > >> On 09/09/2021 22:24, Friedrich W. H. Kossebau wrote: > >>> Am Don

Re: KF API Documentation proposed, small, addition

2021-09-09 Thread Friedrich W. H. Kossebau
Am Donnerstag, 9. September 2021, 22:35:05 CEST schrieb Ahmad Samir: > On 09/09/2021 22:24, Friedrich W. H. Kossebau wrote: > > Am Donnerstag, 9. September 2021, 21:45:33 CEST schrieb Ahmad Samir: > >> On 30/08/2021 16:35, Friedrich W. H. Kossebau wrote: > >>>

Re: KF API Documentation proposed, small, addition

2021-09-09 Thread Friedrich W. H. Kossebau
Am Donnerstag, 9. September 2021, 21:45:33 CEST schrieb Ahmad Samir: > On 30/08/2021 16:35, Friedrich W. H. Kossebau wrote: > > Thanks for pushing this here. > > > > Am Montag, 30. August 2021, 14:17:42 CEST schrieb Ahmad Samir: > > Open question: > > in whic

When to use "code"-style for code expressions in API docs? (was: Re: KF API Documentation proposed, small, addition)

2021-08-30 Thread Friedrich W. H. Kossebau
Thanks for pushing this here. Am Montag, 30. August 2021, 14:17:42 CEST schrieb Ahmad Samir: > I would like to add the following to: > https://community.kde.org/Frameworks/Frameworks_Documentation_Policy#Documen > t_the_Classes > > > One can use [https://www.doxygen.nl/manual/commands.html

Re: Raising KF5 version a bit earlier

2021-07-24 Thread Friedrich W. H. Kossebau
Am Samstag, 24. Juli 2021, 13:58:56 CEST schrieb Aleix Pol: > Hi, > Would it be possible to get the version bump in master a bit earlier in > this cycle? > https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/2a39f0b235c24 > 2592ae6658f33e7fc7b547f8c6d Please note that the bump of the

Re: Porting notes / deprecation docs

2021-07-13 Thread Friedrich W. H. Kossebau
Am Dienstag, 13. Juli 2021, 18:46:35 CEST schrieb Frederik Schwarzer: > On 7/12/21 8:43 PM, Friedrich W. H. Kossebau wrote: > > IIRC main file of the generation is > > https://invent.kde.org/websites/quality-kde-org/-/blob/master/apidox/src/ > > gendox.sh > > > >

Re: Porting notes / deprecation docs

2021-07-12 Thread Friedrich W. H. Kossebau
Am Montag, 12. Juli 2021, 20:22:30 CEST schrieb Frederik Schwarzer: > On 7/12/21 7:38 PM, Friedrich W. H. Kossebau wrote: > > Now what is meant by "clickable links to replacements" exactly? Any > > example > > for what you have in mind? > > (Just in case, Dox

Re: Porting notes / deprecation docs

2021-07-12 Thread Friedrich W. H. Kossebau
Some hopefully helpful quick comments from couch: Am Montag, 12. Juli 2021, 19:14:17 CEST schrieb Frederik Schwarzer: > - If not documented separately, should existing deprecation messages >be improved? "no known users" might not be enough for the "unknown >users" in 3rd-party

Re: Porting notes / deprecation docs

2021-07-10 Thread Friedrich W. H. Kossebau
Am Samstag, 10. Juli 2021, 22:47:58 CEST schrieb Frederik Schwarzer: > Hi, > > On 7/10/21 7:38 PM, Friedrich W. H. Kossebau wrote: > > Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: > >> as mentioned earlier > > > > Any pointers? :) >

Re: Porting notes / deprecation docs

2021-07-10 Thread Friedrich W. H. Kossebau
Am Samstag, 10. Juli 2021, 18:00:13 CEST schrieb Frederik Schwarzer: > as mentioned earlier Any pointers? :) > I would like to document classes/methods/etc that > are going to be deprecated during KF6 development. Can you help confused-on-first-read people by explaining what "deprecated during

Proposal: branch ECM into ECM6 for KF6

2021-07-05 Thread Friedrich W. H. Kossebau
Hi, during the discussion of the MR for a KDEInstallDirs6 variant I learned that there is no clear idea yet how ECM should be be released once there are both KF5 and KF6. And more, it seems so far for ECM there is no version-branch planned, but instead would it have to support both Qt5/KF5 and

Mentioning the required standard in API docs (was: Re: KF5 modules development branches now build in C++17 mode)

2021-06-20 Thread Friedrich W. H. Kossebau
Am Sonntag, 20. Juni 2021, 12:16:33 CEST schrieb Friedrich W. H. Kossebau: > As KF5 promises ABI & source backwards-compatibility for the KF5 series to > its consumers, public KF headers need to stay compatible with projects > using C++11 (or C++14). > So in public headers C++17 f

KF5 modules development branches now build in C++17 mode (but keep public headers compatible)

2021-06-20 Thread Friedrich W. H. Kossebau
Hi, small heads-up for everyone: as of yesterday, KDEFrameworksCompilerSettings from current ECM development branch now sets set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED TRUE) for all KF modules (triggered by required ECM 5.84.0 version, which was also bumped yesterday in

Re: Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)

2021-06-05 Thread Friedrich W. H. Kossebau
Am Samstag, 5. Juni 2021, 22:39:15 CEST schrieb Alexander Lohnau: > Or could we use the BUILD_DEPRECATED_SINCE variant in this case? Like we > already have to do with virtual methods. > > This way one would still be able to test it when compiling the framework > without deprecations. Existing API

Deprecation wrappers for pre-KF6 time (was: Re: KF6 meeting notes 2021-06-05)

2021-06-05 Thread Friedrich W. H. Kossebau
Am Samstag, 5. Juni 2021, 16:29:10 CEST schrieb Volker Krause: > Deprecation wrappers macros: > - should those also be added for things that have no replacement yet, or > where the replacement will only become available for KF6? > - trader queries is one such example

Re: Numerous build regressions

2021-04-25 Thread Friedrich W. H. Kossebau
Am Sonntag, 25. April 2021, 15:36:37 CEST schrieb Friedrich W. H. Kossebau: > Am Sonntag, 25. April 2021, 14:18:29 CEST schrieb Friedrich W. H. Kossebau: > > Am Sonntag, 25. April 2021, 09:56:17 CEST schrieb Ben Cooksley: > > > These failures appear to be due to changes to

Re: Numerous build regressions

2021-04-25 Thread Friedrich W. H. Kossebau
Am Sonntag, 25. April 2021, 14:18:29 CEST schrieb Friedrich W. H. Kossebau: > Am Sonntag, 25. April 2021, 09:56:17 CEST schrieb Ben Cooksley: > > These failures appear to be due to changes to the export header templates > > in extra-cmake-modules, and some SSL related f

Re: Numerous build regressions

2021-04-25 Thread Friedrich W. H. Kossebau
Am Sonntag, 25. April 2021, 09:56:17 CEST schrieb Ben Cooksley: > These failures appear to be due to changes to the export header templates > in extra-cmake-modules, and some SSL related functions in KIO. Looking into the export header related one. Seems that bluez-qt includes the export header

Moving plasma-frameworks & krunner to Plasma release set for *6? (was: Re: KF6 meeting notes 2021-04-17)

2021-04-17 Thread Friedrich W. H. Kossebau
(cc: plasma-devel for heads-up, not subscribed there, please re: only to kfd) Am Samstag, 17. April 2021, 16:11:24 CEST schrieb Luigi Toscano: > Several "needs input" tasks are related to Plasma. > Maybe it would be better to focus on Plasma next time and involve Plasma > people, and find out

Re: Patch for exception.h

2021-03-25 Thread Friedrich W. H. Kossebau
Am Donnerstag, 25. März 2021, 06:59:35 CET schrieb Christian Riggenbach: > >Interesting that you are the first one to hit this in all the years... > >but I > >agree with your fix, is consistent with the other export header > >includes and > >needed, both for the CamelCase forward includes but also

Re: Patch for exception.h

2021-03-24 Thread Friedrich W. H. Kossebau
Hi Christian, Am Mittwoch, 24. März 2021, 20:49:16 CET schrieb Christian Riggenbach: > Hi Threadweaver team > > I found a small error in the source code, which inhibits the inclusion of > in my own program to throw an exception to fail a > job: The include for threadweaver_export.h uses <>

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

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

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 >

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

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

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

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

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

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 re

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

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.

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

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

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

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

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

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 >

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

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,

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

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

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 >

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, th

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

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

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

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

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

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

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().`

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

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,

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

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,

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

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

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,

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.

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

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

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

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

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

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

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

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 > > 972da14f486a83556e192d09bb1

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

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

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?

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

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

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

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

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

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

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

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

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

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,

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()

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

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

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

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

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

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

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

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,

  1   2   3   4   5   6   7   8   9   10   >