D26484: Add KIO::DropJobFlag to allow manually showing the menu

kossebau added a comment. And now reported the challenge of drop objects lifetime vs user input on decisions by https://bugreports.qt.io/browse/QTBUG-125229 REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D26484 To: trmdi, #frameworks, davidedmundson, elvisangelaccio,

D26484: Add KIO::DropJobFlag to allow manually showing the menu

kossebau added a comment. Hi. I just came across dropping random data (in my case an image) into file views not working, i.e. not creating any new files due to no more data in the QMimeData instance referred to in the DropJob. Looking into the details, it seems this is due to the flaw

D19557: Update design to look more similar to kde.org

kossebau added inline comments. INLINE COMMENTS > kde-docs.css:252 > +color: white; > +font-height: 3em; > +background: #54a3d8; Seems there is no such CSS property font-height? Was this meant to be e.g. font-size or line-height? REPOSITORY R238 KDocTools REVISION DETAIL

Re: KDE Frameworks with failing CI (master) (19 February 2024)

Am Montag, 19. Februar 2024, 19:36:19 CET schrieb Albert Astals Cid: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for multiple > reasons. > > Good news: 1 repository has been fixed > > Bad news: 1

Re: KDE Frameworks with failing CI (kf5) (4 February 2024)

Am Sonntag, 4. Februar 2024, 13:34:09 CET schrieb Albert Astals Cid: > ki18n - NEW > * https://invent.kde.org/frameworks/ki18n/-/pipelines/598250 > * Linux tests are failing Was found yesterday to be due to iso-codes 4.16 -> https://invent.kde.org/frameworks/ki18n/-/merge_requests/108

Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches

Hi, ((cc:kde-frameworks-devel for heads-up, replies please only to kde-core-deve)) I hit the problem that when working on a repo which would like to use latest KF development state to integrate some new KF API just added in cooperation with that very repo wanting to use it, I cannot do so when

Move krunner also to plasma bundle? (was: Re: plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now)

Am Sonntag, 5. November 2023, 15:32:21 CET schrieb christ...@cullmann.io: > On 2023-11-05 15:11, Nate Graham wrote: > > On 11/5/23 07:09, christ...@cullmann.io wrote: > >> if we are atm moving stuff, might it make sense to move Baloo, too, > >> given it only > >> is usable with the daemon inside

plasma-framework, kactivities and kactivities-stats: please consider proper de-KF-ication now

Hi, with plasma-framework, kactivities and kactivities entering the Plasma product bundle, I assume they also will adapt to Plasma versioning. Without any de-KF-ication though this will break things though for building consumers soonish. Example --- 8< --- find_package(KF6 ${KF_MIN_VERSION}

Re: Breeze and ECM are incompatible for installing icons

Am Donnerstag, 2. November 2023, 14:51:48 CET schrieb Harald Sitter: > https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-lates > t.html > > Each directory contains icons designed for a certain nominal icon size and > > scale, as described by the index.theme file > ... > > >

Re: libkexiv2, libkdcraw (Re: Collection of packaging notes)

Am Mittwoch, 1. November 2023, 13:25:42 CET schrieb Friedrich W. H. Kossebau: > Am Mittwoch, 1. November 2023, 11:55:08 CET schrieb Christophe Marin: > > - Non frameworks modules installing libKF*.so > > libkexiv2 (libKF6KExiv2.so) > > Any code ideas for naming it, given ther

Re: Collection of packaging notes

Am Mittwoch, 1. November 2023, 13:30:03 CET schrieb Jonathan Riddell: > One quick question, is naming non-frameworks libKF6foo really a problem we > need to fix? Given all the other issues... What is in a name... usually some semantics. We could also call random libraries libdsafwef or

libkexiv2, libkdcraw (Re: Collection of packaging notes)

Am Mittwoch, 1. November 2023, 11:55:08 CET schrieb Christophe Marin: > With various alpha coming out soon, here are the notes added to my packages > when I started packaging snapshots and still present. Thanks for the report. Everyone: Could we perhaps establish some wiki page where such

Challenge: adding new method overloads when existing consumers use {} with args

Hi, (cc: kde-frameworks-devel for heads-up, please reply to kde-devel only) given a class C with a method foo(A a): --- 8< --- class C { public: void foo(A a); }; --- 8< --- Now you want to add an overload, to serve further use-cases as requested by API consumers: ---

Re: On ECMDeprecationSettings

Am Dienstag, 28. Juni 2022, 13:12:33 CEST schrieb Aleix Pol: > I wonder if it would make sense to have the ECMDeprecationSettings > calls in KDEFrameworkCompilerSettings rather than in each separate > framework in a copy-paste manner. The calls are more-pr-less replacing the current direct

MRs for dropping dead(?) Python bindings generation, scheduled for Feb 26/27

Hi, so no-one has been found so far who is building or even using the Python bindings for KF modules (see also query on distributions ML*), and those with insight consider it not easily unrecoverable by what I understood. * https://mail.kde.org/pipermail/distributions/2022-February/001148.html

Reminder about KDE_COMPILERSETTINGS_LEVEL (was: Re: Requiring ECM 5.85 makes apps stop compiling)

Am Montag, 14. Februar 2022, 16:32:57 CET schrieb Albert Astals Cid: > It introduces code breaking defines, some of them even of questionable > benefit for an application like QT_NO_KEYWORDS > > I don't understand how such a breaking commit was accepted. > > Who is going to fix all the

D7274: Allow to only build the kauth-policy-gen code generator

kossebau added inline comments. Herald added a subscriber: kde-frameworks-devel. INLINE COMMENTS > CMakeLists.txt:91 > > -install(EXPORT KF5AuthTargets DESTINATION "${CMAKECONFIG_INSTALL_DIR}" > +if(TARGET KF5Auth) > +install(EXPORT KF5AuthTargets DESTINATION "${CMAKECONFIG_INSTALL_DIR}"

Dropping dead(?) Python bindings generation code?

Hi, trying to ensure some changes do not break the Python binding generation, I actually tried to activate that, but found at least on current openSUSE TW there seem to be no longer any working dependencies. Also the openSUSE TW packages of the KF modules seem to also be build without

KF 5.91: 24 modules with failing unit tests (Re: Please fix failing unit tests with Windows platform)

Am Montag, 24. Januar 2022, 01:06:40 CET schrieb Friedrich W. H. Kossebau: > Hi, > > since a long time there are lots of failing unit tests across multiple > repositories. Could the Windows platform maintainers/stakeholders please > look soonish into either fixing those tests or p

Re: Please fix failing unit tests with Windows platform

Am Montag, 24. Januar 2022, 01:22:05 CET schrieb Albert Astals Cid: > Are you going to propose the same for Linux and FreeBSD where we also have > long running tests that don't succeed and no one bothers to fix them? Yes, if a test is known to fail, and no solution is known, it should be tagged

Please fix failing unit tests with Windows platform

Hi, since a long time there are lots of failing unit tests across multiple repositories. Could the Windows platform maintainers/stakeholders please look soonish into either fixing those tests or properly marking them as expected to fail, so the resources the KDE CI spends on running the tests

Maintainers of KDE Frameworks for the Windows platform?

Hi, in the past it was hard to find someone to fix things for KDE Frameworks on Windows, and too often people not interested in Windows had instead to spend their costly leisure time to solve problems, e.g. by debugging via CI runs. I do not think we can expect from every contributor/patch

Gitlab CI: failed unit tests vs. currently passing CI

Hi, seems that Gitlab CI is currently configured to show the green "Success" checkmark for pipeline runs even if unit tests are failing. Reasons seems to be that there Gitlab only knows Yay or Nay, without the warning state level known from Jenkins. And given that quite some projects (sadly)

Includes (was: Re: KF6 meeting notes 2022-01-04)

Am Dienstag, 4. Januar 2022, 18:07:45 CET schrieb Volker Krause: > - in some places includes with the framework prefix don't seem to work > anymore (ie. vs ), any idea where those extra > include directories came from/got lost? FTR, pointed on irc to some insights about design of include folder

D7700: Show list of tags in PlacesView

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!

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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)

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)

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)

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)

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

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

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

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)

(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

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

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

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

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

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

(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

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

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

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

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

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

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

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

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

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)

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

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

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

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)

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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

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

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

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

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

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

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.

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.

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

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

  1   2   3   4   5   6   7   8   9   10   >