Notices

Thanks Aapo, latest version starts without dreaded explore.py:545 error. My son already likes you for that

Upstream changed something, or it was maemo-specific fix, that need re-applying again? As it's affecting all touch-screen devices, maybe it's worth to send our fix to mainstream after re-applying? They may be interested in upstreaming.

Apart from hardware keyboard remap made specifically for gCompris to map right shift somewhere (that could be even loaded at gcompris startup, and unloaded when it exits/crashes/whatever - would require wrapper script, I can prepare one if no better solutions is found), maybe it's possible to slightly modify this game for Maemo only? I.E changing expecting shift_r to right arrow, or something like that?
---

Under science->electricity, we have one of most interesting activities - drawing circuits with live-reaction, calculated transparently via gnucap. Hoever, vanilla installation of gCompris doesn't depend on gnucap, so gcompris throws info, that this activity won't work as intended (will allow to just draw circuits, without them coming to life).

After installing gnucap manually, from Maemo repos (also uploaded by you Aapo - thanks, again!), it works as it should. Maybe it's good idea to add gnucap as dependency? BTW, could you update gnucap to latest mainstream versions (if it's not up-to-date - I had problems fetching this particular package's uploading date).

Also, there is minor problem - some functions (like "breaking" bulb, to see how it affect circuit) are accessed by right-clicking on component. Interestingly enough, despite fact, that I have system-wide bind for right-click as bluearrow+tap (via xbindkeys and xdotool), it doesn't work - gCompris ignores X thingies? No matter what, I wonder, is it fixable?

This one is strange - it shouldn't be Maemo-specific, yet, it seems to be. Do we know, what causes it?

/Estel

These games are broken.
Find the correct coloured duck
Find the correct coloured butterfly
Find the correct instrument
-> Text is "find the {text}"
(they are using string.format() from python2.6 and these rows, with {}, are coming from translation files.


I don't know have this worked ever with touch devices. I have mentioned this to the upstream, and they are waiting me to fix it.

I think this is the easiest approach.

Gcompris uses three external application: tuxpaint, gnuchess and gnucap. For some reason gnuchess is mandatory and others are suggestions.

Gnucap on Maemo is same version what Debian (wheezy, jessie, sid) is using. Seems there are some development version of gnucap in upstream, but I think we stick same than debian.

There should be some general solution for touch devices. I'm afraid that fixing mapping respecting is too tough.


I don't have ideas yet.

That double letter thingy - could it have something to do with how Maemo translates long key presses to the keys' blue shift equivalents? I sometimes get that same translation on double presses in applications like FAM while it is busy sorting.

Noticed strange thing - my "blue_arrow+ tap = right click, shift + tap = middle click" is actually working in gcompris "footbal" (where you have to double click right to shot ball into right corner, double left to left corner, etc), but in a strange way. I need to repeatedly "bash" both blue_arrow and tapping for getting right click.

Also, in falling letters, it's not only problem with words containing double letters - if we play variant where single letters are failing from sky, everything works OK, *unless* there are failing 2 same letters in row. For example, for two failing "O"s, only first get registered.

But, If if purposely hit wrong letter between two "O"s, I can clear them both. Of course, it doesn't work with words, as hitting wrong one reset word progress.

Summing it up, it seems to me, that keys become "sticky" upon pressing - when we hit "O", for example, it seems to me, that gCompris thinks "O"s got pressed and is *still pressed down*, without being released,

I think that it applies to all keys, which aqlso explains my problems with <any_key>+ tap for right and middle click. In most games, it don't matter, but in failing letters/words, it spoils results.
---

Keep in mind that it is just my asumption, as I have no idea how to confirm my suspicions. Also, while writing text in gCompris's simple text editor, no such "sticky keys" (or any other problem with letters) is present. But, it may use different method for processing text input (like with using tuxpaint for drawing, in few games).

/Estel

My kids love playing with this gcompris. Thanks for the great work Aapo, keep it up. Will ask the kids if they find any more bugs.

@estel
Could you please direct me to where you installed the gnucap from. I can not find it on FAM. Thanks.

It's section was not user/ . (You need to enable something "show all packages"). It is now fixed and will be someday on repository too.

Meanwhile I have tinkered broken games and some of them are fixable.

Thanks Aapo, installed gnucap and works well, but I have a problem of no sound. Its activated in config menu, and all the sound files are in /home/opt/gcompris/share/gcompris/boards/sounds. The sounds used to work but stopped a while ago when I upgraded. Let me know if you have an idea what could be wrong else I'll wait for next upgrade and do a complete removal and a clean install.

Keep up the good work mate.

It might relate package named libsdl-mixer1.2. Use terminal to check installed version of it:
It should be Installed: 1:1.2.6-5+0m5+ogg+mp3-2.

Yes Aapo, I have the correct version of libsdl-mixer1.2 installed.