> This doesn't quite make sense to me, the Left and Right have a resize cursor, > and neither of those are set as draggable. I guess it's because of their > height/placement. E.g., see left versus right (Label versus HBox) in slightly > tweaked code.
In your example, "left" and "right" are Labels, which don't resize to fill the available space. There's empty space above the label, and this empty space is the HeaderBar itself, which is draggable. This is why you get a resize cursor, the label has nothing to do with it. > So this brings me to another problem. We don't want some nodes to be > draggable, such as the MenuBar. Because if it is, we end up with this: > > And if you make it non-draggable, you lose the resize cursor (in IntelliJ, > you get both non-drag behaviour, and resize cursor above the menu). It seems > very confusing and non-intuitive; this relationship between dragging options > and seeing a resize cursor and how they're incompatible re: the menu example. How do you suggest we solve this? Just forcing a resize border over potentially interactive elements might work for some applications, but not for others. Windows File Explorer and Terminal generally have the same behavior, where you don't get a resize cursor on client content. However, they do seem to allow for a resize cursor if you manage to precisely hit the top border of the window (it seems you need pixel-precise pointing for that). However, tiny resize borders don't seem to be a good user experience. In general, you can of course recreate the IntelliJ behavior by simply placing a draggable, but visually transparent node across your MenuBar, aligned with the top of the HeaderBar and its height set to match the resize border. This will intercept mouse events and give you a resize cursor.
