On Thu, 7 May 2026 19:50:37 GMT, Michael Strauß <[email protected]> wrote:
>> Martin Fox has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains eight commits: >> >> - Merge remote-tracking branch 'upstream/master' into osbackdrop >> - Backdrops are now objects created by specifying a material. The >> list of materials is now open-ended. >> - Merge remote-tracking branch 'upstream/master' into osbackdrop >> - Merge remote-tracking branch 'upstream/master' into osbackdrop >> - Merge remote-tracking branch 'upstream/master' into osbackdrop >> - Removed unused import >> - Merge remote-tracking branch 'upstream/master' into osbackdrop >> - OS supplied translucent window backdrops > > The proposed API feels very stringly-typed, and I'm not sure if that's a good > model. Specifically, I'm looking at future enhancements that expose > configuration options which are available on some > [platforms](https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/ui/apply-mica-win32) > and which we might want to support. > > I've played around with your code for a bit and came up with a slightly > different idea of how we could design an API. Feel free to criticize or > dismiss: > > > // Public API: > public sealed interface StageBackdrop permits DefaultStageBackdrop, > PlatformStageBackdrop { > > // Default backdrops are available as static constants > StageBackdrop WINDOW = DefaultStageBackdrop.WINDOW; > StageBackdrop PARTIAL = DefaultStageBackdrop.PARTIAL; > > /** > * {@return the name of the backdrop} > */ > String name(); > > // Potential future enhancement: > /** > * {@return a backdrop with the specified option} > * > * @throws NullPointerException if {@code key} or {@code value} is {@code > null} > * @throws IllegalArgumentException if the option is not supported by > this backdrop > */ > StageBackdrop withOption(String key, Object value); > > /** > * {@return all platform backdrops supported on this system} > * > * For systems where backdrops are not supported this will be an empty > list. > */ > static List<StageBackdrop> getPlatformBackdrops() { > return PlatformStageBackdrop.BACKDROPS; > } > } > > // Platform-independent implementations: > public enum com.sun.javafx.stage.DefaultStageBackdrop implements > StageBackdrop { > WINDOW, > PARTIAL > } > > // Named platform implementations: > public record com.sun.javafx.stage.PlatformStageBackdrop(String name) > implements StageBackdrop { > public static final List<StageBackdrop> BACKDROPS = > Toolkit.getToolkit().getBackdropMaterials().stream() > .map(name -> (StageBackdrop)new PlatformStageBackdrop(name)) > .toList(); > } > > > `StageBackdrop.getPlatformBackdrops()` would only return the > platform-prefixed named backdrops, not the two platform-independent variants. > Users would only interact with `StageBackdrop` objects, not with strings. > This also gets rid of the "material" terminology, which I find a bit > confusing (I ask the backdrop for a list of materials, and then turn a > material back into a backdrop?). > > The only way to obtain a `StageBackdrop` is to use a static default instance, > choose one of the platform-provided backdrops, or potentially in t... @mstr2 Thank you for looking into this in such detail. I really appreciate it. I've been going back and forth on your proposal over the last few days. I'm now in favor of changing the API to more or less match what you've written up. There's a lot to be said for firmly separating the standard backdrops from the platform-dependent ones and providing different means of accessing them. I'll start migrating the API later this week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-4445926825
