version 2023-11-21 contains it

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

In T15768#283967, @siddheshkukade wrote:

@timotheegiet I just wanted to help KDE by contributing to it's projects I have a year of open source experience.
How can I get started for this project can you give a short information about the tech stack used here

@timotheegiet I just wanted to help KDE by contributing to it's projects I have a year of open source experience.
How can I get started for this project can you give a short information about the tech stack used here

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

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

https://invent.kde.org/education/gcompris/-/merge_requests/114

https://invent.kde.org/education/gcompris/-/merge_requests/109/

I'll have a look.

@hadron if you think you will have time, feel free to take a look at it, you'll probably find a cleaner quicker solution than me :). If you don't have time, please tell so another person can take a look at it

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

For code: https://invent.kde.org/education/gcompris/-/commit/a1d28e55fdc774a24469ab4c390db498e3e7882f

As discussed, this code misses some use cases and does not handle correctly the translation.

Hi,
If you replace the Manuel part of gcompris.py with this code:

For source_build_dist.sh (only shipping po files in the list): https://invent.kde.org/education/gcompris/-/commit/721e7dbdac7ab7060e708a6edfbeb263cddc3d02

https://invent.kde.org/education/gcompris/-/commit/47b6ee940e71f0b603e05b01bb677fb15ba01d8c

In T13994#247257, @timotheegiet wrote:

In T13994#247248, @echarruau wrote:

and at some point, when all users have migrated to the last version, we can remove the symbolic links in the data repository

"when all users have migrated to the last version" is not something that will ever happen... (as far as I can tell we always have users using older than latest version for several reasons...).
Better keep the symbolic links as long as possible, as links do not take much space it should not be a problem to keep them.

In T13994#247248, @echarruau wrote:

and at some point, when all users have migrated to the last version, we can remove the symbolic links in the data repository

We would replace all the words/$color.$CA with colors/$color.$CA
in the GCompris data repository, we will remove all words/$color.ogg and create a link from colors/color.ogg -> words/$color.ogg
and at some point, when all users have migrated to the last version, we can remove the symbolic links in the data repository

Regarding the voices, if they are already in colors/ folder, it's better to use them directly instead of duplicating them in the words/ folder (and then potentially miss one when updating).

Merge request:
https://invent.kde.org/education/gcompris/-/merge_requests/43

I'll try and fix this soon.

Sure you can!
qsTr() is used to mark strings as translatable (https://doc.qt.io/qt-5/qtquick-internationalization.html#1-use-qstr-for-all-literal-user-interface-strings)

Can I take this? If yes, what exactly do I have to do?

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

Hi,
We do not need to have a version just for numbers. I understand why it is
in mathematics now.
Emmanuel

I've fixed the issue with characters hidden by mobile keyboard (they are now always anchored to the top if the mobile keyboard is visible).

Right, I'll take a look for the layout issue.

Hi,
we did change it because:

"Type of fruits" (the plural of "fruit" is also "fruit")
we've updated our use of "fruits" to "fruit" (except in one place where "fruits" was appropriate as really referring to different kinds of fruits)

Perfect again. Thanks! :)

It misses some Qt packages, I think this command should fix it: sudo apt install qml-module-qtquick-controls qml-module-qtquick-window2

Which OS are you using? If ubuntu:
...

I have verified that this is fixed. Great work! :)

I have verified that this is fixed. Great work! :)

Oh, yea. WIth all the issues that I reported and all the bugs that you two have been fixing, I got slightly confused for a second and thought that this one had been fixed.

In T13709#242608, @jjazeix wrote:

I think I manage to reproduce (at least I have one reproducible case). If you finish a game against Tux, then spam the "undo" button until the beginning, you can't press the redo button again (it will disappear and do nothing)

I tried following your directions, but I can't reproduce the bug. Do you care enough about this to have me verify it? I am not too concerned about it, but I will try to verify if you want.

Oh, yes. Of course. I should have been looking at the commits in the KDE/1.0 branch. Silly me.

Indeed. I was exiting via the Home button. I instantly reproduced it when exiting via the the escape key. I will verify soon.

The commits have a different numbers depending on the branch... the same commit in master is a096de49.

Ah, I forgot to precise in my explanations to reproduce: you need to exit the activity using the escape key.
Using the Home button from the bar already had the fix to prevent the bug to happen.

In the head of the KDE/1.0 branch (commit 66d621)...

I tested on commit 3be from Oct 1

Well at least I could 100% reproduce the bug you described with the steps I explained, and then I understood from the code why it could happen and made a fix to make sure it should not happen anymore...
On which version did you try to reproduce? (old build from KDE/1.0 branch from before Oct. 8th or newer ?)

I tried following your directions, but I can't reproduce the bug. Do you care enough about this to have me verify it? I am not too concerned about it, but I will try to verify if you want.

I think I manage to reproduce (at least I have one reproducible case). If you finish a game against Tux, then spam the "undo" button until the beginning, you can't press the redo button again (it will disappear and do nothing)

... And bug fixed :)

Oh, I just found how to reproduce this bug!

In T13715#241862, @tysonwilliams wrote:

Actually, here is an argument for currently spamming the undo button.

After one of my 6 year olds finishes a chess game, he often wants to show it to me. To do this, he "spams" the undo button until the game is in the initial state again. Then he slowly clicks the redo button while giving me play-by-play (i.e. "Then I moved my queen. Then he moved his king. Then I thought, I should get another queen, so I moved this pawn. ...)

He wouldn't have to spam the undo button if there was also an "undo all" button.

In T13715#241861, @tysonwilliams wrote:

There is no reason to spam the undo/redo buttons

My kids encounter so many bugs in Ubuntu by violating assumptions like this, and I never know how to reproduce the problem. This is especially true of my 4 year old. He can't read yet, so he uses trial and error to figure out how to make modal dialogs disappear (and I don't have speakers on the computer they use, so he can't use audio clues either). As I watch them nativage around, I imagine if I were the one that created the program, and I constantly think to myself, "Oh, I would never have tested that type in interaction".

Actually, here is an argument for currently spamming the undo button.

There is no reason to spam the undo/redo buttons

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

Can reproduce this time :).
I'll add a small timer before being able to click again the button.
There is no reason to spam the undo/redo buttons

Hi,
thank you for reporting.

Indeed it is. Great work :)