2009/7/8 Viktor Griph <[email protected]>: > * 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.
I would step back a moment and consider the possibility of how useful still supporting librplay is. I know it's tangental to what you're asking -- and I will get back on topic in just a moment, but librplay sucks! The growing trend is pulseaudio, although this would penalise people on archaic installations of SunOS 3.2 -- shame. Given that I would put any amount of money on the fact that the number of people using rplay with FvwmEvent -- *AND* who are following FVWM 2.5.X, changing it to yor former suggestion isn't likely to bite too many people. > * 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. Agreed -- although pre-supposing ordering in this way is wrong -- I should be able to specify something like this: *FvwmEvent: new_desk NopNop *FvwmEvent: Cmd Function ... and not care as a user that "Cmd" should come before anything else; (c.f. FVWM 1.X requiring a strict order of InitFunction, etc. -- not good.) > 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. Well, I would still go with the assumption that breaking rplay "compatability" here is safe. The idea of sounds on actions is very 1995 -- again, the number of people using it will be next to nil -- so I think it's safe to code this with an eye to breaking rplay options here; or just separate the two out: CmdSound Cmd Or something. If that makes sense, great. :) -- Thomas Adam
