Yeah, I think it’s probably a bad idea, and you’re both right about it being a futile exercise. There’s no way you could cover all the variations…
The use case I was wrestling with at the moment: GUI App, running on Mac OSX (I haven’t tested if the same issue exists on Windows yet), with the possibility of opening more than one DocumentWindow, one containing the Main App and other windows containing additional support parameters etc.
Using native title bars, I run into this issue: Let’s say you have a Slider with a text box, or some ComboBoxes. When you click in the Slider text box to edit the value, or click in the ComboBox to focus it and pop open the menu, if you click on a native title bar of the same window or a different window, the focus is not cancelled, you do not exit the edit state of the component, the other window is not “brought to the front” thereby gaining the front window appearance, etc. You’re basically stuck in the edit state unless you cancel it some other way. (Now, if you click and drag the title bar of the native window, it does cancel out of the focused state, but that’s not the same as a simple click, which I would expect to do the same thing.)
It could just be me, but my expectation of the behavior in this case is that clicking on the title bar, especially of a different window, would cancel out of the focused component. It drives me nuts. Absolutely doesn’t happen with a JUCE title bar - because the window gains focus and cancels the component focus. But I tried and tried and you get nothing when clicking on a native title bar. No focus changes, no mouse events, nothing you can grab onto. If anyone has a JUCE hack/suggestion, I’m all ears. But I’ve not ever jumped down the “doing that part natively” rabbit hole before.