This can be applied to a number of other cases as well, when an operation, being impossible or not applicable in the current conditions, is silently ignored without any feedback.
these are a couple of examples; more exist, but I honestly cannot recollect them at the moment.
*) in a TAB, raising or lowering a note out of the range possible on that string or out of the instrument range (possible on a pitched staff, not possible in a TAB as such a note canot be assigned fret marks)
*) applying a clef not compatible with the staff group (the original post is one case of this)
The feedback could range from an error dlg box (like the one displayed when attempting to create a frame with no measure selected, probably best left for major issues) to a simple 'di-du' sound: anything which gives the user a clue of what is happening is welcome; a 'failure' sound is however common in many applications.
I agree it is an issue bordering between the bug report and the feature request but, being a not marginal 'hole' in the UI, I think it qualifies fairly well as a bug.
If some basic functionality is provided by the core developers (like a global warningSound() or genericWarning() function), adding specific calls to it can be left to peoples dealing with individual code sections.
In the meantime, it has been ascertained that an aural feedback (a 'di-du!" sound or similar) cannot be implemented in a platform independent way (at least under Linux the ALSA (or equivalent) transport continuously running in background stops any system sound generated by the application).
However, I still maintain the point has some importance, as a non-marginal 'hole' in the UI. Ideas for alternative ways to provide a feedback to the user for ignored or failed operations are welcome!
Comments
This can be applied to a number of other cases as well, when an operation, being impossible or not applicable in the current conditions, is silently ignored without any feedback.
these are a couple of examples; more exist, but I honestly cannot recollect them at the moment.
*) in a TAB, raising or lowering a note out of the range possible on that string or out of the instrument range (possible on a pitched staff, not possible in a TAB as such a note canot be assigned fret marks)
*) applying a clef not compatible with the staff group (the original post is one case of this)
The feedback could range from an error dlg box (like the one displayed when attempting to create a frame with no measure selected, probably best left for major issues) to a simple 'di-du' sound: anything which gives the user a clue of what is happening is welcome; a 'failure' sound is however common in many applications.
I agree it is an issue bordering between the bug report and the feature request but, being a not marginal 'hole' in the UI, I think it qualifies fairly well as a bug.
If some basic functionality is provided by the core developers (like a global
warningSound()orgenericWarning()function), adding specific calls to it can be left to peoples dealing with individual code sections.Thanks,
M.
BUMP-ing...
... and adding more info.
In the meantime, it has been ascertained that an aural feedback (a 'di-du!" sound or similar) cannot be implemented in a platform independent way (at least under Linux the ALSA (or equivalent) transport continuously running in background stops any system sound generated by the application).
However, I still maintain the point has some importance, as a non-marginal 'hole' in the UI. Ideas for alternative ways to provide a feedback to the user for ignored or failed operations are welcome!
Thanks,
M.
Flashing the screen?