While working on cleaning this activity today, I noticed the code was already supposed to not allow more than 7 receivers (6 children + the basket) and 6 candies per receivers. I've improved the logic of random-level generation to ensure it's also the case there. And optimized the layout in a way that should prevent all kinds of overflows. Closing as Resolved.

Hi,
Best way to fix this is to make a binding for the size of the receivers, so that it uses a default size close to the current one, and only gets smaller if too much receivers are added in the available area (with something like Math.min(defaultSize, relativeSize).

Just a note to say I've restarted working on this activity for the next major release. I first ported locally the old branch to Qt6 and adapted it to other of our changes, but there are still too many bugs...
So now I'm restarting it almost from scratch, with the goal of reaching a cleaner and bug-free code. With useful reference from the old branch it should be relatively fast.

This has been fixed.

This has been fixed since my layout rework of this activity.

Fixed in https://invent.kde.org/education/gcompris/-/commit/5a4826b3ad3f3bdd6f0b204cb3d02c8f3c8f21b9

All done :)
@jjazeix I've removed the dependency, but maybe double-check there's no leftover anymore...

Good, I'll do that soon then :) Thanks for the task listing and the diff reference!

As it's graphics related I can take that task if you're ok with it.

For GCompris, it listed those 5 failures:

• "branding-has-primary-brand-colors"
• "app-icon-footprint"
• "app-icon-in-line-with-contemporary-styles"
• "app-summary-not-too-long"
• "app-summary-no-weird-formatting"

Done in https://invent.kde.org/education/gcompris/-/merge_requests/185

Fixed in https://invent.kde.org/education/gcompris/-/commit/6ee12f961aa2e1f0641751474740f7b9069d1684

I'll take a look at that soon.

All completed :)

I've just done some big clean-up and improvements to this activity. About your first request, that won't really change as the way it works is to move an item by clicking on its destination slot, which in my opinion is good. But the visual improvements should make it more obvious (before the ListView was not clipped, so it could show an extra item not clickable on the bottom, which was indeed confusing).

Task completed last year, closing as resolved.

Task completed last year, closing as resolved.

Done in commit https://invent.kde.org/education/gcompris/-/commit/d6f9b388b1228b3195ae87db81c5c86a27bf630a

Fixed in https://invent.kde.org/education/gcompris/-/commit/c9545ce52b0a487e1d523bf27e93972d60c2be65

I've found a good command-line software that is able to find solutions for this type of game. We can probably use it as reference or reuse some of its code for this hint feature.

Done for Andika update.

I already have the base logic part working :)