@sitter Any chance you could put this on your priority TODO list for November (before 5.101), given you might be the one with most insight into the logic due to your previous work on the worker base classes?

Given the introduction of currently KIO::WorkerBase & KIO::TCPWorkerBase parallel to the old KIO::SlaveBase & KIO::TCPSlaveBase classes, this task no longer is waiting for KF6 branching.

Curious: how do the settings in Plasma SystemSettings>Network>Setings (Proxy, Connection Preferences, Cookies) make it at least to Qt/KF-based applications? Is there a chance this config data is only picked up by KIO classes, and thus only when KIO::AccessManager is hooked into the QtNetwork logic?

In T14887#279920, @ratijas wrote:

Any progress on Grantlee?

In T15610#278958, @starbuck wrote:

Should be renamed, someone please confirm if it is correct now and then
close the ticket.

With "category idenfier in the knsrc file" I was trying to refer to the "Categories" entry, as specified e.g. in the "Categories" section here: https://api.kde.org/frameworks/knewstuff/html/index.html

+1 (as in, not unhappy)

In T15665#278122, @ltoscano wrote:

Ok, so I do have a last minute objections.

Updated the description for the perceived current state of discussion.

Guess with not many people interested in big discussions or with elaborated plans so far this should then just see the most minimal change needed
And the new name would be: "kdesdk-kioworkers"

< I've adapted scripty to handle this:

And I just see that other than nwtwork/kio-extras, in sdk the thumbnailers are also in a separate repo, kdesdk-thumbnailers (which also just holds one thumbnailer these days, for gettext po/pot files).
So "kio-extras-sdk" would be rather misleading then. And if keeping this a multi-component repo, should instead keep the component type in the name -> "kdesdk-kioworkers"?

Ah, must have failed to click the very link to the very release notes then (and actually was sure I had seen such lists also for KDE Gear).
Good then, thanks (and just got one +1 on this being what packagers like to see, so all happy from my side here).

Thanks, Ben, and everyone for discussion.

Okay, so seems at least on first thought that should be an okay move, and thus we can get rid of the misnomer now with the MR also merged.

When it comes to timing, guess such a rename is best done after July 7, 2022: 22.04.3 release and before July 14 2022: 22.08 Freeze and Beta (22.07.80) tag & release. So that the 22.08 tarballs are named folloiwing the new name right from the beta one.

@alex Got some chance to reflect on this?

In case more authority is needed, such names as introduced by the "using" would be what is called "global namespace pollution" :)

Please strongly consider adding those generic names into a new namespace KRunner, instead of now introducing those names into the global namespace.

Seems such insight is nothing people have active interest in it, thus discarding again, makes no sense to setup and maintain something only 1-2 persons would ever use. And fits the lack of other insight overview reports like development of compiler warnings, test results etc., guess the lack of MBAs has not helped to establish a cult around metrics ;)

I promised to write such a method before, but I found myself burnt out around this things, brain always went black and I wiped any drafts the next day So cannot help here, not even with code drafts :/

Oha, I just gave doing a build of KF with EXCLUDE_DEPRECATED_BEFORE_AND_AT a try, and seems there are now lots of places in non-deprecated parts of KF modules which use/rely on deprecated API...

Thinking about it some more, seeing the state of EXCLUDE_DEPRECATED_BEFORE_AND_AT might be also slightly orthogonal to which Qt version is used.

With the arrival of gitlab CI, there might be a new chance to revive this idea (please see task description) here to keep some automated track where we are with KF itself depending on own deprecated API in the non-deprecated parts.

In T14887#264318, @mlaurent wrote:

when you will move "https://gitlab.com/kossebau/grantlee" in invent.kde.org is it possible to keep git history ?

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