<div dir="ltr"><div dir="ltr"><div class="gmail_default" style=""><font face="verdana, sans-serif">Hi Michael,</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">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).</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">No, I do not think wrapping it in a BorderPane manually is a problem if it didn't present any unexpected problems.</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">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. </font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">Or consider maybe a dialog header node that gets updated/replaced <i>after</i> 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.</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">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.</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">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")..?</font></div><div class="gmail_default" style=""><br></div><div class="gmail_default" style=""><font face="verdana, sans-serif">Just some thoughts for now. I'll leave some proper comments on the PR after testing.</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><br></div><div class="gmail_default" style=""><font face="verdana, sans-serif">Kind Regards,</font></div><div class="gmail_default" style=""></div><div class="gmail_default" style=""><font face="verdana, sans-serif">Cormac</font></div></div><font face="verdana, sans-serif"><br></font><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr"><font face="verdana, sans-serif">On Sun, 15 Jun 2025 at 21:58, Michael Strauß <<a href="mailto:michaelstrau2@gmail.com">michaelstrau2@gmail.com</a>> wrote:<br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="verdana, sans-serif">Hi Cormac,<br>
<br>
I think there are several overlapping problems here.<br>
<br>
Let's start with the window button states. I've prepared a PR to align<br>
the states of extended window buttons with what would be expected on<br>
the OS [0]. This seems to address your points 2, 3, and 4.<br>
<br>
Second, let's look at this piece of code:<br>
<br>
    var dialog = new Dialog<>();<br>
    dialog.initStyle(StageStyle.EXTENDED);<br>
    dialog.setTitle("My Dialog");<br>
    dialog.setContentText("My Content");<br>
    dialog.getDialogPane().getButtonTypes().addAll(ButtonType.OK);<br>
    dialog.getDialogPane().setHeader(new HeaderBar());<br>
    dialog.show();<br>
<br>
To me, this seems like it should work, but it doesn't (the `HeaderBar`<br>
has a height of 0). The reason for that is that `DialogPane` doesn't<br>
respect the minHeight of the `HeaderBar`; it only uses its prefHeight<br>
(which is 0). This is probably a bug: a control should never use<br>
prefHeight alone, but should use the result of clamp(prefHeight,<br>
minHeight, maxHeight) instead.<br>
<br>
Third: Assuming that the bug above is fixed, we have the question of<br>
whether we need additional API in `Alert`, `Dialog`, or `DialogPane`.<br>
I don't have a strong opinion on that yet. With all fixes in, it's<br>
certainly possible to create extended dialogs without new API. Is it<br>
too much work to wrap your content and a `HeaderBar` in a<br>
`BorderPane`? Do developers really repeatedly use the Alert/Dialog API<br>
in their code, or would they not usually create a utility method for<br>
that?<br>
<br>
[0] <a href="https://github.com/openjdk/jfx/pull/1831" rel="noreferrer" target="_blank">https://github.com/openjdk/jfx/pull/1831</a><br>
<br>
<br>
<br>
On Fri, Jun 13, 2025 at 5:39 PM Cormac Redmond <<a href="mailto:credmond@certak.com" target="_blank">credmond@certak.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> To keep the conversation going on window icons / HeaderBar, here are some observations/problems when using StageStyle.EXTENDED for a DialogPane (on Windows):<br>
><br>
> 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.<br>
> There's no way to control (hide or or disable) the window icons, all three are present<br>
><br>
> 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<br>
><br>
> 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).<br>
> 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).<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
><br>
><br>
><br>
> Kind Regards,<br>
> Cormac Redmond</font><br>
</blockquote></div></div>