Pushed to master and Applications/17.12

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

I just realzied this is not how you use QMEsasgebox 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

Looks sensible, only minor comment is that you should be using === instead of == in JavaScript code since it's marginally faster, but not that it matters much.

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

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.

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

Thanks for catching the typo. About the comment: You are of course perfectly right :D.

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.

Your welcome! If there are any more issues, just open a new ticket or re-open this one.

Thanks for the API reference to the list of the categories.

I checked and see the categories listed live here:
https://api.kde-look.org/ocs/v1/content/categories

Isn't it https://autoconfig.kde.org/ocs/providers.xml nowadays (not sure about what is the prefered URL)?
Also, where do you get the error with what request?

Ok, but then, what happened with the new categories? Just to name one, I fixed kdiamond according the name which is shown, but I see an error about non-existing category:

Yeah, that could be.
KNS/GHNS unfortunately has the habit to look for a hardcoded category name, so to make it work backwards compatible, I would need to know the exact string each program tries to match and add it as "legacy name" internally.

Thank you. Another question: is it possible that the name shown does not match the internal name? I see messages from knewstuff saying that the categories do not exists.

Since knewstuff is now retired (and from my understanding didnt feature an account management?) the best would be

1. ask the authors to create an account and re-publish them.

Thanks! Did you see also my question about the possibility of sending contents from someone who is not the author?

All Categories have bveen added: https://store.kde.org/browse/cat/355/ord/latest/

Gently ping @starbuck

Also, another category:

Also, another category:

It turns out the the web server on the machines hosting newstuff.kde.org was restarted by accident when I tested the applications few days ago. So the testing worked just by pure chance.
Reopening, few applications need categories on store.kde.org:

Apparently the issues was temporary or it has been solved somehow. As today (2017-07-23) all knsrc files in kdegames/ which has a corresponding GUI can load something (or at least not error out). Closing then.

Maybe changing the value is fine. Or the print dialog could have a button (if it's possible to extend it, not sure with Qt5 and its incomplete state) that says "Print immediately". Whatever is easier.
About wasting paper: if you are going to print, how many schemas are you going to print?

In that case, maybe you'd simply want to flip the default value of the setting "When printing, try to fit more than one puzzle on a page" instead?
That way ksudoku will print just the one puzzle, wasting paper, but it will print it right away.

Or simply print immediately :)

I take it you mean you want a different UX for the printing feature. Something more like the following, perhaps?

Possible issue which requires some thinking: some of those dbo calls write a formatted text (like a game schema), so it should be investigated whether this is still required, or if some overload of the << operator are required.

This change has landed.

Working on a Differential for this right now.