A configuration file that is modified by a GUI, is still a configuration file.
This isn't about editing with a text editor or not, it's about whether you want such a file to be backed up and synced between computers. I'd say yes, for local xmlgui files. If you spend 1h setting up 50 shortcuts and customizing your toolbar, you want that backed up.

I wrote ConfigLocation without much thinking as to whether that should be the Generic variant or not. The main point was: not in state.

Oh I see. Right, then MimeTypeFinderJob definitely stays in KIO.

The first 4 should move to KService too, IMHO.

Gnome ships something for sure (applications.menu or gnome-applications.menu, not sure, see https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html), but overall, we should be able to find org.kde.konsole independently from menus, IMHO.
That's what Type=Service desktop files (installed in kservices5) are for.
IMHO konsole should install such a file, like konqueror does.

I don't understand the question. As you correctly state, kdelibs4 config files were in ~/.kde while KF5 config files are in ~/.config so there was no clash, but also no syncing of any kind. Two completely different worlds. Why would one want to keep them in sync? Config changes made in kdelibs4 systemsettings didn't apply to KF5-based apps any more than they would apply to GTK/Gnome apps. And vice-versa.
This was a different situation than your renaming-but-keeping-compat case, maybe.

Oh, OK, the name will be right at some point, so, sure, call it that way.

projects-invent/libraries/ktexttemplate/metadata.yaml says

projectpath: playground/libs/ktexttemplate
repopath: libraries/ktexttemplate

The name seems wrong to me, it's not part of KF5. Why not just call it "ktexttemplate" like the repo?

Would this mean that if Dolphin crashed during file operations, the operation could no longer be completed, and leave partial files?

You're right, after removing the string-comparison stuff there's nothing left in KParts::Event, it could be removed completely.

Good point about wasKilled already being checked by existing code, that's good.

I made some more progress with this, adding a WorkerFactory base class and making kio_file's plugin QObject implement that, to create FileProtocol instances in-process.

Things are moving in XDG about this too.

Urgh, does anyone still ship kdelibs4 or kdelibs3?

KWallet::isEnabled is for users who don't trust KWallet, right? But then what? They are prompted for a password every single time they check mail / connect to a chat / open a webpage with auth / do anything else that require authentification, right? I'm wondering if this is really workable and if anyone actually disables KWallet. Well, maybe very occasional KDE users which only use a few apps that rarely ask for auth....

Yep that message seems fine. You were right from the start :-)

Yeah that's because ksycoca still contains all sorts of service types: "Application" but also all others. So when querying that DB, we still need to filter on "Application". Once we get rid of non-application desktop files in ksycoca, we can also get rid of that filtering.

AFAICS the KServiceType class should be deprecated as well.

My suggestion is KApplicationEntry (a value class) and KApplicationEntryTrader (an alternative to KApplicationTrader that returns a KApplicationEntry or a list of those).

(for the record, a working link for pointer_helper_p.h is https://invent.kde.org/libraries/kpublictransport/-/blob/release/20.12/src/lib/pointer_helper_p.h given that it has been removed in master)

Like Ahmad said :)

This could use Qt6 setupChildProcess() or in Qt5 setChildProcessModifier(), similar to https://phabricator.kde.org/T13940.

Done in https://invent.kde.org/network/konqueror/commit/4f96b58efc8614f33d0a15fac6393612e3d3068e

I'm working on that.

I think it needs to be ported to selectionInfo(KFileItemList) instead.

BTW the main use case is Android where forking processes is not allowed. We could still keep most slaves out of process on desktop platforms, for the robustness reason mentioned above.

Do the other tools k´fron kde-cli-tools matter in the frameworks context?

kde-cli-tools: we all agreed in today's call that the best course of action is to remove the '5' (for compatiblity, we should still provide the '5' name as a symlink to the versionless binary). And for KF6, we'll stop installing those symlinks. The reason this is possible now (while it wasn't before) is that by forking slaves instead of talking to klauncher, we don't need to use the same KF version as the running environment anymore.

As discussed in the meeting, let's keep the only KFileItemList overload, it's the one that provides most information to the recipient, which doesn't have to re-do things like mimetype determination etc..

String comparisons are an awful solution for a dynamic_cast-like solution. We were young and inexperienced...
Nowadays we should use QEvent's type() instead.
I suggest to remove eventName() and the Event(const char*) constructor in KF6 and replace it all with event type ids like QEvent does. I would also remove KPARTS_EVENT_MAGIC, the base class should be abstract, it makes not sense to instanciate it as is.
This means

Next step: https://invent.kde.org/frameworks/kinit/-/merge_requests/8

Well done!

re lensfun: let's see if https://invent.kde.org/packaging/craft-blueprints-kde/commit/8582a5a0d8bf946a182c36028d2c7599b9d62d56 helps....

Fixed libgit2 with
https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/227 + https://invent.kde.org/packaging/craft-blueprints-kde/commit/ca8d3a66c642c62c6a3660ef663e224e22e7a789

Done in https://invent.kde.org/frameworks/kservice/-/merge_requests/54

Waiting for @nicolasfella to agree or disagree with my comment :-)

Well, one can implement a crash handler without using KCrash... A simple sigaction should do. This would also be an opportunity to make sure no memory allocation happens in the signal handler (I bet unlink converts the QString to an 8-bit char* down the line), by storing the sycoca path into a static char*.

Thanks. Nobody told me it broke a unittest and I didn't notice, indeed. I think kdepim's unittests are ... lacking supervision.

https://invent.kde.org/frameworks/kio/-/merge_requests/492

Well, it was using inheritance, which is frowned upon for value types (due to risk of slicing).

I did a quick test to see if this could work:

The other side of this is to disable the kdeinit loading mechanism: http://www.davidfaure.fr/2021/disable_kdeinit_for_executables.diff

Oh, my bad. Coming back to an old discussion, I misinterpreted some old comments (mine included).

plasma-workspace is a workspace, not a provider of library for the above applications.

As discussed in today's BoF: removing from KF6 board, not a blocker for KF6 itself.

Great. If there's a plan, then it's not a blocker for KF6 itself anymore -> removing the KF6 tag.

Makes sense, unless we want those overlays to show up in the file dialog too, in the future...

Why? Doesn't this module only make sense in Plasma?

@cfeck "Right now, application config files can override colors over kdeglobals to allow per-application color schemes." << technically yes, but there's no GUI for that, so do we really need that feature?

Albert says it's now possible to force-stop the interpreter in ... QQmlEngine?

Obviously keeping KServiceTypeTrader is a valid alternative :)
I only wanted to deprecate it because all plugin-loading needs were otherwise covered, forgetting that it's not only used to load plugins.

Obviously search providers used to use KServiceTypeTrader too, but indeed I ported away from that in commit 6246cc48067845208cf5acd8b798abd68349cf18 (D9213)

Yep. And a clean build (with no cmake cache), just in case.

I have no plans myself, I don't know anything about KAuth. This was just a suggestion :-)

Actually, that's done already, src/CMakeLists.txt makes a copy of applications.menu into the right build dir for the unittests to pick up.
So this will keep working even if kservice stops installing that file, all we'll have to do for cleanliness is to move it from src/ to autotests/.
And copy it to plasma.
But all this has to wait for KF6 branching.

KService should use a copy of applications.menu for its own unittests, so that the file can move to plasma. I can work on that.

"Who cares" (which really means "I don't care", since clearly there are people who do care), and "stupid" are not constructive feedback nor acceptable language in this community.
Here's a constructive suggestion for how your feedback should have looked like:

Actually forget about DAV, FTP is a better example.

We live in a world of fast reliable internet. I suspect people in less-well-equipped ("third world") countries might have a use for increasing timeout values so the system tries longer before giving up. But yes this was more useful when it was about your internet browsing, while now if it's just about your DAV connection....

Yes, I don't think we can do that earlier, since host and part need to agree on the class being used.

No this isn't about sessions (which involves persistence across application restarts). This is all in memory.

I think this was about class KSERVICE_EXPORT KService : public KSycocaEntry, which exposes the fact that KService is "backed" by ksycoca, in the public API (given all the methods in KSycocaEntry).

I assume webkit-based doesn't either

If nothing in the code of kcmshell creates a dependency problem, I'm in favour of this solution, it's also what came to my mind when reading T14330.

Pushed in https://invent.kde.org/frameworks/sonnet/commit/6eb2c6392548772b2c594dfebf0ec53b9a8635d7

Re-reading my reply in that MR, I am very unsure of what I meant. I think I was only talking about the technicalities of an empty Exec line for a Type=Service desktop file. Please do not treat that as a decision in any direction, I don't have experience with the question of "kcmshell is available but systemsettings isn't".

"KBookmarkMenu needs a complete rewrite" : see comments in konsole's subclass of KBookmarkMenu.
But a new class can be written at any time, before or after KF6 branching.

Related: https://invent.kde.org/frameworks/kwallet/-/merge_requests/11

Maybe @antlarr knows why 22px was chosen?

We cannot drop things during the KF6 lifetime, by definition. Deprecate, at most, but not remove. So it will need to be maintained for the whole KF6 lifetime unless you start porting away from it, document how, deprecate it, and remove it after KF6 branching...

(I replied in T12256, the last comment here is no longer applicable, desktop files for plugins are being phased out)

Sure that would be Unix only.

Hmm hmm. If I implement KTerminalLauncherJob using a DBus interface, and move it to KService for KF6 according to the current plan, then we'll still have a dependency to DBus in KService. Same for the pending support for DBus-launching applications in ApplicationLauncherJob.

In progress: https://invent.kde.org/frameworks/kio/-/merge_requests/406

I see. Well, someone should implement it in one app (real or test), to make sure it all works, and then document it :-)

No, you don't. The code in KFileItemActions says:

Improving the documentation for the first two bullet points would make sense, yes.
But the solution for "Situation 2" needs to be implemented, too.

Seems sensible. I think what you mean is that I posted my thoughts into the wrong task, 16 months ago, that's quite possible :)

Can't find a Canceled column.

Well, it makes sense to prolong as much as we can the transitional period where the same codebase can be built with both Qt5/KF5 and Qt6/KF6.
(e.g. I just ported libkode and KDSoap that way, master supports both Qt5 and Qt6. It's so much easier to have it all in a single branch...).

Especially with the current trend of porting KCMs to QML, they should really move out of KIO then...

This has been done meanwhile.