StageStyle.EXTENDED & dialogs

[Michael Strauß]

Hi Cormac,

I think there are several overlapping problems here.

Let's start with the window button states. I've prepared a PR to align
the states of extended window buttons with what would be expected on
the OS [0]. This seems to address your points 2, 3, and 4.

Second, let's look at this piece of code:

    var dialog = new Dialog<>();
    dialog.initStyle(StageStyle.EXTENDED);
    dialog.setTitle("My Dialog");
    dialog.setContentText("My Content");
    dialog.getDialogPane().getButtonTypes().addAll(ButtonType.OK);
    dialog.getDialogPane().setHeader(new HeaderBar());
    dialog.show();

To me, this seems like it should work, but it doesn't (the `HeaderBar`
has a height of 0). The reason for that is that `DialogPane` doesn't
respect the minHeight of the `HeaderBar`; it only uses its prefHeight
(which is 0). This is probably a bug: a control should never use
prefHeight alone, but should use the result of clamp(prefHeight,
minHeight, maxHeight) instead.

Third: Assuming that the bug above is fixed, we have the question of
whether we need additional API in `Alert`, `Dialog`, or `DialogPane`.
I don't have a strong opinion on that yet. With all fixes in, it's
certainly possible to create extended dialogs without new API. Is it
too much work to wrap your content and a `HeaderBar` in a
`BorderPane`? Do developers really repeatedly use the Alert/Dialog API
in their code, or would they not usually create a utility method for
that?

[0] https://github.com/openjdk/jfx/pull/1831



On Fri, Jun 13, 2025 at 5:39 PM Cormac Redmond <credmond at certak.com> wrote:
>
> Hi,
>
> To keep the conversation going on window icons / HeaderBar, here are some observations/problems when using StageStyle.EXTENDED for a DialogPane (on Windows):
>
> You need a HeaderBar (at least to take up some space), and you'd need to set it via setHeader(), and if you already have actual header content, you'd need to wrap that content in (probably) a BorderPane (and put the HeaderBar in as top). E.g., it's quite a lot of work to do, everywhere required.
> There's no way to control (hide or or disable) the window icons, all three are present
>
> Usually with StageStyle.DECORATED, the dialog's minimise icon is disabled, preventing you from minimizing it: this is not the case with EXTENDED, it's enabled
>
> If you minimise a modal/blocking dialog using the EXTENDED minimise icon, the dialog shrinks to just the size of the title bar, and (mostly) minimises to bottom left of the screen with just the window icons visible: and the whole application is then blocked; the minimized dialog's window icons, while visible, do nothing; so you cannot close or restore the dialog. Also, curiously, their colour changes in my example (presumably because a scene's fill has disappeared or something, changing from dark to light).
> For Alerts, they'd typically get a StageStyle.UTILITY, I assume (i.e., just an X window icon); so there are similar problems there when wishing to use EXTENDED, with an inability to control the window icons (even just to hide the minimise/restore buttons).
>
> So overall, it seems impossible to leverage the new window icons to mimic existing default behaviour with regards to dialogs/alerts. You'd need to refrain from using EXTENDED for dialogs -- which is quite noticeable and ugly, particularly if there are major colour changes between your main window's title bar, and a dialog's (e.g., dark vs light).
>
> I imagine developers using the EXTENDED window icons / HeaderBar will be slow to adopt EXTENDED if their application has a non-uniform look-and-feel for dialogs/popups, etc.
>
>
>
>
> Kind Regards,
> Cormac Redmond