Thanks indeed. Just a note for future. Try to keep patches smaller. Separate them in e.g. whitespace changes, documentation changes and code changes. git add -p or git commit -p helps with that.
Reason: If you mix code changes with whitespace changes and then the code change turns out to be problematic, you cannot just revert the change without losing the whitespace fixes.

Committed as 5f29c43e896e7865de7a6a7ee747f6ffc60f47dc

Any more complaints/suggestions? I do not know who would be a good assignee for print-manager since several people more or less sporadically work on it.

My bad, this should now be the right diff.

I think I updated to a new diff but it is not showing the new changes ... Any hint?

init member in header

Committed in 1e656e0051f3919b02f8425632d47f9d332785ab
https://cgit.kde.org/kshisen.git/commit/?id=1e656e0051f3919b02f8425632d47f9d332785ab

Yes, I re-read the KF5 porting notes and I guess the KFoo -> QFoo thingy was a misconception based on the deprecation of quite some the KDE 4 KFoo classes.
Thanks for your comments. :)

Hmm, that was exactly my thought when I saw these Krazy issues. I think to remember exactly the opposite suggestion from a few years ago where Krazy said, we should use the equivalent Qt classes. Am I remembering correctly?

Thanks indeed. Very useful! :)

In D12459#253942, @broulik wrote:

@schwarzer I'm changing the catalog name to be more consistent with the other KCMs, is that an issue?

Not sure if it's possible here bit might it be feasible to extent the scores class' c-tor and hang the object into the parent memory management hierarchy?

Looks good to me. But wait a few more days in case others want to review as well.

In D11561#231670, @ivan wrote:

You can also switch to 'can't' as far as I'm concerned

Danke für die Arbeit. :)
Ein paar Nachfragen folgen.

In D9805#189154, @aacid wrote:

I just realzied this is not how you use QMEsasgebox critical.

Since it's static you just do QMessageBox::critical(...)

fix diff ... hopefully

In D9805#189130, @aacid wrote:

Is phabricator being silly or are your patches missing some stuff?

Like it says
...\nPlease install the
and ends there

In D9790#189002, @helfferich wrote:

Do you mean switching the interval/substeps/speed? Or switching from a change in timer interval to the substeps?

I'll try to explain:

1. Why change the interval? The basic loop is: Move ball -> Check for collisions -> Change direction, perform actions, according to collisions, etc. -> Move ball -> ... The speed determines how far the ball is moved during the "Move ball". If the ball is moved too far, the collision detection might be inaccurate (E.g. the extreme case is the ball moving through a brick with no detected collision). To avoid such bugs, we move the ball only half the distance, but twice as often.
2. Why use substeps now? In the original code, this was done by cutting the gameTimer interval in half. However, this broke during the port to QML, because QML timer have a minimum interval of 16ms. Cutting it in half to 8ms does not have any effect. The alternative approach is to keep the gameTimer interval, but perform the basic loop twice.

OK, tested it and it works as in the ball does not slow down anymore.
I cannot really argue about the implementation because I did not understand why this switching is needed in the first place. :D

Thanks for picking up the topic with a patch. :)
I might be able to test this tonight but not sure.
Anyway, here are just some things I saw while scrolling over the patch.

Nur ein paar Sachen, die mir beim Drüberfliegen aufgefallen sind.
Ein paar sind schlicht Geschmacksfragen, also im Zweifel ignorieren. ;)

In D9570#184689, @aacid wrote:

This is not really needed, i.e. the xsd is not really accurate of what the code expects since this gets merged with the default rc file we will already have a menubar.

If you feel strongly about having the file validate, sure commit it, otherwise it's not really worth it in my opinion.

Looks good to me.