2009/7/8 Viktor Griph gr...@dd.chalmers.se:
* 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
