It seems that it is not possible (only on OS X, on Windows it works) to use setAlwaysOnTop(true) in a DocumentWindow holding a plugin’s editor. You can try to add setAlwaysOnTop(true) in the last line of the PluginWindow constructor in the PluginHost, and it will crash or the window with the plugin will be empty. Weird…
PS: Pluginhost crashes in Release mode on OS X (can’t get it to run because of some assertion failure), only works in Debug mode.
That’s not surprising, because on OSX to change the window’s mode, it needs to actually delete the OS window and create a new one, so any views within it are going to get messed up. Can’t think of a good workaround for that, TBH…
But then it should be as simple as to first call setAlwaysOnTop(true) and then use setContentComponent() afterwards!?
This method seems to work at start, but the plugin sometimes tends to go down by the same amount of pixels as the Title Bar height of the DocumentWindow it is contained in. This always happens when I click on another plugin’s window. And it only happens with VST plugins. Why is that? :?
Even changing using setVisible(false) and setVisible(true) again on a DocumentWindow containing a plugin produces the same effect.
Keeping plugins always on top seems like a “must”. All hosts do it (Logic, Cubase, Ableton), so why can’t JUCE do it? I don’t care if it is a native window or a JUCE window. But having to click everytime on a damn button to make a plugin visible again is out of question.
So why does changing using setVisible(false) and setVisible(true) again on a DocumentWindow containing a plugin make the inner of the plugin move down (and the same thing happens when I click outside of the plugin window and it is greyed because it does not have the focus anymore)?
I tried it again, and this really happens. The plugin window stays on top though (but only if I don’t use the native OS X title bar).