StageStyle.EXTENDED & dialogs

[Cormac Redmond]

Hi Michael,

Amazing to address the main issue (utility window icons, etc.) so quickly.
I will test your new PR tomorrow (I'm Irish time, late here).

No, I do not think wrapping it in a BorderPane manually is a problem if it
didn't present any unexpected problems.

But, there'd be some pain/risk re: third-party or library dialogs, etc.
Imagine you're using a library which returns a dialog with an
already-populated header node, where all you want is consistent window
icons (i.e., uniform colors or custom icons as per your main screen), you'd
need to always check for header nodes and wrap them in a BorderPane with a
HeaderBar in top.

Or consider maybe a dialog header node that gets updated/replaced *after*
the dialog is shown -- you'd lose your BorderPane/HeaderBar if you don't
have control over that code that does the replace (i.e., in third-party
code). Not sure if that's even possible, but I presume it is valid.

Also, a dialog's headerText field would present a problem, presumably, as
using a header node (to get the title bar / window icons) would mean you'd
need to also check for or migrate headerText usages and stick it into a
header node (i.e., the BorderPane's center as a Label, or whatever). This
might break CSS. Similar issue for "graphic". Again, I'm thinking about
third-party libs that might use these fields today.

Would it be an idea that a pane (whether dialog or all) has a "title bar"
node field, and leave header alone (where header takes in the meaning of
"everything below title bar")..?

Just some thoughts for now. I'll leave some proper comments on the PR after
testing.


Kind Regards,
Cormac

On Sun, 15 Jun 2025 at 21:58, Michael Strauß <michaelstrau2 at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250616/e40b3c52/attachment-0001.htm>