On Thu, 27 Nov 2025 23:10:15 GMT, Marius Hanl <[email protected]> wrote:
>> This enhancement allows `Stage` to be placed on the screen similar to a
>> popup window, where a user-specified positioning anchors defines a point on
>> the stage that should coincide with a given location on the screen. For this
>> purpose, the following new methods are added to `Stage`:
>>
>>
>> public class Stage {
>> public void relocate(AnchorPoint screenAnchor, AnchorPoint stageAnchor);
>> public void relocate(AnchorPoint screenAnchor, Insets screenPadding,
>> AnchorPoint stageAnchor, AnchorPolicy);
>> public void relocate(Screen, AnchorPoint screenAnchor, Insets
>> screenPadding, AnchorPoint stageAnchor, AnchorPolicy);
>> }
>>
>>
>> ## AnchorPoint
>> `AnchorPoint` is a point that is either specified in absolute coordinates,
>> or relative to the screen or stage:
>>
>> var anchor1 = AnchorPoint.proportional(0.5, 0.5); // center of the
>> screen/stage
>> var anchor2 = AnchorPoint.absolute(100, 100); // absolute coordinates within
>> screen/stage
>>
>>
>> For example, a stage that sits flush with the bottom-right corner of the
>> screen can be shown as follows:
>>
>> var screenAnchor = AnchorPoint.proportional(1, 1); // or use the
>> AnchorPoint.BOTTOM_RIGHT constant
>> var stageAnchor = AnchorPoint.proportional(1, 1);
>> stage.relocate(screenAnchor, stageAnchor);
>> stage.show();
>>
>>
>> ## AnchorPolicy
>> `AnchorPolicy` controls how the anchor may be adjusted when the preferred
>> placement doesn't fit within the screen bounds:
>>
>>
>> public enum AnchorPolicy {
>> FIXED,
>> FLIP_HORIZONTAL,
>> FLIP_VERTICAL,
>> AUTO
>> }
>>
>>
>> * `FIXED`: always use the provided anchor; only adjust the resulting
>> position to fit within the screen.
>> * `FLIP_HORIZONTAL`: if the preferred placement violates horizontal
>> constraints, try a horizontally flipped anchor (e.g. top-left to top-right)
>> before falling back to the original anchor.
>> * `FLIP_VERTICAL`: likewise for vertical constraints.
>> * `AUTO`: automatically choose the most suitable flip:
>> if only horizontal constraints are violated, acts like `FLIP_HORIZONTAL`;
>> if only vertical constraints are violated, acts like `FLIP_VERTICAL`;
>> if both are violated, try a diagonally flipped anchor (both axes) and
>> pick the placement that requires the least adjustment.
>>
>> This is useful for popup-like behavior where you have a preferred "opening
>> direction", but want the window to flip to the opposite side of the
>> reference point when there isn’t enough space (e.g. "prefer below, but open
>> above if below doesn’t fit").
>>
>> ### PopupW...
>
> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1298:
>
>> 1296: @Override
>> 1297: public void centerOnScreen() {
>> 1298: relocationRequest = null; // cancel previous relocation request
>
> As far as I understand, with the new anchor system, a center on screen can
> easily be achieved as well? I wonder if we could also deprecate this method
> instead. But not sure if I understand it correctly.
No, the anchor is always a point _on the window being shown_, not on the
screen. All anchor APIs require you to specify an explicit screen location, and
the window is then moved so that the anchor coincides with that screen
location. So to emulate `centerOnScreen()`, you'd have to manually get the
screen bounds, and then calculate the center.
> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1459:
>
>> 1457: * @since 26
>> 1458: */
>> 1459: public static final class Anchor {
>
> This could be a record too
Yes it could, but I don't like the boolean parameter that it would expose.
Boolean parameters are usually not a good idea, as they lead to "boolean
blindness" at the call site. I've moved this entire class to `javafx.geometry`,
as it might be useful for other code in the future, and I don't want to
proliferate two nested versions of an anchor point (one in `Stage`, the other
in `PopupWindow`).
> modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 1120:
>
>> 1118: }
>> 1119:
>> 1120: // Give subclasses a chance to adjust the window
>> bounds
>
> Unrelated to this Enhancement, but I wonder if the `centerOnScreen` line
> before could also be rewritten using this system (at one point). Now, it
> looks like he might be centering the `Window`, and then fix the bounds to
> something else, wasting some time.
I've re-implemented `centerOnScreen` in terms of `WindowLocationAlgorithm`, so
it now uses the same code paths as the `relocate()` methods.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2570158460
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2565054489
PR Review Comment: https://git.openjdk.org/jfx/pull/1986#discussion_r2604714657
