Another data point, KStandardAction has some code like this:

if (pAction && parent && parent->inherits("KActionCollection")) {
    QMetaObject::invokeMethod(parent, "addAction", Q_ARG(QString, pAction->objectName()), Q_ARG(QAction *, pAction));
}

I don't know which of the calligra apps are still alive / have recent commits/activity.

https://invent.kde.org/office/kile/-/merge_requests/13

Good news: https://mail.kde.org/pipermail/kde-core-devel/2022-February/091573.html

This task should be tagged Plasma, it can happen at any time, not necessarily before KF6.

Finally merged https://invent.kde.org/frameworks/kdesu/-/merge_requests/14

In T15232#270140, @vkrause wrote:

In T15232#270137, @ahmadsamir wrote:

Gitlab CI runs unittests as root, can looking into these wait until it's not running them as root?

Issues from running the tests as root should affect the Qt5 tests equally I guess? If so, this only looks at the difference to the 5 build, and thus shouldn't contain any issues caused by that. Those I have investigated in more detail already are all unrelated to that at least.

Gitlab CI runs unittests as root, can looking into these wait until it's not running them as root?

WIP MR: https://invent.kde.org/frameworks/kdesu/-/merge_requests/14

Using ::system() and setting FD_CLOEXEC on all fd's, I still get similar results.

(I knew declaration-and-definition-rolled-into-one are not nice, but didn't know they could be this bad :-)).

Interesting. I have Qt 6.2.2 (what's in Tumbleweed repos), I don't build Qt from source.

Debugging with:

It looks like alot of the usage of QNetworkConfigurationManager is about the QNCM::onlineStateChanged signal, which can be ported to using QNetworkInformation::reachabilityChanged in Qt6. https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=QNetworkConfigurationManager

Thanks o/

In T15127#268304, @mlaurent wrote:

what is the status of Phonon4Qt5 ? Will it deprecated or we need to add to this list ?

In T15127#268282, @alex wrote:

This should take care of the plasma-frameworks dependency: https://invent.kde.org/frameworks/krunner/-/merge_requests/83

In T15127#268279, @alex wrote:

krunner (links against plasma-framework)

The dependent pats have been deprecated for quite a wile. In a deprecation free build nothing depends on plasma-frameworks

From building against Qt6, one implication of QTextCodec being moved to the Qt5 compat module, is that QTextStream::setCodec() is gone in Qt6, replaced by QTextStream::setEncoding(), which doesn't have the same range of encodings that are available in QTextCodec.

In T12208#267910, @davidedmundson wrote:

The docs are very misleading.

But the core part of automatically adding accelerators to apps is something that's run for all applications. It adds the majority of &accelerators.

This is done regardless of any user settings inside the KCheckAccelerators constructor called from a Q_COREAPP_STARTUP_FUNCTION hook.

I have a feeling that it was meant to be a debug tool, and everyone was meant to call KAcceleratorManager::manage manually. But due to a bug this debug tool is always doing it, and now everyone relies on it.

In T11833#267882, @alex wrote:

Doesn't Plasma also use the inhibition stuff? not sure if it's from Solid or somewhere else.

https://invent.kde.org/plasma/plasma-workspace/-/blob/master/libkworkspace/sessionmanagement.h

Doesn't Plasma also use the inhibition stuff? not sure if it's from Solid or somewhere else.

I would say yes, mostly; what remains can be fixed as we go, I think (i.e. when building against Qt6 fails in a KF, we'll adjust the code in ECM to accommodate, e.g. https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/208).

Actually KIO::ProxyScout has to be ported to something else, because QNetworkConfiguration is gone in Qt6, and there is no replacement.

Posting here so as not to forget; QDomDocument is still used in the implementation of KIO::davSearch().

More measly digging:

• kdesud parent pid is 1, (so probably the parent of kdesud isn't waiting for it to finish, and it gets repartented to systemd as the init pid 1); I am not an expert on this subject
• kdesu is the parent of /usr/bin/su root -c /usr/lib64/libexec/kf5/kdesu_stub -
• the previous /usr/bin/su process is the the parent of /usr/lib64/libexec/kf5/kdesu_stub
• kdesu_stub is the parent of dolphin
• /usr/lib64/libexec/kf5/kioslave5 /usr/lib64/qt5/plugins/kf5/kio/kio_file.so has parent pid 1

In T12166#267022, @fvogt wrote:

In one of the KF6 meetings, it was noted that kdesu won't work in Wayland because the latter doesn't allow GUI apps to run as root at all (IIUC).

As long as the application has access to the wayland socket, it'll work. If $WAYLAND_DISPLAY is an absolute path or $XDG_RUNTIME_DIR is preserved (kdesu doesn't do the latter), that's enough for applications running as root to connect.
e.g. sudo -E kdialog --getopenfilename or WAYLAND_DISPLAY=$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY kdesu -- kdialog --getopenfilename start kdialog with wayland as root.

In one of the KF6 meetings, it was noted that kdesu won't work in Wayland because the latter doesn't allow GUI apps to run as root at all (IIUC).

Using openbox:

ct       14634 14229  0 13:40 pts/8    00:00:00 kdesu /usr/bin/dolphin
ct       14643     1  0 13:40 ?        00:00:00 /usr/lib64/libexec/kf5/kdesud
root     14663 14634  0 13:41 pts/12   00:00:00 /usr/bin/su root -c /usr/lib64/libexec/kf5/kdesu_stub -
root     14666 14663  0 13:41 pts/12   00:00:00 /usr/lib64/libexec/kf5/kdesu_stub

I see; a round-about way would be to get the file name from kconfig and pass it to KPluginMetaData which would then create a QSettings object and read the entry; but that is a bit more hassle.

Instead of a function template, how viable would it be to use QSettings? for example Sonnet uses QSettings since it's in a higher tier and can't use KConfig.

So, it looks like there is a viable alternative for OpenSuse's yast use-case; haven't tried the other apps that use kdesu.

One more data point; using pkexec (an online search revealed that others asked the same question about pkexec before https://unix.stackexchange.com/questions/203136/how-do-i-run-gui-applications-as-root-by-using-pkexec) seems to work for e.g. yast:

Another clue:

ahmad    10822     1  0 11:43 pts/2    00:00:00 /home/ahmad/dev/kdesu/build/install-dir/lib64/libexec/kf5/kdesud

so basically, the PPID is 1, which is systemd.

I changed the code in kdesu/src/client.cpp back to using system(), see https://invent.kde.org/unmaintained/kdelibs/-/commit/e4cebe4edd98d63fabfb2eecf4ceef794d5fa5a4; (I wanted to see what fd's were shared between parent and child, to test if it still works after I change the code to use QProcess):

Right; I tested and that seems to work, so it's a false positive (and apparently I am slightly confused about this issue).

I think only this is left:

In file included from /home/ahmad/dev/kdeclarative/src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp:8:
/home/ahmad/dev/kdeclarative/src/qmlcontrols/kquickcontrolsaddons/qiconitem.h:56:5: warning: signal smoothChanged is overloaded (with /usr/include/qt5/QtQuick/qquickitem.h:97:1) [-Wclazy-overloaded-signal]
    void smoothChanged();
    ^
/home/ahmad/dev/kdeclarative/src/qmlcontrols/kquickcontrolsaddons/qiconitem.h:57:5: warning: signal stateChanged is overloaded (with /usr/include/qt5/QtQuick/qquickitem.h:97:1) [-Wclazy-overloaded-signal]
    void stateChanged(State state);
    ^

Updated based on a recent grep on the Frameworks. Either they're ported or an MR has been created.

FWIW, state includes toolbars and dockwidgets location/orientation, that is part of an app configuration.

@krop thanks for the info and insights; looks like Qt are making good use of CMake.

In D26675#678819, @davidre wrote:

we could install an icon into hicolor as fallback

One way to fix this is if sddm have copies of the needed password buttons, then it should work regardless of the installed icon themes.

In D26675#678811, @bharadwaj-raju wrote:

Is there an SDDM issue to track this? Because I edited the file to make revealPasswordButtonShown true, and the button shows up just fine. Which makes me think this might've been fixed in SDDM.

In T12533#263355, @alex wrote:

@ahmadsamir I feel like T12549 is actually the more suitable task since we are talking about migrating cache data ;)

I am not sure which is better, the in-app code, which is never going to cause any race conditions, or a central solution in KConfig (which is kconf_update, which has some side effects :)).

In T12533#252707, @dfaure wrote:

Notes from the KF6 sprint (2021-03-28)

• If possible, applications should do it in process -- doesn't even need API in KConfig. The app can make up a key for the version and check it, (this will even work better for cases where a plugin wants to update something in the app rc file, a single app-global version number would require the app to know about this).

In T13986#263041, @alex wrote:

@ahmadsamir KCMUtils is taken care of with the last overloaded signal having an open MR,

Also I un-overloaded a signal in kwidgetaddons of the rating widget.

kitemmodels

Here private signals are overwritten and no overload is specified.

Even without passing a parent to addModule(), you can still have a treeview by setting the FaceType: dialog->setFaceType(KPageDialog::Tree)

Already done by Montel (thanks).

Should be fixed by https://invent.kde.org/frameworks/kio/-/commit/707b3eadf661e9f1066748cda8f1349bca95137b

In T14335#261955, @davidedmundson wrote:

I don't think the phase split makes sense,

Ack, I'm happy to drop that.

I think in general the concept of kcminit makes some sort of sense. It allows us to drop specialisations in startplasma, and that's a good thing.

Excellent, thanks. (I had no idea how to fix it :D).

Tracker issue created at https://invent.kde.org/frameworks/kio/-/issues/6

In T14763#261292, @alex wrote:

If systemsettings5 is the executable, but datafiles get installed in a systemsettings folder it will not make a difference if the executable is versioned or not.
See https://invent.kde.org/plasma/systemsettings/-/blob/master/app/CMakeLists.txt#L37.

In T14763#261281, @alex wrote:

Plasma yes, but most likely used by some code in KF to launch it.

But that raises the question if we can make a KF6 release if Plasma 6 is not ready yet.

In T14763#261277, @alex wrote:

Aren't kinit and kjs supposed to go away?

Yeah, that makes sense.

In T14370#261205, @alex wrote:

I guess this could also be extended to remove the then redundant qOverload/QOverload::of/static_cast statements in the connects that previousely were overloaded?

Updating the list of remaining Frameworks:

• ktexteditor
• bluez-qt
• kdeclarative
• kitemmodels
• plasma-framework

Actually they are two different tasks, this one is about actually deprecating/un-overloading the signals; the other task is about cleaning up the API docs, i.e. removing the // clazy* exclude rules... etc.

If there are no objections I'll run this on KF repos right after the 5.85 release. (I'll ping this task before I actually start, just in case).

Sounded like a good idea, I tested it but it didn't work; then reading QDesktopServices::openUrl() docs:

KUrlHandler::openHelp() has a fallback to open the relevant docs at docs.kde.org if KHelpCenter isn't available while that code can be moved to to OpenUrlJob, it would mean that any KDE application that doesn't require KIO would be stranded.

Creating a list seems to work getting things done, so.

Two MRs merged, remains https://invent.kde.org/pim/kontact/-/merge_requests/7.

OK, I've had KDE_FORK_SLAVES=1 exported for a couple of months now, I didn't see any issues.

A small correction, which shows how old/ancient some of us are :), there was no KF4, back in those days it was called kdelibs/kdebase, not going to say KDE4 as that makes some people who are more ancient than myself, a bit annoyed; many of the current repos in KF lived in kdelibs, kdebase, kdeworkspace IIUC.