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

[Friedrich W. H. Kossebau]

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, mart, dfaure
Cc: kossebau, ngraham, broulik, anthonyfieroni, kde-frameworks-devel, 
LeGast00n, cblack, michaelh, ahmadsamir, bruns, vkrause

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

[Friedrich W. H. Kossebau]

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 of KIO::DropJob 
being async, but the QDropEvent (which got a respective comment) and even more 
the QMimeData it exposes (which has no comment, but just a helpless QPointer 
wrapper) is not defined to outlive the QWidget drop event handler call. And 
both at least X11 and Wayland protocol seems to negotiate things by the drop 
serving instance only offering a list of MIME types, next to the copy or move 
action, and only on the reply of the drop consumer actually deliver the data of 
the selected MIME type.
  
  My naive reaction to this would be to use some QEventLoop inside KIO::drop() 
for the user interaction to query "Copy or Move" and "Which format?", then 
extract the very data from the QMimeData, before returning to the Qt drop event 
handler call from which KIO::drop() would be called.
  
  But the method added here, DropJob::showMenu() and their usage would not be 
fixed by this. Anyone around still involved with this who could work on this 
from their use case POV? Or at least give some thoughts on this?

REPOSITORY
  R241 KIO

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

To: trmdi, #frameworks, davidedmundson, elvisangelaccio, mart, dfaure
Cc: kossebau, ngraham, broulik, anthonyfieroni, kde-frameworks-devel, 
LeGast00n, cblack, michaelh, ahmadsamir, bruns, vkrause

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

[Friedrich W. H. Kossebau]

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
  https://phabricator.kde.org/D19557

To: ognarb, #vdg, #documentation, yurchor, ltoscano
Cc: kossebau, yurchor, rooty, ltoscano, bruns, abetts, broulik, aacid, 
kde-frameworks-devel, kde-doc-english, LeGast00n, cblack, gennad, fbampaloukas, 
michaelh, ahmadsamir, ngraham, skadinna, vkrause

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

[Friedrich W. H. Kossebau]

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 NEW repository is failing
> 
> 
> kconfig - NEW
>  * https://invent.kde.org/frameworks/kconfig/-/pipelines/611171
>   * kconfigcore-kconfigtest is failing on Windows

Not new, but flaky test. See for a theory on the cause the comment here:
https://invent.kde.org/frameworks/kconfig/-/merge_requests/219#note_854124
(filesystem timestamps too granular for memory cache invalidation during test) 

Still needs someone tackling this, not yet got myself to sit down over it and 
might not soonish sadly.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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
(candidate for KF5 backport also, to fix the same there)

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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 someone had added a 
flatpak job on CI to that repo.

Because with such flatpak jobs it seems they are limiting the available KF 
version not to the current latest one, as expected for continuous integration, 
but some older (anywhere documented?) snapshot:

"runtime-version": "6.6-kf6preview",

What can be done here to reestablish the old immediate continuous integration 
workflow? Where new APIs (also from KF) are instantly available?

Right now this is a new extra burden which makes working on new features with 
KF and apps more complicated. Thus less interesting, and one/I would rather 
duplicate code in apps to get things done.

Blocking latest KF API from usage also means less testing of that before the 
initial release.

Besides all the resource costs to create flatpaks on master builds by default 
every time, when those are usually not used by anyone anyway.

So, how to solve those problems? Did I miss something?
Could flatpak builds on master branches be made on-demand rather?

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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 more or less, too?
> >> 
> >> Greetings
> >> Christoph
> > 
> > Baloo is linked by some apps, e.g. Elisa, and I wouldn't like to make
> > them haul in Plasma stuff.
> 
> Hi,
> 
> some applications link to kactivities, too.
> I think it just makes it more clear that this will just work with
> Plasma.
> 
> But I can live with the status quo, too, just thought it would be
> cleaner.

While at it:

would KRunner not also be a good candidate to bundle with Plasma instead of 
KF?  (to repeat some old record :P)

AFAIK the only programs hosting KRunner plugins are Plasma ones, everyone else 
just provides plugins. So similar to Plasma-Frameworks.

Bundling KRunner libraries with Plasma would allow to develop the search/query 
system in-sync, and plugin developers would just expect the plugin API to be 
stable.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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} REQUIRED COMPONENTS
CoreAddons
Plasma
)
--- 8< ---

* KF6_VERSION will be set by FindKF6.cmake to min component version, so that 
of KF6Plasma
* when setting KF_MIN_VERSION one will only think about KF versions, not 
Plasma versions

Asking people to always know about that trap and remember to always only do 
e.g.
--- 8< ---
find_package(KF6CoreAddons ${KF_MIN_VERSION} REQUIRED)
find_package(KF6Plasma ${PLASMA_MIN_VERSION} REQUIRED)
--- 8< ---
yields rather strange pattern code.

Or think of things like libcolorcorrect/LibColorCorrectConfig.cmake.in:

--- 8< ---
find_dependency(KF6Plasma "@KF6_MIN_VERSION@")
--- 8< ---

Looks fine on first sight, does it? Just, no longer is now.

So not best developer experience here.

Thus, to make it clear to everyone that those 3 libraries are now from another 
product bundle, with own versioning and other own rules, please do not forget 
to adapt
* naming: library names, CMake package names, CMake target names
* version variable setting (PLASMA_MIN_VERSION needed now in consumers)
* documentation: metainfo.yaml entries, references to KDE Frameworks

And yes, while at it some other Plasma bundle things might want to be unmessy 
here as well, e.g. libkscreen :) 

Cheers
Friedrich

Re: Breeze and ECM are incompatible for installing icons

[Friedrich W. H. Kossebau]

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
> ...
> 
> > list of subdirectories for this theme. For every subdirectory there must
> > be a section in the index.theme file describing that directory.
> Just my 2 cents, but since the specification specifically allows theme
> authors to do whatever, if ECM doesn't support that then ECM appears
> not spec compliant.

ECM though can only know about the actual layout at a given time, and create 
install rules for the build system based on that, which then result in the 
path as used by the package created at the time.

If an icon theme at some point in time decides to change its internal dir 
layout, any 3rd-party icons will suddenly be installed at the wrong place.

ECM needs to know about the internal dir layout -> needs to be able to access 
the actual theme desktop file and extract the info.

Packages need to have dependencies on the internal dir layout. So if an icon 
theme changes in an incompatible way, packages need to be rebuild, to install 
theme icons to the new places.

Time for a public icon theme application-installing-interface version with 
each icon theme? :P

Alternatively icon themes might need to support looking up icons also in some 
specified standard way, next to their custom one... needs people who have fun 
working on specs and ensuring its support by stakeholders :)

Some more 2 cents, from my couch :)
Friedrich

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

[Friedrich W. H. Kossebau]

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 there is already a number suffix, coming
> from the library that is wrapped?
> 
> Similar need also for libkomparediff2, where the 2 is referring to diffing 2
> things, not a version number.

MR: https://invent.kde.org/graphics/libkexiv2/-/merge_requests/25
 
> > libkdcraw (libKF6KDcraw.so)
> 
> I have an old patch locally somehow never finished, will brush up as MR
> tonight hopefully. (promised in https://invent.kde.org/graphics/libkdcraw/-/
> merge_requests/9#note_646025 )

MR: https://invent.kde.org/graphics/libkdcraw/-/merge_requests/12

Both with list of further MRs to adapt known-to-me consumers

Cheers
Friedrich

Re: Collection of packaging notes

[Friedrich W. H. Kossebau]

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 libPlasmaFoo (while 
unrelated to Plasma), would that be a good idea?

If not, then why not fix any misnaming while we change names anyway.

Cheers
Friedrich

libkexiv2, libkdcraw (Re: Collection of packaging notes)

[Friedrich W. H. Kossebau]

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 things could be tracked?
 
> - Non frameworks modules installing libKF*.so
> libkexiv2 (libKF6KExiv2.so)

Any code ideas for naming it, given there is already a number suffix, coming 
from the library that is wrapped?

Similar need also for libkomparediff2, where the 2 is referring to diffing 2 
things, not a version number.

> libkdcraw (libKF6KDcraw.so)

I have an old patch locally somehow never finished, will brush up as MR 
tonight hopefully. (promised in https://invent.kde.org/graphics/libkdcraw/-/
merge_requests/9#note_646025 )

Cheers
Frriedrich

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

[Friedrich W. H. Kossebau]

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:
--- 8< ---
void foo(B b);
--- 8< ---


But there is existing consumer code, making use of C++17, which calls
--- 8< ---
C c;
c.foo({});
--- 8< ---

So the new overload will not be source-compatible and break existing code, for 
what my WE mood brain tells me.

Which spoils the API evolving we have been doing so far e.g. in KDE Frameworks 
quite a bit. 
So far we seem to just have been lucky, but with more consumer code starting 
to make use of C++17 features, the risk has grown and I just ran into this the 
first time -> https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/
e425aaa3025272cb70169354d04dfb3713f9783a#note_491339

Had not yet thought about this challenge myself before, so curious what people 
think can be done here?

Should perhaps the use of list-initializers with arguments in method calls be 
discouraged, at least for plain {} ones, where no type information is provided 
at all?

Cheers
Friedrich

Re: On ECMDeprecationSettings

[Friedrich W. H. Kossebau]

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 add_definitions calls 
with nicer-to-human calls using the new macro. So the principle of all the 
repeated instructions is as before (module the now needed extra 
ECMDeprecationSettings include. No change there.

I had also pondered whether things could be deduplicated somehow while 
touching things, but my thoughts against are:

a) While settings in many modules are the same, often they are not. And at 
least one module needs lower Qt visibility level, supporting that exception 
needs extra code which adds complexity (and we lack cmake coders in KDE, just 
got a reply today what translated to me as "too lazy to write proper cmake 
code", no idea how to social-engineer people here).

b) Upgrading the min levels is a thing which needs investigation module-by-
module. Requiring the persons doing the level bump to have to handle all the 
dozens KF modules in one go will be a task too few have time slots for I 
guess, so no-one might do that. Allowing to bump individually allows to 
distribute the work by time & persons.

In general, when it comes to deduplication in CMake code of KDE Frameworks 
modules, there is big potential in many places, so many patterns which are now 
stable and which could be reduced into CMake macros for simple developer-
facing KF cmake code. But no time and energy myself here currently.

For this deprecation handling setting alone, at least I have no good idea how 
to simplify without adding cost at other places, like above mentioned. But 
others might, so please share your ideas.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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

Thus there is now a set of MR prepared to remove the dead cmake code for that, 
getting rid of unused log messages and code that is bitrotting.
Proposed would be to merge it upcoming WE (Feb 26th/27th), so there is a last 
chance of a week for anyone to speak up to rescue things, but also another 
week before the tagging:

https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/198
https://invent.kde.org/frameworks/kauth/-/merge_requests/22
https://invent.kde.org/frameworks/kcodecs/-/merge_requests/15
https://invent.kde.org/frameworks/kcompletion/-/merge_requests/24
https://invent.kde.org/frameworks/kconfig/-/merge_requests/112
https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/105
https://invent.kde.org/frameworks/kdbusaddons/-/merge_requests/20
https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/48
https://invent.kde.org/frameworks/ki18n/-/merge_requests/47
https://invent.kde.org/frameworks/kitemmodels/-/merge_requests/34
https://invent.kde.org/frameworks/kitemviews/-/merge_requests/8
https://invent.kde.org/frameworks/kjobwidgets/-/merge_requests/17
https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/116

If I hear no objections, would merge all those in 7 days.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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 applications in KDE to build after that?
> 
> Apps that I've tried and failed:
>  * okular
>  * kdenlive
>  * konsole
>  * ktuberling
>  * kgeography
> 
> And i stopped tried because i was getting super sad nothing was compiling.
> 
> What is the suggested solution for this? Because I don't think it makes
> sense to burn hundreds of hours just replacing signal to Q_SIGNAL and
> wrapping all the strings ever in QStringLiteral and QLatin1Char.
> 
> Never require a modern ECM?
> 
> unset those defines again from the application side?
> 
> Something else?

Sorry to see you running into this, seems some time has passed and this 
vanished from people#s memory. Guess we should have send not one, but a few 
reminder emails about the new mechanims introduced at ECM 5.85.0.

TL;DR Please use 
set(KDE_COMPILERSETTINGS_LEVEL 5.84.0)
before
include(KDECompilerSettings NO_POLICY_SCOPE)

For more details see
https://marc.info/?l=kde-devel&m=162893561025502&w=2
as well as
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/144

That approach was the best people could come up at the time to allow 
introducing new requirements. 

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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

This installs KF5AuthTargets.cmake based on the condition, but 
KF5AuthConfig.cmake still includes the target file unconditionally, so cmake 
would fail over missing the file when using find_package(KF5Auth).

So are the cmake files  not used in the case to support here at all, and all of 
the cmake config handling should be wrapped?

REPOSITORY
  R283 KAuth

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

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

Dropping dead(?) Python bindings generation code?

[Friedrich W. H. Kossebau]

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 bindings, for the 
samples I checked.

Then I found that on both gitlab & jenkins CI the binding generation is also 
skipt (at least for KCoreAddons on all platforms, but seems also everywhere 
else). 
Some related commit removing the support talks about "deterministic" builds 
though:
https://invent.kde.org/sysadmin/ci-tooling/-/commit/
6a92fdf747990d2e074e92b2bdc224efc9b08740

Then on #kde-devel I was told that"pyqt5 5.15.6 + sip4" do no more go 
together, referencing 
https://www.riverbankcomputing.com/pipermail/pyqt/2021-November/044346.html:
> It wasn't an intentional breakage but it's not something I'm going to rush 
to fix.

Who feels in charge of the Python binding support? Is there a chance someone 
will work on this soonish? 

Or could we drop it now, and save everyone the cmake warning messages they 
cannot fix and also the bad feeling to change things that might break binding 
generation support even further?

It was suggested that "the only reasonable way forward it to port to modern 
sip" "but that requires an almost full rewrite".
Which sounds as if any future system will need a rework of ECM's 
PythonModuleGeneration as well, thus keeping the current CMake code in KF 
modules around in chance they might get used again as they are in the future 
would not make sense.

Reference removal of the Python binding generation support up as
https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/198
to serve as example for the discussion.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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 properly marking them as
> expected to fail, so the resources the KDE CI spends on running the tests
> every hour, day and week make some sense again, as well as having something
> usable to diff results again, to notice any new regressions?
> 
> Please see
>  
> https://build.kde.org/job/Frameworks/view/Platform%20-%20WindowsMSVCQt5.15/
> (best sort by "S" build status to get a list what need

And those who believe in the broken windows theory also would claim this 
slacking now resulted in the regressions in the openSUSE builds, where 5 
modules now have failing unit tests at time of release tagging, when it once 
was 0 thanks to hard work of David F. and others. :(

Is it time to remove 
https://community.kde.org/Frameworks/
Policies#Frameworks_CI_failures_are_treated_as_stop_the_line_events
because seemingly this is just old dead pixels on a web page and not the 
spirit these days?

Friedrich

Re: Please fix failing unit tests with Windows platform

[Friedrich W. H. Kossebau]

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 
as EXPECT_TO_FAIL. Is there would be projects that do not do that (e.g. if the 
maintainer only cares for Windows, to turn things around), for those platforms 
where tests keep failing eternally unhandled we should drop the claim of 
support (and wasting CI resources).

Cheers
Friedrich

Please fix failing unit tests with Windows platform

[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 properly marking them as expected to 
fail, so the resources the KDE CI spends on running the tests every hour, day 
and week make some sense again, as well as having something usable to diff 
results again, to notice any new regressions?

Please see
  https://build.kde.org/job/Frameworks/view/Platform%20-%20WindowsMSVCQt5.15/ 
(best sort by "S" build status to get a list what need

Otherwise I would tend to propose to declare Windows support as unmaintained, 
if there is no change within the next weeks.

Thanks in advance
Friedrich

Maintainers of KDE Frameworks for the Windows platform?

[Friedrich W. H. Kossebau]

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 author they are 
capable to understand and to solve things on all platforms. For one as this 
does not scale, and even more when the platform is a proprietary one that 
otherwise works against the mission of KDE and people rather avoid to have to 
know about it.

So we need dedicated maintainer teams for each platform IMHO. And if that team 
is empty, have to drop the official support for that platform, instead of e.g. 
having it a "broken windows theory" thing on CI (pun intended).

Given Linux (default, all the usual suspect contributors), FreeBSD (Tobias, 
Adriaan), and Android (some other usual suspect contributors) are covered, 
there is a reaction time the same day often, when help is needed with those. 
Other than for Windows (and macOS once it makes it to CI).

Who would be available as contact person for KF @ Windows, so could be 
reliably called in to solve code issues appearing in new work or regressions 
by external influences? Either by a to be created @teams tag or as highly 
available individuals?

If we do not have enough people who can provide at least, say, weekly work on 
the Windows platform, I would propose to drop the official support, as it is 
an annoying burden to those who have no stakes on that platform.
And also harms the reputation of the KF product, because being badly 
maintained and thus partially broken makes it into the developer/user 
experience on those platforms, which then is mapped onto the whole product 
(rightfully), not just the support on that platform.

Cheers
Friedrich

Gitlab CI: failed unit tests vs. currently passing CI

[Friedrich W. H. Kossebau]

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) maintain a few long-time failing 
unit tests, having the pipeline fail on unit tests seems to have been seen as 
too aggressive 

This of course harms the purpose of the unit tests, when their failures are 
only noticed weeks later, not e.g. at MR discussion time.

Seeing how at least in KDE Frameworks first regressions sneaked in without 
someone noticing (nobody looks at logs when the surface shows a green 
checkmark, e.g. kcoreaddons, kwidgetsaddons, kio, purpose, krunner on openSUSE 
and possibly more have regressed in recent weeks, see build.kde.org) this 
should be something to deal with better, right?

Bhushan gave two first ideas just now on #kde-sysadmin:
> Well we can add a switch that repos can commit to saying test failure is 
build failure
> Another alternative is we use bot to write a comment on MR

IMHO, to give unit tests the purpose they have, we should by default to let 
test failures be build failures. And have projects opt out if they need to 
have some unit tests keep failing, instead of e.g. tagging them with expected 
failures or handling any special environment they run into on the CI.

Your opinions?

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

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 layout 
noted in an older comment here:
https://invent.kde.org/pim/akonadi/-/merge_requests/70#note_300273

And follow-up on what makes path relative to "include/KF5" work:
https://invent.kde.org/pim/akonadi/-/merge_requests/70#note_300304

Seems at least the version files as currently installed do not match the 
pattern as described above, but that might have been just a mistake which 
happened to work, so no-one noticed.
Installing kfoo_version.h instead of to include/KF5 to include/KF5/KFoo should 
still work as before., at least for anything which reads include paths from 
installed metadata like cmake config files, pkgconfig files or qmake pri 
files.

The currently by KF5 modules provided pkgconfig files or qmake pri files seem 
to even never add "include/KF5" in the samples I looked at, so any #include 
 would have never worked with them.

So I would propose to fix things and adapt the version files to be installed 
into the module prefix now already. Any serious project should get the include 
paths from the build metadata and not try to heuristically find version 
headers and try to heuristically detect the version from that.

Cheeers
Friedrich

D7700: Show list of tags in PlacesView

[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 is passing the tag string both as translation context as 
well as the string to translate as well. Is this on purpose? Even more as the 
context parameter is ignored anyway and just there to force a context for the 
other cases being used with I18NC_NOOP values, to make sure a context is set at 
all.

So where are those tag names coming from, are they expected to be translated at 
all?

REPOSITORY
  R241 KIO

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

To: nicolasfella, #dolphin, #kde_applications, alexeymin, ngraham, broulik
Cc: kossebau, chehrlic, broulik, kde-frameworks-devel, bruns, rkflx, mmustac, 
spoorun, michaelh, renatoo, anthonyfieroni, cfeck, elvisangelaccio, emmanuelp, 
ngraham, alexeymin, #dolphin, sdorishlab, badbunny, waitquietly, azyx, 
nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, koehn, cblack, 
fbampaloukas, alexde, Codezela, feverfew, meven, ahmadsamir, navarromorales, 
firef, andrebarros, rdieter, mikesomov, vkrause

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

[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 https://invent.kde.org/frameworks/ki18n/-/
> merge_requests/21, by me. What actually caused the breakage however was the
> way deprecation versions are managed. Not the first time, and not entirely
> surprising, the MR comments even mention that risk.
> 
> There's two approaches on how to handle such changes without breaking the
> build:
> 
> (1) Change KF, port apps after the next KF release, deprecate old KF API in
> a subsequent release once porting has been completed.
> (2) Change KF and deprecate old API immediately, port apps after the next KF
> release and then bump the deprecation version once that has been completed.
> 
> Both have been rejected previously and I have yet to see an alternative
> workflow that allows KF changes/deprecation while avoiding breakage like we
> have seen here. I very much share your frustration in that regard.

The problem is rather the (on purpose) too aggressive setting of the 
visibility levels in PIM projects. See also the thread recently here:
https://mail.kde.org/pipermail/kde-pim/2021-August/047845.html

(So as Albert said while I was typing :) )

It is part of the workflow of one big contributor, but sadly has those 
negative side-effects for everyone else. In the absence of someone else having 
found a solution meanwhile, I will see to finally complete this WE my 
technical proposal to this conflict, as sketched at the end of
https://mail.kde.org/pipermail/kde-pim/2021-August/047914.html

Cheers
Friedrich

Making Grantlee a KF5 Framework, take 2

[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 decent time away, and Grantlee upstream with stalled 
development (even seeing forks already), it might be better to execute the 
KFying plans already now. And by that also shift some workload from the Qt5/
Qt6 port time away to now.


WORKING KF5 VARIANT ALREADY PREPARED, INCLUDING CONSUMER PATCHES

While so far we have yet to manage to reach Stephen to see him agree on and 
bless the new plan, work has been done to prepare a KF5 variant of Grantlee 
meanwhile, tracked in this task:
https://phabricator.kde.org/T14887

The current result is:
* a working KF5 module variant of Grantlee (mainly missing code reformat and 
SPDX headers, but already prepared separately)
* working patches for all known users of Grantlee in KDE (as well as Kraft as 
another known user in the outer spheres).
See the linked task above for the KFGrantlee repo and the patches to the 
consumers.

So basically prepared, just missing out on complete licenses and name 
transfer. Modulo further review by KF developers of course :)


KF 5.88 WOULD BE A WELCOME TARGET

In a perfect world we could add the text templating library of Grantlee as a 
KF module for KF 5.88 begin of November (the markup generation would be solved 
differently, as fork for now in the only left consumer kjots, see task for 
details).
This would allow to switch the majority of Grantlee consumers, 10, which are 
part of KDE Gear, without #if#else to KF Grantlee for KDE Gear 21.12. While 
seeing to have the other 3 either have a patch release before with build 
support added or provide distributions with patches for that. So the 
distributions can switch all the packages to use KFGrantlee at the same time, 
no need to juggle two variants of the same library at the same time.

Now KF 5.88 tagging is just less than 5 weeks away, so this might appear a bit 
rushed. But it is also a small window of opportunity, with developers around 
with attention to the matter, and where things could be aligned. And after all 
the codebase is pretty mature after all the years, and the recent 
modernization patches should not have had much of a negative impact. So giving 
it a try.

Otherwise I would propose KF 5.89 in December as a target and ask for allowing 
KDE Gear 21.12 to dependent on that, even if released just a few days later by 
current schedules.


CONTACT TO STEPHEN  NEEDED, IDEALLY NOW

As Stephen already pointed out as reason in the original proposal, other 
interesting things in life have taken over his resources and focus. Yet we 
need his input for two things, so for that we need someone who could interest 
him to spend some 10 more minutes on his former, so important to us, work :) :

a) Review and merge this prepared commit in his authorship which adds missing 
license headers to some files:
https://github.com/steveire/grantlee/pull/75
b) State by an email to kde-core-de...@kde.org or kde-frameworks-devel@kde.org 
he is fine with us taking over the name Grantlee for the new KF variant of the 
library, as official successor of his work.

In case please consider to share personal details by PM with me, let's keep 
private things private :) Otherwise any help very welcome to resolve these two 
blockers.

Cheers
Friedrich

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

[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&type=Code&ref=advsearch&l=&l=
  
  
  In comparison to how many non KDE users of kconfigcompiler? ;) Also is github 
only giving a partial view of the world with htose fine with MS GitHub or 
having put their code in public anyway. After all KF is LGPL, to allow 
in-house/proprietary use. And those often have their subcultures using their 
own peferred suffices, I found :) ).
  
  >> KF targets also consumers outside of KDE spheres
  > 
  > Also I think there are currently quite a lot of kcfgc options, which makes 
is more difficult to work with IMHO. That might also be more true for third 
party users which are not very familiar with the API.
  
  Can you report any who were confused by those rather straightforward options? 
I would expect almost all are not challenged by those bits, removing them 
should not imrpive their experience a lot. Do we have reports/research?
  
  > Though from having a quick look it seems like (pretty much all) of those 
headers are not using any of KDE/Qt libs. Which means that they would not be a 
very likely audience anyways.
  
  I was giving you examples of what C++ developers use. And it's C++ developer 
who are the primary target of our libraries, as everyone else has a hard time 
due to no real bindings.
  
  > If we want to attract our frameworks to more users, making them slimmer is 
also a possibility one needs to consider.
  
  I would not agree that cutting features and reducing flexibility makes things 
more attractive to others. Rather the opposite. Why using a primitive solution 
that only partially fits when one can instead do a home-grown perfect fit with 
full control...

REPOSITORY
  R237 KConfig

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

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

D19565: kconfig_compiler: new kcfgc args HeaderExtension & SourceExtension

[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 that I know of) it is the ".h" 
extension is the most common one for headers.
  >
  > Are there any reasons for having it that I am not aware of?
  
  
  KF targets also consumers outside of KDE spheres, which are not bound to 
KDE's suffix tradition/culture (and any need to stay backward-compatible to 
that), so just looking at Qt & KDE is not enough. The world is bigger ;)
  
  Try e.g.`find /usr/include/ -name "*.hxx"` and `find /usr/include/ -name 
"*.hpp"` to see that developers of other projects prefer those suffixes for C++ 
headers.  Using `.h`, so the same suffix as used for C headers, has the 
disadvantage that one cannot tell the type by just the siuffix, and most MIME 
type guessers also fall flat due to not reliable magic bytes.
  
  When it comes to the source suffix, there also are bigger subcultures 
preferring something else than `.cpp`, not sure where the others are coming 
from.
  
  https://en.wikipedia.org/wiki/C++ lists these suffixes being more widely 
used: .C, .cc, .cpp, .cxx, .c++, .h, .H, .hh, .hpp, .hxx, .h++. And while the 
C++ Core guidelines these days recommend .h and .cpp for new-from-scratch 
projects (see 
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-file-suffix) 
they also acknowledge there are other traditions. And there are people who 
think the reasoning for using .h (mixing C and C++) is poor when it comes to 
C++-only headers. and for the before-mentioned reasons having a dedicated own 
suffix for headers would be better.
  
  All in all these flags allows for nicer integration of kocnfigcompiler 
generated code over forcing KDE's current traditions onto others. If you ask 
me, actually more of KDE should switch to use some non-h suffix for headers as 
well where possible, less guess work needed whether a header is C or C++..

REPOSITORY
  R237 KConfig

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

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

Re: KApiDox move from dedicated server to Jenkins

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

Linking to external docs (mainly the Qt ones) seems missing. For that 
respective doxygen tags files need to be added. Qt generates such files during 
the build, so for the current api.kde.org people copied those tags files from 
their distribution's package.

Here I did for updating to Qt 5.15:
https://invent.kde.org/websites/quality-kde-org/-/commit/
8a18c9033751cb41548361aea5c8ba2de3499dd7

with the files found in /usr/share/doc/packages/qt5/*/*.tags, provided by the 
package libqt5-qtdoc-devel on openSUSE TW.

To see how kapidox is instructed about those tags files, as that seems missing 
from its own docs, see the usage example in the current api.kde.org scripts:
https://invent.kde.org/websites/quality-kde-org/-/blob/master/apidox/src/
kapidoxgendox.sh#L33

CHeers
Friedrich

Re: KF API Documentation proposed, small, addition

[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 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 which places is it a good idea to use "code"-style with class names
> >>>>> and
> >>>>> method names? So when does readability suffer by too many changes in
> >>>>> the
> >>>>> formatting in a text body?
> >>>>> 
> >>>>> Looking e.g. at the Qt docs for a reference, they do not use
> >>>>> "code"-style
> >>>>> when referencing classes or methods from text, as well as in the
> >>>>> listing
> >>>>> of classes and methods. So I wonder if this is by design or just
> >>>>> historic?
> >>>> 
> >>>> They use QDoc, IIUC; and it looks like they recommend using \c
> >>>> https://doc.qt.io/qt-5/04-qdoc-commands-textmarkup.html
> >>>> 
> >>>> at least that page suggests so.
> >>> 
> >>> Then our question was not "if" they have a command to markup things to
> >>> be
> >>> printed code-like, but "when" it should be used. And the examples they
> >>> give
> >>> (not sure though if exclusive or inclusive) are
> >>> 
> >>> "
> >>> variable names, user-defined class names, and C++ keywords (for example,
> >>> int and for)
> >>> ".
> >>> 
> >>> So no mention of names of the methods, members, properties and classes
> >>> the
> >>> documentation is about (note the "user-defined"). And looking at the
> >>> existing Qt API documentation, I would guess the given list is rather
> >>> exclusive then, and \c with Qt is not to be used when referencing the
> >>> elements of the documented API itself (at least in flow text).
> >>> 
> >>> Myself I meanwhile rather think that this might be a good choice.
> >>> Imagine
> >>> how e.g. https://doc.qt.io/qt-6/qstring.html would look like if all text
> >>> elements referencing Qt classes or method names would be in code-style.
> >>> I
> >>> guess the reading flow in the flow text blocks would suffer a lot.
> >> 
> >> So one vote for and one vote against, we need a tie-breaker.
> > 
> > What I would like to see are some argument for why you want this change?
> > What is broken now, what does it improve?
> > Can you give an example where your proposal is applied and what the result
> > is, before and after?
> 
> I think it's useful to markup the method names, that makes reading the API
> docs in text format in a header file easier, the same way marking up
> true/false is useful, the same way syntax highlighting in most text editors
> is useful.

I see, that is where you are coming from, it makes some sense there. But...

... it only makes sense for people looking at headers in a plain text editor 
which also is capable of parsing doxygen comments and adding respective 
highlighting.

.. for every other plain text viewers/editors, including on the gitlab file 
viewer, it makes things harder to read.

.. it very possibly lowers the quality of the generated API docs, which should 
be the main purpose of writing those API documentation snippets, no?

So im summary not convinced this would be a change for the better.

Cheers
Friedrich

Re: KF API Documentation proposed, small, addition

[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:
> >>> Thanks for pushing this here.
> >>> 
> >>> Am Montag, 30. August 2021, 14:17:42 CEST schrieb Ahmad Samir:
> >>> Open question:
> >>> in which places is it a good idea to use "code"-style with class names
> >>> and
> >>> method names? So when does readability suffer by too many changes in the
> >>> formatting in a text body?
> >>> 
> >>> Looking e.g. at the Qt docs for a reference, they do not use
> >>> "code"-style
> >>> when referencing classes or methods from text, as well as in the listing
> >>> of classes and methods. So I wonder if this is by design or just
> >>> historic?
> >> 
> >> They use QDoc, IIUC; and it looks like they recommend using \c
> >> https://doc.qt.io/qt-5/04-qdoc-commands-textmarkup.html
> >> 
> >> at least that page suggests so.
> > 
> > Then our question was not "if" they have a command to markup things to be
> > printed code-like, but "when" it should be used. And the examples they
> > give
> > (not sure though if exclusive or inclusive) are
> > 
> > "
> > variable names, user-defined class names, and C++ keywords (for example,
> > int and for)
> > ".
> > 
> > So no mention of names of the methods, members, properties and classes the
> > documentation is about (note the "user-defined"). And looking at the
> > existing Qt API documentation, I would guess the given list is rather
> > exclusive then, and \c with Qt is not to be used when referencing the
> > elements of the documented API itself (at least in flow text).
> > 
> > Myself I meanwhile rather think that this might be a good choice. Imagine
> > how e.g. https://doc.qt.io/qt-6/qstring.html would look like if all text
> > elements referencing Qt classes or method names would be in code-style. I
> > guess the reading flow in the flow text blocks would suffer a lot.
> > 
> 
> So one vote for and one vote against, we need a tie-breaker.

What I would like to see are some argument for why you want this change?
What is broken now, what does it improve?
Can you give an example where your proposal is applied and what the result is, 
before and after?

Cheers
Friedrich

Re: KF API Documentation proposed, small, addition

[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 which places is it a good idea to use "code"-style with class names and
> > method names? So when does readability suffer by too many changes in the
> > formatting in a text body?
> > 
> > Looking e.g. at the Qt docs for a reference, they do not use "code"-style
> > when referencing classes or methods from text, as well as in the listing
> > of classes and methods. So I wonder if this is by design or just
> > historic?
> 
> They use QDoc, IIUC; and it looks like they recommend using \c
> https://doc.qt.io/qt-5/04-qdoc-commands-textmarkup.html
> 
> at least that page suggests so.

Then our question was not "if" they have a command to markup things to be 
printed code-like, but "when" it should be used. And the examples they give 
(not sure though if exclusive or inclusive) are 

"
variable names, user-defined class names, and C++ keywords (for example, int 
and for)
".

So no mention of names of the methods, members, properties and classes the 
documentation is about (note the "user-defined"). And looking at the existing 
Qt API documentation, I would guess the given list is rather exclusive then, 
and \c with Qt is not to be used when referencing the elements of the 
documented API itself (at least in flow text).

Myself I meanwhile rather think that this might be a good choice. Imagine how 
e.g. https://doc.qt.io/qt-6/qstring.html would look like if all text elements 
referencing Qt classes or method names would be in code-style. I guess the 
reading flow in the flow text blocks would suffer a lot.

Cheers
Friedrich

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

[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 Doxygen commands]
> to improve readability, for example
> * @c which will make the word after it use a monospace/typewriter font face,
> typically e.g. @c true, @c false, @c setSomeValue(); for multiple words
> you'll have to use: multiple words
> * @copydoc to copy the docs of a different method, e.g. if one method
> overloads another

I propose to turn "can use" into "should use" and define where which command 
should be used where (and which variant in case of aliases), for a consistent 
result. 
Doxygen commands are already used, so I cannot see how the current proposal 
for an addition makes a difference about helping when to do what?

So in the given case, the motivation of the proposal is to improve the 
resulting documentation to have all in-text (C++) code expressions to be 
formatted in code-typical ways (i.e. monospace fonts). So far this was mainly 
done for literal code expressions like "nullptr", "true" and "false", whereas 
method names or class names were not, until recently at least.

Open question:
in which places is it a good idea to use "code"-style with class names and 
method names? So when does readability suffer by too many changes in the 
formatting in a text body?

Looking e.g. at the Qt docs for a reference, they do not use "code"-style when 
referencing classes or methods from text, as well as in the listing of classes 
and methods. So I wonder if this is by design or just historic?

Leaving @copydoc for a separate discussion.

Cheers
Friedrich

Re: Raising KF5 version a bit earlier

[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 dependency version to 5.85 (so not just the 
version itself) had already been done on July 15th, given we asked David to do 
so before in https://invent.kde.org/frameworks/extra-cmake-modules/-/
merge_requests/150 

See e.g.
https://invent.kde.org/frameworks/kpackage/-/commit/
0e03365fe2674c229ff8c93a353c7c9ce0302afb

Are there some repos which missed out here?

Cheers
Friedrich

Re: Porting notes / deprecation docs

[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
> > 
> > But I dropped out when there were people talking about their progress in
> > writing a replacement and put my hopes & bet on them. But seems life got
> > in
> > then it seems...
> 
> I cannot check what is used on the server but I was told
> https://invent.kde.org/frameworks/kapidox/-/blob/master/src/kapidox_generate
> would be the script that generates apidocs on the server.

quality-kde-org code still is the one being run, and it invokes 
kapidox_generate in the process

Cheers
Friedrich

Re: Porting notes / deprecation docs

[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, Doxygen usually itself already generated automatic links to
> > the functions (just needs complete signature, incl. const), see also
> > https://www.doxygen.nl/manual/autolink.html
> > but then I would guess you know that)
> 
> Yes, that's what I meant. api.k.o does have clickable links (if done
> properly) but compiler warnings do not. That's why it would be good to
> keep the KF5 api docs.

Ah, so html pages on a server/local docs in QCH vs. compiler log, I see :)

((Old man blabla: decades ago one would have hoped we have more machine-
processable output from compilers in 2021, e.g. rich text. But then we also 
still do patches as plain text diffs, not AST diffs... oh well :) ))

> Any insight on how you kept the KDE 2-4 apidocs alive?

Mainly defending against admin wanting to clean up dead stuff and just wiping 
the current freak setup behind api.kde.org ;) (which is https://
invent.kde.org/websites/quality-kde-org)

Right now the kdelibs 2-4 docs are no longer regenerated (at the time when I 
got involved only the 4 one still was, but now also no longer is, and just is 
static files on the web server. I did some URL updates e.g. for trolltech.com-
>qt.io using mass regexp replacements on them).

IIRC main file of the generation is
https://invent.kde.org/websites/quality-kde-org/-/blob/master/apidox/src/
gendox.sh

But I dropped out when there were people talking about their progress in 
writing a replacement and put my hopes & bet on them. But seems life got in 
then it seems...

Cheers
Friedrich

Re: Porting notes / deprecation docs

[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 applications who get that message

Yes, ideally that should be backed up by some web page perhaps, informing 
anyone how to get in touch with whom to make a user and their needs known, for 
finding a solution.

> - Is it possible/desirable to keep the latest KF5 API docs as it is
>generated on api.k.o to have deprecation messages with clickable links
>to replacements?

When doing my own little contributions to keep api.kde.org alive last year, I 
also made sure to have the so far existing kdelibs 2-4 API still available, 
see https://api.kde.org/history.php (reached via "Old KDE Versions" from 
api.kde.org mainpage). The same hopefully can be done for KF5 (and other 
libraries who would need versioned docs).

Now what is meant by "clickable links to replacements" exactly? Any example 
for what you have in mind?
(Just in case, Doxygen usually itself already generated automatic links to the 
functions (just needs complete signature, incl. const), see also
https://www.doxygen.nl/manual/autolink.html
but then I would guess you know that)

Cheers
Friedrich

Re: Porting notes / deprecation docs

[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? :)
> 
> It was discussed in the weekly BBB meetings a few weeks ago.

I see. As contributor on occasions only myself, please refer to the respective 
meeting notes some thankfully write, so one can read up on more background, 
and such a planned task ideally would be backed up by a task board entry on 
phabricator, so people can coordinate and track things about it in an async 
manner.

> >> 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 KF6 development" is referring to? Deprecated during KF5 development
> > and no longer be available in KF6? Not yet deprecated due to no existing
> > replacement, but with replacement planned in KF6?
> 
> Everything that is marked deprecated when KF6 sees the light of day.

Okay. Not a good idea IMHO. There should be a single place of information, and 
we have that already with the current KF5 API docs. I hope no-one plans to 
just remove them from the website, though, Well, then there are also the 
offline docs in QCH format as backup generated during the builds and packaged 
by good distributions ;)

> The idea is to have the APIs that are being deprecated now documented
> when those APIs (and with it the API docs) are removed.
> The audience is everyone who is starting the porting work when KF6 is
> already there for some time.

Ideally that audience should get the recommendation to first port away from 
deprecated API using the last released version of KF5 and Qt6. That way they 
are able to do a big chunk of the work while being able to maintain a fully 
working state of their software, without serious regressions. Once that 
checkpoint is reached, then go for porting all those things which disappeared/
changed in KF6 & Qt6 without any preparations in KF5 & Qt5.

Remember that this is not just KF 5 -> 6, but also Qt 5 -> 6. And perhaps even 
C++11 -> C++17. IMHO only those would recommend to port directly from one set 
of APIs to an other one without any intermediate checkppints for the working 
sate of the software who want to secure their job for a while, because it will 
take ages to fix all the regressions introduced during the port. Unless the 
company/community goes down in the meantime, because the ported software does 
not get done.

BTW, even the Qt Company recommends that step-by-step approach, and they 
surely do want to have their customers be successful in a short time ;) ->
https://doc.qt.io/qt-6/portingguide.html

That is also why some of us invested so much of our time into properly tagging 
API with deprecations warning macros and visibility guards, so porting can be 
done step by step away from the old AP assisted by the compiler, always having 
a working software. Because we have been through some porting in KDE and 
learned our lessons, haven't we... ;)

> Yes it is manual work. However, since the documentation does not remove
> stuff that has been removed from the API, it's a thing of adding newer
> deprecation markers, which seems manageable.

While perhaps it might be a nice thing to have a shortcut list of API that is 
deprecated in KF5 times, as a manifest to look-up things, ideally we find ways 
to auto-generate that from the existing API markup.

After all KDE is a software developing community, so we should be able to 
automate that, no? ;)

So, I can only really ask to keep documentation of KF5's deprecated API in one 
place, and do it properly there, with nice examples, already now useful to 
those who port away when they can. And that place should be the current KF5 
API docs.
Even more as people come and go, and having yet another place which needs to 
be kept even more manually up-tod-ate does not improve things, it adds more 
risk to have outdated unmaintained information. As you could see in review, it 
already now needs poking in every second review to have proper documentation. 
And then also do that in some separate content?

What would be very good to have though IMHO, are preparations of the porting 
documentation of that API which is not deprecated in KF5, but will be replaced 
by something else in KF6 (because it cannot be done earlier for reasons). The 
KF6 task board should have some data about such plans.
Such documentation will need a place and a structure, so also need someone to 
work on and prepare it, so developers can put in the data once those 
replacements are created during KF6 init phase.

My 2 cents

Cheers
Friedrich

Re: Porting notes / deprecation docs

[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 KF6 development" is referring to? Deprecated during KF5 development and 
no longer be available in KF6? Not yet deprecated due to no existing 
replacement, but with replacement planned in KF6?

> For that I scraped up all the deprecation macros from the frameworks and
> edited them to be more unified.

That sounds like duplication of data, and worse, a manual copy of a certain 
state, which also needs to be manually maintained to be up-to-date to stay 
useful.

In general I am also curious what audience is targeted by the planned 
documentation and in which work-flows that documentation should solve which 
needs, and what other solutions are there which would not satisfy those needs 
well enough?

In general, for API already deprecated now during lifetime of KF5 we are 
adding porting notes to the very API itself. Which is also the place as API 
consumer I would be hoping for to get all needed information straight in one 
go, instead of having to jump to other places, which might even get out of 
sync or focus of developers (remember that current online docs of api.kde.org 
also only provide docs for latest version (and even the development one, not 
just the latest released).

And this is a change to what happened in kdelibs4 times, where most 
deprecation happened in the development branches for what became KDE 
Frameworks, so there also was no API documentation maintained at the same 
time. So copying the approach taken for the KDE Frameworks porting notes would 
not be needed here 1:1 for what I understand.

Instead we would need to add documentation for those things which are again 
deprecated (well, removed rather) during preparation of KF6, where the 
replacement also only will be in KF6, so no-one can port before.

Cheers
Friedrich

Proposal: branch ECM into ECM6 for KF6

[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 Qt6/KF6 at the 
same time for the longer future. With no defined plan when support for Qt5/KF6 
should be dropped. 

Which also brings a related question: when should all the deprecated ECM 
modules and any other deprecated things there be dropped that have accumulated 
in the last years since ECM 1.0? While CMake itself has it's policy mechanism 
though so far I think they still keep backward compatibility for anything, 
just doing things different by policy default? And might only dump backward-
compat support really on the next major version?

So when would ECM dump backward-compat support for anything? And, due to not 
being co-installable to older version of itself as of now, risk breaking 
builds of older Qt5/KF5 software or forcing the use of dir links switching? 
Hello Debian and other LTS systems and trying to develop with more recent 
software at the same time.

IMHO ECM should rather be branched into a major-version-postfixed variant as 
well for KF6 times, e.g. "ECM6". And allow a clear cut of legacy things, as 
well as some redesign where considered useful. And perhaps even be renamed, 
into KFCM, KDE Frameworks CMake Modules (yes, I see the unfortune brand name 
conflict while typing, so perhaps something else or no change at all)

Having a version postfix in the name should allow co-installability. Yes, 
there will be some duplication, but Qt5 and Qt6 or Python 2 and Python3 
libraries also duplicate lots of logic ;) and its not that the ECM modules are 
MB of installation.
Maintenance to ensure backward ports of bug fixes between ECM & ECM6 is an 
issue, but might be less trouble than having to support Qt5/KF5 & Qt6/KF6 at 
the same time (including any cached variables on switching build deps) and 
then the challenge when to annoy some people by dropping legacy support they 
rely on.

And those who want to support builds against Qt5/KF5 & Qt6/KF6 from the same 
code (which I personally in general recommend against, compromises needed just 
hurt), they then would have to do a bit more code branches in cmake code as 
well. But they are fine with that in the C++ code, so should they be in the 
cmake code (or just copy over any newer CMake modules temporarily if more 
simple).

Also think of test setup - having to test both against Qt5 & Qt6 might be more 
troublesome, locally and on CI. More easy if there is just one Qt flavour to 
keep in mind.

My 2 cents as old cmake code writer (who might not be involved in the near 
future)

Cheers
Friedrich

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

[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 features can only be used for new API and also
> needs to be guarded properly by respective preprocessor macros to not be
> seen in C++<17 usages of KF headers.

On a related note, we also need to think about how to mark C++17-only features 
(or any counterparts) in the KF API documentation, so developers know from 
first read on whether some KF API fits their project standards. Something like
"C++17 only", " etc. Myself I do not know some good examples in other 
documentation right now to copy from, but definitely IMHO we should provide 
this in ours.

A first related TODO note has been created here:
https://invent.kde.org/frameworks/kapidox/-/issues/7

If you have proposals for how to do that or examples in other existing 
documentation to copy from, please add a note there.

Cheers
Friedrich

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

[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 all KF module development branches already to activate the 
setting).
Any custom CMAKE_CXX_STANDARD settings as before present in some KF modules 
have been removed as well, so all KF modules code should build now complying 
to the C++17 standards, so everyone can also take advantage of those in new 
code for KF modules from now on.


BEWARE (just to emphasize the obvious to you, so it can be referenced ;) ):

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 features can only be used for new API and also 
needs to be guarded properly by respective preprocessor macros to not be seen 
in C++<17 usages of KF headers.

Cheers
Friedrich

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

[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 users will still be informed about the
> deprecations by the compiler warnings.

Using BUILD_DEPRECATED_SINCE with what will become the KF6 Beta version (i.e. 
the version where something will disappear in preparation for KF6) should be 
possible as well. The current way of testing that no hidden dependency by 
usages of deprecated-with-already-present-replacement API still exists, by 
building all KF libraries with DISABLE_DEPRECATED_BEFORE_AND_AT=CURRENT (or 
explicit version) should not be affected by this, as after all the macro 
should yield true for bigger versions.

And the version-controlled deprecation warning macros could also be used with 
that BETA version (though we should then adapt any current usages of 
KF_DEPRECATED_WARNINGS_SINCE to not use 0x06, but the respective KF6 Beta 
version, to silence warnings for the stuff only deprecated without parallel 
replacement and replaced/dropped for the KF5 beta.
Think e.g. as negative exapmple for what to avoid the useless warnings for 
QNetworkConfigurationManager, where we cannot do anything about while using 
Qt5 and have to do that extra work to tell the compiler to not warn for that 
class on our side.

E.g. by the (broken) example I linked before:

#if KPARTS_VERSION <= QT_VERSION_CHECK(5, 900, 0) # the 900 is broken
#include 
#include 
#include 
#include 
#endif

could instead be

#if KPARTS_BUILD_DEPRECATED_SINCE(5, 190) # or whatever if KF6 Beta
#include 
#include 
#include 
#include 
#endif

On the other hand the term DEPRECATED could be confusing here, as nothing is 
really deprecated in the traditional sense., where something is tagged to be 
removed either because being unused or in favour of another now available 
approach. So this could be considered an abuse of those macros rather, and 
where things are already complex now they might get even more complex by that 
additional meaning.

The BUILD_DEPRECATED_SINCE are there for being able to configure a build with 
or without, with a filter level by version even. Will that be needed for 
things which get fully replaced? I.e. will there be a transition time where 
both old & new are available? If not, I would make this rather a simple hard 
condition against the foreseen version where something will be replaced.

Also, if X gets replaced by Y, that X is right now also used by other things 
often in the same module, so being able to completely build without X might 
not be doable. So the macro usage cannot even be tested properly. And things 
will only be found out when actually replacing X by Y (and Y might only be 
created in the process), so any wrapping beforehand does not really prepare 
anything for someone?

Is there an example where things could be demoed/tested/experimented with?

Cheers
Friedrich

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

[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 (https://phabricator.kde.org/T14543)
> - so should we set the version to 6.0 for those instead? avoids leaking into
> KF6 by accident and doesn't block the usage of those macros elsewhere?

I propose to not use 6.0.0. but some beta-like version number, e.g. 5.190.0. 
((Beware, our use of the hexnumber version scheme 0xXXYYZZ limits the 
individual numbers in the version to the range 0..255)).
Otherwise those macros will trigger only on release version bump time, which 
would be too late.

Now the challenge is to find a good minor version number for KF6 Betas :)
And have this properly documented, so people use the same working trigger 
version. At least one place uses QT_VERSION_CHECK(5, 900, 0) which does not do 
what we expect...
See https://invent.kde.org/frameworks/kparts/-/blob/master/src/
partloader.cpp#L21
(should be fixed in the process)

Cheers
Friedrich (sadly no resources currently to help more with KF5->KF6)

Re: Numerous build regressions

[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 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 also from C code, and the C preprocessor of clang (?)
> > on FreeBSD seems to handle a directive like
> > 
> > #if defined(__has_cpp_attribute) && __has_cpp_attribute(deprecated)
> > 
> > not as one like myself would expect it, stopping evaluation before the &&
> > ?
> > 
> > 08:25:02  /usr/home/jenkins/workspace/Administration/Dependency Build
> > Extragear kf5-qt5 FreeBSDQt5.15/bluez-qt/build/src/bluezqt_export.h:42:37:
> > error: function-like macro '__has_cpp_attribute' is not defined
> > 08:25:02  #if defined(__has_cpp_attribute) &&
> > __has_cpp_attribute(deprecated)
> > 
> > Guess that needs some #ifdef __cplusplus protection of some kind. Anyone
> > experience with that, while I am learning while writing such code now?
> 
> Or rather that GCC has __has_cpp_attribute defined also in C mode, other
> than Clang, and there is no lazy evaluation by the preprocessor?
> 
> Still need to research in full detail, but have a first hot-fix testing
> right now locally that does some handling of inclusion of the generated
> export header in C mode, and would push later.
> 
> No clue yet whether the other KIO-related build failures also are related to
> the new export header changes, still need to look at that.

Turned out the KIO-related build failure was also caused by the change in the 
export header generation, which as a result started to have export/visibility 
macros evaluate to compiler-specific attribute markup (say, __attribute__) and 
deprecation attributes to standard ones ([[]]), which at least GCC seems to 
not like when being used together on the same class or function.

See also
https://bugs.kde.org/show_bug.cgi?id=436155

A fix based on the current understanding of the uncovered challenges has been 
pushed now to ECM, and rebuilds are triggered, hopefully they will work out. 
Thanks to (the people maintaining) CI for catching these builds-for-me non-
obvious issues quickly :)

Cheers
Friedrich

Re: Numerous build regressions

[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 functions in KIO.
> 
> Looking into the export header related one. Seems that bluez-qt includes the
> export header also from C code, and the C preprocessor of clang (?) on
> FreeBSD seems to handle a directive like
> #if defined(__has_cpp_attribute) && __has_cpp_attribute(deprecated)
> not as one like myself would expect it, stopping evaluation before the && ?
> 
> 08:25:02  /usr/home/jenkins/workspace/Administration/Dependency Build
> Extragear kf5-qt5 FreeBSDQt5.15/bluez-qt/build/src/bluezqt_export.h:42:37:
> error: function-like macro '__has_cpp_attribute' is not defined
> 08:25:02  #if defined(__has_cpp_attribute) &&
> __has_cpp_attribute(deprecated)
> 
> Guess that needs some #ifdef __cplusplus protection of some kind. Anyone
> experience with that, while I am learning while writing such code now?

Or rather that GCC has __has_cpp_attribute defined also in C mode, other than 
Clang, and there is no lazy evaluation by the preprocessor?

Still need to research in full detail, but have a first hot-fix testing right 
now locally that does some handling of inclusion of the generated export 
header in C mode, and would push later.

No clue yet whether the other KIO-related build failures also are related to 
the new export header changes, still need to look at that.

Cheers
Friedrich

Re: Numerous build regressions

[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 also from C code, and the C preprocessor of clang (?) on FreeBSD 
seems to handle a directive like
#if defined(__has_cpp_attribute) && __has_cpp_attribute(deprecated)
not as one like myself would expect it, stopping evaluation before the && ?

08:25:02  /usr/home/jenkins/workspace/Administration/Dependency Build 
Extragear kf5-qt5 FreeBSDQt5.15/bluez-qt/build/src/bluezqt_export.h:42:37: 
error: function-like macro '__has_cpp_attribute' is not defined
08:25:02  #if defined(__has_cpp_attribute) && __has_cpp_attribute(deprecated)

Guess that needs some #ifdef __cplusplus protection of some kind. Anyone 
experience with that, while I am learning while writing such code now?

Cheers
Friedrich

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

[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 which tasks are really blockers for KF 6.0 and which
> are not. In fact several Plasma items are not really blockers for KF6.
> 
> In the worst case, the first plasma-frameworks release could be delayed
> until Plasma 6 is closer to be ready. Other frameworks don't depend on it
> (just one dependency in KRunner, but it is deprecated, to be removed at
> branching time). Maybe frameworksintegration? (to be checked)

It seems these days the only real user of plasma-frameworks & krunner 
libraries is the Plasma shell itself, with other applications only providing 
plugins/extensions and only targeting Plasma again. IIRC Amarok was the only 
other project ever making use of Plasmoid technology, but not sure that still 
works even. For KRunner, which also seems to have been once designed for 
other, non-shell purposes, I am not aware of anything else.

And with there being strong development coupling when it comes to evolvement 
of features, perhaps it makes sense to move those two modules from the product 
KDE Frameworks to the product Plasma and its release cycle for Plasma 6?
After all there are already a few Plasma-specific libraries released as part 
of the Plasma set, so those two would not be at odds there.

Just a random thought from a non-Plasma contributor having seen what seems at 
sometimes struggles to get changes into plasma-frameworks & krunner in time 
for new Plasma major versions and being backward-compatible to older Plasma 
versions.

Not sure if such a change, if wanted, would be doable already now for Plasma 5 
even, at least without creating major headaches for any stakeholders?

Cheers
Friedrich

Re: Patch for exception.h

[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 the normal
> >direct
> >include  as well.
> 
> Yeah, it surprised me as well.
> 
> The underlying problem was, that reimplementing Job::success() didn't work.
> It wasn't called at any time (checked with a simple std::cout << "";), so
> failing a job was only possible by throwing Threadweaver::JobFailed(). I
> didn't dig deeper in the source than job.cpp, where throwing an exception
> is catched by the executor, which sets the state accordingly.
> 
> Is it a bug or just not documented corrected?

No proper insight into Threadweaver myself here. If no-one else picks up your 
question here on the ML in the next days I propose to file a bug then, hoping 
that someone with clue might have time one day to pick up this issue.

Cheers
Friedrich

Re: Patch for exception.h

[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 <> instead of "", which
> gives you a file- not-found error from the compiler.
> 
> Forgive me for posting a link to github, but it is a really small fix:
> https://github.com/eringerli/threadweaver/commit/
> f7e480e9bd9a3a6dd7f0bed67a4f853e2e339c95[1]

Thanks for the pointer. Forgiven, but then forgive me for being lazy as well 
and not setting up a remote to fetch your commit but doing a new commit myself 
directly :)

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 the normal direct 
include  as well.

Cheers
Friedrich

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

[Friedrich W. H. Kossebau]

kossebau added inline comments.

INLINE COMMENTS

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

Why the `QOverload::of()` with `&QComboBox::textActivated`? 
Accidental copy&paste?
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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

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

[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

[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

[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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

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

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

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

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

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

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

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

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

[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

[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