gnome alert sounds under fvwm?

Configuration General Questions
1

I’ve been trying to get echo -e '\007' (or something like it) to work.

With the usual Gnome (version 2.28.0) and Metacity WM, the above
command produces the “alert” sound that is set in System–>Preferences–>Sound.
(This works for gnome-terminal, but not for xterm, not sure why it does not work—any thoughts?)
One also gets an alert sound for lots of other actions, like hitting the backspace key
when there is nowhere to backspace to etc.

But if I replace the Metacity WM with fvwm (using fvwm --replace & ) I can’t seem to
produce any alert sounds at all. Nothing from echo -e '\007' or any of the other
sounds that are played when the Metacity WM is used, e.g., those that are in
/usr/share/sounds/gnome/default/alerts. My pc speaker works fine (e.g. it beeps
when I boot the machine), but I can’t seem to get either it or the gnome sounds to
speak to me. I can play the “alerts” files fine with /usr/bin/play, and in general the
sound system works fine, e.g., nice bluegrass from worldwide bluegrass through xmms.

Any thoughts for how to get alert sounds with fvwm, either the normal beep from
the pc speaker or by playing some sound file such as gnome does?

I’m running fvwm version 2.6.1, with my recently installed Scientific Linux 6.0 OS.

– Peter

2

Ah – you’re assuming the window manager (FVWM) is responsible for this. It isn’t.

My PC doesn’t have an internal speaker anymore, and as such, I instead use a linux kernel module from here:

carcosa.net/jason/software/beep/

… and then use:

alsabeepd.py

from the same package above. I’ve put in ~/bin – although don’t forget to set the permissions on /dev/beep appropriately for non-root users.

In the alsabeepd.py file, the only thing I ended up doing was changing the definition of “BEEP”.

HTH,

– Thomas Adam

3

Well, I am still struggling to get some kind of “alert” or “beep” sound in response to, say, a ‘cout << “\007”’ in a C++ program, or even (as I’ve mentioned earlier), anything like ‘echo -e “\007”’ issued from either a gnome-terminal or an xterm.

I did build and install the “beep” program (beep version 1.3), and it works, but it is not terribly useful since it relies on a call to ioctl etc., rather kludgy to replicate in a C or C++ program (although presumably possible). Of course I’ve ensured that the “pcspkr” module gets loaded at boot time. (Otherwise the “beep” program would not work.)

Also I don’t want to have to revise every piece of code that might incorporate alerts or beeps. For example, the clamav package has the “clamscan” command, which if one says, say,

clamscan -r -i --bell /home/peter/Mail/spam

no beeps or other alerts are heard when a tainted file is found, in spite of the “–bell” option being given. (This used to work for me, when I had a gnome version earlier than my current version, which is 2.28.0, but it no longer works.)

So I am still wondering if there is a simpler way to do it. I did play around a bit with McBrayer’s “Fancy Beeper” kernel module, but I could not get it to work, even after perusing comments from Thomas Adam (and offline, from Akkana Peck).

There is also a very long discussion in a Ubuntu forum

(bugs/launchpad.net/bugs/486154)

but this discussion ends without resolution of the problem.

While I understand this may not be an FVWM issue, I am still wondering why alerts work for metacity (at least with gnome-terminal) but not for FVWM. I’m not sure whether it’s a problem with gnome, or the window manager, or pulseaudio, or the kernel, or what.

Any further guidance would be most welcome. Even if I don’t want alerts or beeps, I would at least like to have some control over them. If someone has recent experience with getting McBrayer’s “fancy beeper” kernel module to work I would love to hear the details. I am not an experienced daemon writer.

Thanks,

4

My guess is that gnome-terminal (and most other Gnome applications) pass these kinds of events to gnome-settings-daemon and not to the underlying OS. I’m guessing metacity is built with Gnome support and does so as well. Killing gnome-settings-daemon might be a way to find out whether it’s responsible (but then again, that is just an educated guess on my side, it might be some other part of Gnome handling these events).