While reading the FvwmEvent source code I've noticed several issues with it's configuration system that needs fixing. However I'm not sure what the best fix is for all the issues, so I'll start by listing the issues:
* RPlayVolume and RPlayPriority is not honored at all. They are defined in handle_config_line, and chnges to the values are not stored at all. There are two possibilities for fixing this: Either let the values set the volume for all sounds, or let them be changable from top to bottom in the configuration. Since FvwmEvent doesn't support dynamic reconfiguration the differenc isn't that big, but in the later case it would be possible to set different priorities and volumes for different events, while in the former that won't be possible. On the other hand, the later will require the volume and priority to be specified before any events in the config, while the later could have it anywhere. * Tied to the above issue is also the interpretation of the Cmd option. Right now it is only applied at the end of the configuration process, which would be similar to select that volumes and priorities only should be applied at the end of the configuration. However I still think that in a sane configuration it should be specified before the actual events, but changing that might break configs which define a Cmd after the events. (But there is still no dynamic reconfiguration possible, so if you have a bunch of sound events specified you can't not change the command used to play the sounds for a running FvwmEvent anyway. Appart from thet there is the basic issue that the configuraion parsing system is fragile with respect to the module protocol, and I would like to fix that by reimplementing parts of the configuration parsing and event handling to not break if there isn't an event defined fo all messages. I can't descide what the best approach to the options Cmd, RPlayVolume and RPlayPriority should be. Cmd can be left as is, and only the most recently specified Cmd applies, however builtin-rplay and other Cmd:s are handled in so different ways, that it would be good to know if an event is for rplay or from a standard Cmd at the time it is parsed, and especially not have to be able to change between to two types as the user sends a new module configuration command to fvwm. Any input on this would be good. /Viktor
