On Wed, 20 May 2026 15:41:19 GMT, Martin Fox <[email protected]> wrote:
> There's now a call to query a backdrop for its supported options. The call > for setting an option has been moved to Stage since you can change the value > at any time. That call is currently a no-op since the only backdrop that > supports options is macOS.ClearGlass and it's not available. Hooking this up > isn't rocket science but is a bit tedious so I'm putting it off. Having `setBackdropOption` be a method on `Stage` seems to be a very loose-fitting API; for me, a backdrop option is a property of a backdrop (as the name implies), not a property of a stage. The canonical pattern to define properties on an object that are only meaningful in the context of another object is an [attached property](https://github.com/openjdk/jfx/pull/2015). However, I don't think that this is a good fit when the natural carrier for this API is `StageBackdrop`. Maybe you moved backdrop options to `Stage` because that allows `StageBackdrop` to essentially be an immutable key that identifies a backdrop. But it also clearly suggests to me that if the configuration of a backdrop is dynamically modifiable, it can't be an immutable object at the same time. I don't see a huge problem of having `StageBackdrop` be a mutable object. The only sharp edge is the two standard backdrops, which are static constants and should therefore be intrinsically immutable. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-4568293986
