HeaderBar non-draggable window issue

[Michael Strauß]

I've given this some more thought, and I think we can do something in
terms of API. What makes your use case different is that the occluder
is not a descendant of the HeaderBar, instead it's a sibling of it.
I've added HeaderDragType.TRANSPARENT and
HeaderDragType.TRANSPARENT_SUBTREE, which can also be set on
non-descendants of HeaderBar. Notably, it doesn't create additional
draggable areas, it merely doesn't obstruct already-existing draggable
areas. In your example, you would set TRANSPARENT on the MaskerPane.

You can check it out in the HeaderBar API update PR:
https://github.com/openjdk/jfx/pull/1936

Does this solve your problem?



On Wed, Dec 31, 2025 at 2:24 AM Cormac Redmond <credmond at certak.com> wrote:
>
> Hi Michael,
>
> It could be adapted, it could also be clipped using the size of the HeaderBar (in fact, that's what I've done), etc. But MaskerPane was just an example that highlights differences in behaviour of Window icons vs draggable header.
>
> In this case, there are no controls in the HeaderBar and there are no controls sitting on top of it. There's just one pane sitting on another, and a lot of blank space.
>
> Scene's pickHeaderArea() does receive these mouse events. I am thinking that HeaderBar could/should, as much as possible, continue to support dragging when an event was not sourced from a control. I have never experienced an application that does not drag when you click and drag from an "empty" area of the header bar, wouldn't it be better to support this out-of-the-box (or at least an option to enable an eager more)?
>
> I imagine most HeaderBar usages won't be packed with nodes and would want this behaviour.
>
> Kind Regards,
> Cormac