I’ve been working on floating child windows (windows that float above a designated parent window, but not above everything on the desktop, like with always-on-top windows) on a personal fork of JUCE for the last couple months.
Here’s how everything looks:
This feature has been requested to death since 2006 (!!!), so I figured I’d share what I’ve been able to do here
Please let me know if you have any questions, I’m happy to help however I can
Nice work. This is one of the major short coming of juce for anybody that is doing applications rather than plugins. Hopefully this can get merged into the official juce at some point.
And I hope so too. It would be a pretty straightforward merge as well. My work has only touched a handful of files, and in the time since I made my fork, they’ve hardly been modified at all on develop
It’s just a matter of whether my code is up to JUCE’s standards :P
Also I saw your post (from 2007!) about setAlwaysOnTop being unimplemented on linux
I gave it a proper implementation while I was doing my work on child windows. Though I think setAlwaysOnTop would probably see less usage in a context where proper floating child windows are available (a lot of the usage of setAlwaysOnTop that I see is just people trying to achieve child window-like behavior)
@original-picture This is amazing, thanks for sharing @ibisum I’ve attached a code-changes-only patch that will apply to JUCE 8.0.8 on the master branch
There were a few conflicts on develop and I wanted to keep the patch exactly as it is in @original-picture ‘s repo, so master it is
@andyjtb - Thanks for this patch, I will have a poke at this during the week. I hope you get a chance to submit this as a PR to the main devs too, would be good to see this improvement. Will let you know further thoughts after a code review on my end ..
If anyone wants to help with the development of these features, the best thing you can do is build and (manually) test your existing JUCE GUI applications with this fork. I need to make sure that projects built with the fork and master behave identically when the new functionality isn’t being used, and lots of manual testing is the only way to do that!
Great work!
Since I made similar modifications a decade back, it would be great if this could get implemented in Juce officialy.
As far as I recall, some issues I had that I would suggest testing were:
Windows and Mac handle these types of child windows differently, I would check on both platforms
I seem to recall some issues related to Drag & Drop, might be just the way I did it, but it’s worth a check.
Also, is it possible to “unlik” the parent and the child? You might not always want the position of the parent to change the position of the child ?
Windows and Mac handle these types of child windows differently
At least in my experience, the only real observable difference is that on macOS, child windows move with their parents, but all the correct windowMovedOrResized calls still get made, so this doesn’t seem to be a issue in practice
I seem to recall some issues related to Drag & Drop
I haven’t tested drag and drop at all, so it definitely could be broken. But none of my modifications touched the drag and drop code, so I don’t think I’ve actually introduced any drag and drop related bugs
Also, is it possible to “unlik” the parent and the child? You might not always want the position of the parent to change the position of the child ?
Yep! Just use ComponentPeer::removeFloatingChildPeer
But also do be aware that parent windows changing the positions of their children is only a thing on macOS (not my decision, that’s just how child windows work on macOS). Parent transformations don’t get applied to children on windows or linux/GNOME
