We also don't need this. Q_SLOTS are needed with old style Qt syntax where SIGNAL and SLOTS are used. With the new Qt5 connect syntax, you can just connect to any function, so no need to involve moc on this function.

The other include (#include "externalcommandhelper.h") I think can still go away but please test that it builds in a clean build dir.

It is needed by std::unique_ptr and std::unordered_set. We shouldn't rely on header being pulled in by some other header.

Maybe push to 4.0 branch?

Ship it

If I commit this myself, I need your mail address for git commit --author. Is it the same as in reviewboard (I can't see the one from Phabricator)?

In D13849#384351, @davidedmundson wrote:

It runtime requires Qt 5.12 for xdg-output which the shell needs for fullscreen, which means we can merge for Plasma 5.16

Looks fine.

Looks alright, although I wouldn't call that thing a typo. Variable names in C++ doesn't have to match in function header and implementation, although, it's probably less confusing if they match. But sometimes one can simply omit names in header and just have types.

In D20109#440247, @cjlcarvalho wrote:

We also need to adapt this connect KJob to the Qt5 signals and slots syntax.

I don't think we should change other lines too here. We pass that percent to KJob, so keep the type the same as KJob expects.

I don't think moving QtCrypto is right. It's not a Qt header, it belongs to QCA.

Hmm, do we really need this? quint64 is unsigned long long. It's just a typedef, so both can be used interchangeably. And unsigned long long is also C++ data type, not just C... Altgough, obviously this change wouldn't break anything. I guess it's just a question of code style but I didn't find any KDE recommendations. Any other opinions from other reviewers?

Coding style adjusted

Added more error handling if executable is not found.

By the way, what about duplicate icons? When transitioning from Oxygen
to Breeze, KDE Partition Manager was given the same icon as Filelight
(which actually looks more like filelight window rather than disk
partitioning).

@cjlcarvalho Just double checked, it's still an issue.

@cjlcarvalho I don't recall any patch that fixed this. I can try to test
later today.

In D17129#382304, @stikonas wrote:

In D17129#382302, @varunp wrote:

Most of the features in gsmartcontrol look like they have already been transferred to json. I can try to add all of this in the next few months. Is there any timeline on the next release of partitionmanager/kpmcore?

No timeline yet. First of all, there needs to be a new release of smartmontools. But probably best to work in a branch for a while.