Kross support removed from Lokalize in https://commits.kde.org/lokalize/a0dc91ddc032485f850bc8fd5333e5a8a58024b6.

This is done in Plasma 6.

@ognarb and @svuorela has been doing some work, but some is still left

SlaveBase is now internal, can be cleaned up at any point

This is "solved" by dropping ResourceInstance: https://invent.kde.org/plasma/kactivities/-/merge_requests/34

We have plasma-open-settings as an agnostic tool to open systemsettings/plasma-settings with fallbacks to kcmshell.

There may also be cases where we prematurely ported to kcmshell6 and we need the ability to open a Qt5-based KCM. This could happen e.g. when running a KF6-based app in Plasma 5 (assuming that's a supported case at all)

WindowEffects was clean up in https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/120

By default it is https://lxr.kde.org/source/frameworks/kdeclarative/src/qmlcontrols/kquickcontrols/private/keysequencehelper.cpp#0070

Do we actually use the checkForConflictsAgainst in KeySequenceItem anywhere? Quick grep suggests not

https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1762

"solved" for now by https://invent.kde.org/network/kio-extras/-/merge_requests/296

My proposed course of action:

I got confused by my incomplete Gnome installation, Gnome indeed ships gnome-applications.menu and this is a non-issue

This isn't about services in the KDE sense though, it's about applications. (It's not about konsole*part* but the actual Konsole application)

'service->property("Foo", QMetaType::QStringList).toStringList()' is a bit of a mouthful. Can/should we make it something like 'service->property<QStringList>("Foo")'?

The problem is that package managers will not overwrite /etc stuff on install, that will lead very easily to issues.
As said, I see the point for the user local config, why not in .config, all fine for me.
But I would like to have the shipped ones as data, that allows to be sure updates will enforce the new state is used.

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 think having that in /etc is very wrong as most applications totally break or even crash on any non-trivial modification of this and /etc somehow implies this is config.
The files in the config dir in the home are only meant to be written by the shortcut config and Co. and not manually altered.
In Kate and Co., if you just remove some menus or toolbars in the worst case it will just crash.

In https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/374#note_745927, @krop comments:

Although technically correct, I'm not particularly happy to see ui files being installed in XDG_CONFIG_DIR by default. There's nothing a system administrator should touch. I'm not convinced that's the right move.

Updated functionality:

• MR "KDE_INSTALL_KXMLGUIDIR: undocument and prepare remove for 6.0 "
• MR "Use GenericConfigLocation to read & write ui.rc files (w/ migration class)"

Found that AppConfigLocation actualy cannot be directly used, as plugins have their separate component name to use in place of the appname. So sticked with GenericConfigLocation/cpmonentName, which though is pretty the same as AppConfigLocation for apps anyway.

Thanks for the input, good to have :)

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

@dfaure Any chance on your "old-timer knowledge" on the question whether to keep using "kxmlgui5/APP" (i.e. GenericConfigLocation/ConfigLocation) or to instead switch to "APP/xmlgui5" (i.e. AppConfigLocation)?

Other things:

https://invent.kde.org/system/kup/-/merge_requests/23

Proposed implementation:

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

On close look the situation seems to be a bit different than kded. kiod doesn't really have externally provided modules, all of them come from kio(-extras).

There's one thing in our proxy settings that libproxy doesn't seem to cover: The "Use proxy settings only for addresses in the exceptions list" settings.

KRunner/Milou:
https://invent.kde.org/frameworks/krunner/-/merge_requests/148
https://invent.kde.org/plasma/milou/-/merge_requests/69

https://codereview.qt-project.org/c/qt/qtbase/+/494754 for enabling it upstream by default