Bug: DocumentWindow setWantsKeyboardFocus(false) title bar buttons disabled

If you call setWantsKeyboardFocus(false) on a document window then when it becomes active window the title bar buttons (close, minimize..) are disabled.

You can reproduce this behaviour in the Plugin Host Demo by setting setWantsKeyboardFocus(false) in the PluginWindow constructor.  If you do it before the "setVisible(true)" on line 51, then the buttons are disabled when the plugin window first opens.  If you do it after the setVisible(true) then the buttons will be enabled at first, but once you switch focus back to the main window and back to the plugin window the buttons will be disabled.  

This is tested on OSX Mavericks (10.9) with the latest tip.

What I'm trying to do is allow my audio host app receive key events when a plugin window is active.  setWantsKeyboardFocus(false) appears to do the trick as I expected it should, it just breaks the buttons..  If the bug is not easily fixable then any suggestions for accomplishing the same thing properly are appreciated.  Thanks!

Hello, and thanks for making the effort to produce a minimal example (it helps, a lot!).

I couldn't reproduce the issue. The only obvious difference is that I'm using Yosemite rather than Mavericks. Have you made any other changes?

Hi Joshua, thanks for taking a look at this.  My test with the Plugin Host Demo is based on a fresh copy of the latest tip, so the only change to it is adding the call to setWantsKeyboardFocus(false) in the constructor for Plugin Window.  I'm a bit surprised that it works fine for you in Yosemite as the code for active window checking appears to be heavily dependent on the window having keybaord focus, and it also doesn't appear to be based on anything platform specific.. that said of course anything is possible. :)

Some methods that show this dependency:

TopLevelWindowManager::checkFocus

TopLevelWindowManager::findCurrentlyActiveWindow 

Component::getCurrentlyFocusedComponent()

Component::takeKeyboardFocus   //The only place where currentlyFocusedComponent is assigned a value, which doesn't happen if the component doesn't want keyboard focus.

TopLevelWindowManager::isWindowActive //relies back on checkFocus for currentActive window or relies on currentlyFocusedComponent, which checkFocus relies on...

DocumentWindow::activeWindowStatusChanged() // the place where the buttons are set to disabled if the window isn't active

Based on this code I don't actually expect you guys to "fix" this as it appears that it would need a some redesigning of fundamental window management.  If I'm right then any suggestions for how I can accomplish this otherwise?  

 

Bah!  Evidently I haven't been thinking clearly..  it's easily worked around by overriding DocumentWindow::activeWindowStatusChanged().

Sorry for the noise!