After further investigation, it appears that the problem is in line
104 of /usr/share/gcompris/python/tuxpaint.py, which looks like this:
gcompris.sound.close()
Commenting out that line (and deleting the tuxpaint.pyc file) "fixes"
the problem in that it allows tuxpaint to run instead of hanging.
However, gcompris's music continues to play. A better fix, would be to
pause and resume the music, like so:
--- tuxpaint.py.orig 2006-12-15 14:44:51.000000000 -0800
+++ tuxpaint.py 2008-01-30 16:55:05.000000000 -0800
@@ -101,7 +101,7 @@
if eval(self.config_dict['disable_stamps_control']):
options.append('--nostampcontrols')
- gcompris.sound.close()
+ gcompris.sound.pause()
# release pointergrab if running fullscreen, tuxpaint wants to grab the
# pointer itself
@@ -137,7 +137,7 @@
)
def end(self):
- gcompris.sound.reopen()
+ gcompris.sound.resume()
global pid
# force kill - data loss
if pid != None:
It appears that Debian Stable's default sound system, ALSA, allows for
multiple access to audio devices, so closing the device is not
necessary. However, I could be wrong.
--b9
On Jan 30, 2008 4:42 PM, <[EMAIL PROTECTED]> wrote:
> This is still a problem in Debian Stable, which uses GCompris 8.2.2-1.
> If Debian Unstable has a fix, it would be nice to backport it as it
> breaks my heart to tell kids, "Whatever you do, don't click on the
> picture of the penguin with a paintbrush. It'll crash the computer!"
>
> Perhaps of interest, this bug does not occur when gcompris is run with
> sound disabled using the -m (mute) switch.
>
> --b9
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
