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 <credm...@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
