GCompris split source

Problems

Source of GCompris is to big. This is a problem for translators, they have to download all the source to get their up to date file to translate.

Binary packages are also too big. We already have separated sounds package but the data package is also big. We should find ways to provide users with limited disk spaces (embedded, live cds, main distro cd)

Solution

Split GCompris.

• GCompris compilation part, with all xml.in (they needs translation too) and all xml file for wordlists. This part has to include all the translations of gcompris (probably without sound files).
• GCompris data: all images and others data mandatory to run gcompris. skin, no skin? no skin!
• GCompris non translated sounds ? that could make easy an installation without sound files, e.g if computer has no soundcard.
• GCompris skins: can be packaged separately. Probably should. To make possible a minimal installation for livecd.
• GCompris translated sounds: are packaged separately by debian/ubuntu. We should do the same. English sounds are fallback if others are not found, for click_on_letter: we should add such callback in others boards (colors, gletters, smallnumbers).

How

• use package-config in data packages to know where main gcompris package is installed ? with a compilation option to force install everywhere, that's mandatory for deb/rpm packagers.
• add check in gcompris start to ensure data, skin and sounds are installed.
• add a global option like /etc/gcompris/gcompris.conf ? that should make possible a global default skin choosed when skins are installed. Anyway it should contains the default db location too, if db is shared between multiple users.

Creating specific dataset

We need to provide distro builder, livecd, embedded systems a way to create a GCompris dataset that suits their needs in terms of content selection and resulting size. For example, on a live cd for small children like freeduc cd, we may choose to put only level 1 to 3 and so save room for other apps.

To provide a nice level of flexibility, we need to know which activity need which sounds and images. The best place to keep this information is to put it in the activity menu files. More, to be sure it's uptotime, we should enforce that boards only access images and sounds by refering to it.

Once we have this, we know on a per activity basis exactly what it needs and so what space it takes. We can then create tools to let packagers select activities and see in real time what space it takes.

This has another advantage, we can easyly check at runtime if we have the necessary content to let the user run an activity.