All features completed, bugs fixed, and thoroughly tested.
@jjazeix can you please merge it to master ?

I added a note about this in gcompris-data repository ( https://cgit.kde.org/gcompris-data.git/commit/?id=e0537083aebc8136c123cfe4094d43ccdb43bd30 ).
Let's keep those images a little longer for retro-compatibility with pre-0.95 versions of GCompris.

@jjazeix @timotheegiet AFAIR, I once experimented with adding metadata to a piece of music and yes, it gets lost when converted to other formats. If we can extract the metadata in the conversion script and add it back once converted, it would be nice.

So, getting back on this, this is the checklist of things to do:

1. Fix bug: if starting GCompris with music disabled, enabling it doesn't work (no music played) until restarting the application.
2. Add volume slider for background music and audio effects.
3. Display the author and license info of each track.
4. Consider the format of the music according to the platform.
5. Add unit test for the ApplicationSettings changes.

All rcc files updated on the server with proper tags (artist, title, year and copyright in comments) :)

For the copyright info I'll add them in the COMMENTS tag.

Indeed, here I found a way to transfer metadata to aac using id3v2 command line, at least for ARTIST, TITLE and YEAR.
This should be usable for mp3 too, I'll update the script accordingly.

it does not seem to be the case. I updated the script to keep metadata from ogg to mp3 conversion, but didn't manage yet to find something for aac :/

Thanks, I'll add the tags to ogg files; I've read ffmpeg should keep them during conversion by default, I'll double check and update the rcc on the server.

https://doc.qt.io/qt-5/qml-qtmultimedia-audio.html#metaData-prop
Audio can be tagged using:

vorbiscomment -w colors.ogg -t "ARTIST=Gregoire Giet" -t "TITLE=colors" -t "COPYRIGHT=CC-BY-SA 3.0" -t "DATE=2011"

I updated the music set on the gcompris-data repository, and uploaded the .rcc files to the server.
Let me know if you find any issue with that new set.

Can you add a unit test for the ApplicationSettings changes?
I did one new comment in https://phabricator.kde.org/R2:d3224edb5edc6f21dab3880351e11683f9e60a99
At some places, can you take a look if you can use algorithms instead of while/for loops (using filter for example if it works to do the difference between filtered music and all music)?

That's great to hear! :D

Tested quickly, it seems to work fine.

The final feature is done as well!
Further steps:

1. Needs testing by other members.
2. Discuss more features if needed.
3. Update music names on the server.
4. Update the design if required.
5. Probably merge in master for next release, if possible.

The feature to filter background musics and save/load them to play is implemented. At present, the changes get into effect after the software is restarted.
Next thing to do is to dynamically change the playlist in GCAudio element for background music to make the changes get into effect immediately.

1. Yes, the overall design can be improved (I think @timotheegiet would surely do it better once it's ready to be merged ;)). I just used the current design to check the working first.
2. I'll go on to implement the point #3 now.
3. For the file names, yes, me and @timotheegiet had discussed it on IRC few days back and he'll probably look at it next week :)
4. Sure, I'd also prefer to rebase it on master before proceeding to #3 and make other changes in the commit as per your comments.

Hi, thanks for the update. The design needs to be improved: we should not use a button to display the actual music (except if you plan to use it to select the playable pieces of music (point 3)). We'll also need to clean up the filenames so we have something understandable displayed.

Points 1 and 2 are done. Kindly test the branch for the above-linked commit.

Thanks, I tested again and can not replicate those issues anymore.
Good for me, waiting for @scagarwal and @amankumargupta to confirm it's ok for them too.

@timotheegiet Thanks for the review, I've updated the diff trying to resolve all the issues, can you try it out once again :)

• calendar, resolve minor bugs

I tested the patch on multiple_dataset branch, and noticed several issues.

last MR to be pushed: https://gitlab.com/fdroid/fdroiddata/merge_requests/5129 but GCompris is already in the store now

• calendar, add full date format in find the day questions

• add comments, remove unnecessary variables

• enclose strings in qsTr

• change file copyrights

• add tutorials

• enclose strings in qsTr

• Calendar, add dataset configuration documentation comments

• Calendar, add DialogChooseLevel to activity
• Calendar, improve date formats

• Merge branch 'gsoc_akshaychd_calendar_multiple_datasets' of git.kde.org:gcompris into gsoc_akshaychd_calendar_multiple_datasets

• find_the_day, add multiple datasets

https://commits.kde.org/websites/gcompris-net/5f862f4d1f2e986d2d6784d7ee9136fe0b581b08 removed the dependency for the language list

This is all fixed now, closing as Resolved.

Features to be added:

1. Show the currently playing music in the main menu config dialog.
2. Have a left/right arrows to switch between music.
3. Have a menu like filter from which the user can select only the musics he wants to play.

Yes sure, greying them in the list as "inactive" is what I meant by disable them. Just needs to add a reminder there that those are disabled by the global filter.

"-The only thing that should prevent the user to select a certain difficulty of dataset should be the global difficulty filter (in which case we must display a message to indicate those are disabled by the active filter)." -> or simply "grey" them and put them inactive so that people still know that more difficult objective can be achieved if you change the difficulty level?

@echarruau :
-This "maximun difficulty selected" entry was initially just meant as an info of what is currently selected in the list. Maybe we could also use it as you suggest to auto-select a range of activities, but this should be better handled by the global difficulty filter (the one we already have).
-The only thing that should prevent the user to select a certain difficulty of dataset should be the global difficulty filter (in which case we must display a message to indicate those are disabled by the active filter).

Hi,
Very nice!
Two questions:

• Will the user be able to change the level difficulty by pressing the Maximum difficulty selected entry button? This would be a nice and easy way to change it if needed?
• Will the user be able to choose a dataset that is has a difficulty level higher than the maximum difficulty level? Exemple in this case will the user be able to clieck on Table de 6?

Great job

The mock-up is here : https://phabricator.kde.org/M146