sol1-matt
commented
2 years ago I think @davekempe has some dashboards that make use of sound, I'm not sure if that is per element, any elements or some elements.
I think the different use cases for per element sound is
- only some elements make sounds (the ability to play the same sound on some elements only)
- different elements require need different sounds (the ability to choose different sounds for different problems)
- different levels require different sounds (the ability to have a different sound for each state)
- A combination of the above (eg: some elements play sound with different sounds per level).
I'm not sure what is required for current production environments, I'd assuming feature regression would make somebody unhappy, but in terms of code I'd like to see sounds moved to something generic that can be applied to any element that holds state, a similar concept to #104 .
Is this feature used? Is this a feature we want to support? I can imagine some use cases where the sounds could be different per dashboard (if I squint hard). But per element?
There are big simplicity wins in assuming sounds. In short, there's less state to be passed down from default to dashboard to element, to JSON, to backend, to disk. There's a lot of code which could just be deleted rather than be refactored.
Supporting this level of customisation is to me, like supporting custom visual Meerkat themes. We could implement it - there's loads of themes at https://bootswatch.com/ - but the additional complexity, especially when it's not implemented particularly well, holds feature development up and makes it even harder for the community/contractors to participate.