Committed

In D28525#640569, @samvimes wrote:

[...] und das KDE-Übersetzungs-Handbuch hatte die Großschreibung vorgeschlagen.

In D28525#640572, @broulik wrote:

Generell finde ich es ja respektlos, wenn mich ein Computerprogramm duzt. Dann wenigstens groß, aber, wenn der Duden das sagt ………

In D28493#640433, @felf wrote:

Ween du mir sagst, wie… das ist das erste Mal, dass ich bei Phabricator so weit gekommen bin. :)
(Und früher hab ich das nicht selbst gemacht.)

Was die Grossschreibung von "Du", "Dein", "Ihr" usw. angeht, sehe ich das wie der Duden. Das _kann_ man in Briefen tun aber ueberall sonst ist es unueblich.
Ist das hier arg gemischt? In dem Fall denke ich, sollten wir die Kleinschreibung bevorzugen.

Jup. Danke. :)
Kannst du selbst einspielen?

Ein paar Anmerkungen von mir ...

In D28231#634150, @yurchor wrote:

In D28231#634142, @schwarzer wrote:

I cannot say anything about the soldier since I do not know how this is presented in the application. The rest looks good, thanks.

GCompris soldier.png:

https://github.com/gcompris/GCompris-data/blob/master/words/words/soldier.png

I cannot say anything about the soldier since I do not know how this is presented in the application. The rest looks good, thanks.

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(...)