Add a system property to disable beep sounds

[laeubi]

Is your feature request related to a problem? Please describe. Currently the Display has a way to emit a "beep". In some case an application might not want this to happen regardless of what library code calls this.

Describe the solution you'd like We should have a system property (e.g. swt.beep) to control that behavior, it should be assumed to have the value on and off (where no value is interpreted as on) and then completely inhibit beep sounds.

Describe alternatives you've considered Turn of the speaker or configure the OS to not play sounds but these are rather not acceptable workarounds.

Additional context This needs to be implemented across all the different OS variants of Display.

[mickaelistria]

In some case an application might not want this to happen regardless of what library code calls this.

Using beep() is usually an anti-pattern; and a more standard way to achieve it is using System.out.println((char)7). We could consider deprecating/removing such API, and looking for consumers to replace the bell by a Log. Did you identify which bit of code still call Display.beep() ? Note that such option already exist at OS level usually: https://linuxconfig.org/turn-off-beep-bell-on-linux-terminal / https://onelharrison.medium.com/how-to-mute-the-windows-terminal-bell-fee86af19ddb , and fixing it as OS is probably enough and better than adding an option to SWT.

So overall, I don't think this should be yet-another-option for SWT/Eclipse, but more Eclipse deprecating its usage, avoiding it and replacing it with the standard System.out.println((char)7) which should better honor the OS settings.

[HeikoKlare]

So overall, I don't think this should be yet-another-option for SWT/Eclipse, but more Eclipse deprecating its usage, avoiding it and replacing it with the standard System.out.println((char)7) which should better honor the OS settings.

I agree. As far as I know, using the bell (no matter whether via character 7 or any means like the Display#beep() OS calls) is usually discouraged today. When working on the in-document find/replace UI last year, we completely removed it there according to:

• https://github.com/eclipse-platform/eclipse.platform.ui/issues/1908

So in my opinion, deprecating this functionality and replacing its usages would be the best forward. If someone really needs it, System.out.println((char)7) will still be available.

[laeubi]

Did you identify which bit of code still call Display.beep() ?

At least 75 references are shown in platform/jdt code ... if we agree that Display.beep() should be deprecated I would say we should:

1. Deprecate it with notice to use and mention System.out.println((char)7) as alternative
2. Make it a noop so it simply do nothing from now on

This will then improve the situation already for existing code until they adapt.

@mickaelistria @HeikoKlare would you be fine with that?

[mickaelistria]

Deprecate it with notice to use and mention System.out.println((char)7) as alternative

OK

Make it a noop so it simply do nothing from now on

I don't think it's a good idea. People who invoke beep() for good reasons (if they are any) should get a beep; and we shoudn't change the very substance of this API.

[HeikoKlare]

Agree with what Mickael wrote. For the deprecation it would probably also be good to clean up the SDK code first, i.e., to replace the usages of the API to deprecate, wouldn't it?

[laeubi]

Given the discussion in the PR I don't see any deprecation here or "better" beep sounds advice honestly. It brings no value for me and there is no agreement to remove beep altogether.