Add system property to disable beep sounds

[Copilot]

Overview

This PR implements a new system property swt.beep to control beep sound behavior in SWT Display across all platforms (macOS/Cocoa, Windows/Win32, and Linux/GTK).

Motivation

Currently, the Display class provides a beep() method that emits a system sound. In some cases, applications may want to disable these beep sounds regardless of what library code calls this method. Previously, the only workarounds were to mute the system speaker or configure OS sound settings, which are not acceptable solutions for many use cases.

Implementation

The implementation adds a public static boolean field that is evaluated once at class initialization:

• Property name: swt.beep
• Field: public static final boolean BEEP_ENABLED
• Accepted values:
  • "off" (case-insensitive) - disables beep sounds completely
  • "on" or any other value - enables beep sounds (default behavior)
  • Not set - enables beep sounds (default behavior)

The property is evaluated once when the Display class is loaded, not dynamically on each beep call.

Changes per platform:

macOS (Cocoa): Added BEEP_ENABLED field and modified beep() to check it before calling OS.NSBeep()

Windows (Win32): Added BEEP_ENABLED field and modified beep() to check it before calling OS.MessageBeep(OS.MB_OK)

Linux (GTK): Added BEEP_ENABLED field and modified beep() to check it before calling GDK.gdk_display_beep()

Usage

# Disable all beep sounds
java -Dswt.beep=off MyApplication

# Enable beeps explicitly (same as default)
java -Dswt.beep=on MyApplication

Note: The system property must be set before the Display class is loaded, as the value is cached at initialization.

Benefits

• User control: Applications can disable annoying beep sounds via configuration
• No code changes required: Existing applications can control beeps via JVM arguments
• Accessibility: Helps users who find beep sounds disruptive or inaccessible
• Testing: Makes automated testing quieter and less intrusive
• Backward compatible: Default behavior unchanged - existing applications continue to work as before
• Performance: Property evaluated once at class load time, no overhead on beep calls
• Public access: The BEEP_ENABLED field is public, allowing external code to check if beeps are enabled

Implementation Notes

• Minimal changes - only modified the beep() method implementation and added a public static boolean field per platform
• Property evaluated once at class initialization (not dynamically)
• Consistent across all three OS variants
• No performance impact - simple boolean check on beep calls

Fixes #

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add a system property to disable beep sounds</issue_title>
<issue_description>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.
</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #2613

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[laeubi]

@copilot the evaluation of

!"off".equalsIgnoreCase(System.getProperty(BEEP_ENABLED))

should be stored in a public static boolean field, we do not need to change it dynamically.

We can also remove the testcase, this can not be tested automatically.

[Copilot]

@copilot the evaluation of

!"off".equalsIgnoreCase(System.getProperty(BEEP_ENABLED))...

Done in commit e9c2a1d. Changed BEEP_ENABLED to a public static boolean field initialized with the property evaluation. Also removed the test cases as requested.

[github-actions]

Test Results

104 files   -    11  104 suites   - 11   8s ⏱️ - 11m 3s
 80 tests  - 4 466   80 ✅  - 4 450  0 💤  - 16  0 ❌ ±0 
255 runs   -    56  255 ✅  -    53  0 💤  -  3  0 ❌ ±0 

Results for commit f1622e5. ± Comparison against base commit 6fa4ee7.

This pull request removes 4466 tests.

AllWin32Tests ImageWin32Tests ‑ testDisposeDrawnImageBeforeRequestingTargetForOtherZoom
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ testImageDataForDifferentFractionalZoomsShouldBeDifferent
AllWin32Tests ImageWin32Tests ‑ testImageShouldHaveDimesionAsPerZoomLevel
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromCopiedImage
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromImageForImageDataFromImage
AllWin32Tests TestTreeColumn ‑ test_ColumnOrder
…

[vogella]

Why not use off as default?

[merks]

Just because we (personally) decide we don’t like beep enough to add a system property to disable it completely should we really decide that to be the new default for everyone? It’s arguably not even for everyone’s safety and comfort. It’s more of a preference. I generally turn my speakers off when not using the them. So I don’t personally care, but I also see no reason force a new default on everyone else.

[laeubi]

Please see general discussion here:

• Add a system property to disable beep sounds #2613

[merks]

Yes I saw that. I don’t agree. A system property does no harm. Defaults are a different story, hence my comment here. Deprecation would be a different PR.

This seems to have shifted from one topic to another where there appears now to be a compelling reason for enforcing correctness on everyone. That seems questionable to me, and I hate my computer making noises.

[laeubi]

@merks I would be fine with either way, I'm just sick of people complaining my application has "bugs" while it is a "feature" of platform ;-)

So @merks @vogella it would be good to leaver you concerns or support at the issue so we hopefully can came to a conclusion there and I'll create a PR with whatever decision is taken there.

[vogella]

I'm in favor of a "non-annoying" default—therefore, no beeping. I have yet to meet anyone who actually likes applications that make beeping sounds. When I use Eclipse with sound enabled, people regularly ask me to mute my computer.

I believe we should choose reasonable defaults for Eclipse once we identify an issue, rather than fixing it in a way that only experts can handle (such as through obscure properties).

That said, having such an option is still better than nothing, so I’m not blocking progress either way.

[merks]

Wouldn't it better to literally have a sound option in the preferences? E.g., like this is Thunderbird?

An application could enable or disable it by default just like for any other option. And such an option would be discoverable.

[BeckerWdf]

An application could enable or disable it by default just like for any other option. And such an option would be discoverable.

I like this proposal.

[mickaelistria]

I don't think we should make Display.beep() a no-op. Display.beep() should still beep. But we should maybe mention in the documentation (and maybe related deprecation note) that this is not recommended and has standard solutions (System.out.prinln((char)7) that are to be preferred.

IMO, all calls to Display.beep() in JDT need to be replaced by either no action (if beeping means "nothing to do"), or a regular logging (if we actually don't want to interrupt user) or alerts (if this is a problem worth alerting users).

[laeubi]

An application could enable or disable it by default just like for any other option. And such an option would be discoverable.

I like this proposal.

Well the system property is a kind of "preference" for the sake of SWT as a library that can run without OSGi and especially without Eclipse.

Nerveless of course we can also have an API to toggle the switch so it can than be used in a preference dialog (even though I would not bother to implement such feature)... but sad enough now discussion has moved to this PR (what is only *one possible way to implement it) instead of taking place in the initial issue, but anyways it does not matter to me if we come to a conclusion somehow.

So to summarize we have:

1. no general agreement that beep() should be a no-op or should go away so I think deprecation is not an option
2. there is some kind of agreement that it can be useful to disable beepsounds on application level maybe even configurable by the user.

So my suggestion would be now:

• by default let be everything as-is
• have a system property so the users are free of choice to disable it for any SWT based app via usual means
• have an API method Display#setBeepEnabled(...) that allows to control the behavior through e.g. preferences and make it easier accessible to the user
• We decide on some places where beep is used in application code if it is really usefull to call the method at all.

[mickaelistria]

I would favor "We decide on some places where beep is used in application code if it is really usefull to call the method at all." (and basically for JDT we get rid of about all calls to beep() which are often coupled with change to StatusLine https://github.com/search?q=repo%3Aeclipse-jdt%2Feclipse.jdt.ui%20.beep()&type=code (and if some people want them, they add new preference to enable them where it makes sense)

[laeubi]

@mickaelistria this still does not solve it for other plugins and I want something that only depends on SWT... if JDT or others ever move ... who knows? Can I convince every SWT lirary to adapt and offer me preferences? Likley not... Do I want to maintan a lot of preferences in my application instead of setting one system property? Likey also not managable.