OS/X demo bug: floating windows vanish when dragged in

(It’d be nice if we had a few extra characters for the Subject:, we don’t even get one tweet’s worth. :-D)

Playing with the demo today, I note a feature deficiency on OS/X that I don’t remember seeing before…

In the Juce Demo/Widgets/misc widgets pane, drag the box onto the desktop. That works wonderfully (and what a cool feature that is).

Now drag it back. As the mouse passes the border of the inner pane, the dragged component vanishes and stays vanished as long as you’re dragging. Once you release the mouse, there is a noticeable delay of up to 5 seconds(!) and then the lightweight component appears on the desktop pane.

Yeah, that was always a bit of a dodgy demo - on OSX when the floating window is hidden, it stops sending mouse events, so it can’t carry on tracking the mouse. Must have written that bit of the demo nearly 10 years ago, and it’s all seriously in need of some renovation work!

Oh, interesting to note! So, if I ever wanted to do this :slight_smile: (someday I’ll have the time!), then I’d have to switch to tracking the mouse events in some other component…

You could use other tricks, e.g. rather than hiding the window, just make it 1x1 pixel and transparent.

This is interesting, as I tried to make such a component based on the demo that could be dragged outside its parent window to become one on its own (with a close button), and with the possibility of “docking” it back to the main window again.

I also had some troubles like this, so I added a button in the floating window to dock it back to it’s parent.

Well, I don’t wanna hide the window, just drag it in and out of a pane! It’s such a great feature, it’d be lovely if I could include it in production code…

It’s a tricky issue - how does Juce handle it as you drag a component out of a window? That works really well!

I guess that the component where you start the drag keeps getting mouse events even when you’ve dragged out of it - you don’t get that when you drag in. But someone in the event chain has to know when you start to drag the component in because you are checking somewhere to see if it’s a drop target and if so lighting it up…!

Now you might think that you could override mouseEnter() in the receiving component and then (somehow) check to see if you were in the middle of a drag and drop and if so continue to render the component - but that’s work that everyone would have to do, and worse, there’s this: [quote] When the mouse button is pressed and held down while being moved in
or out of a component, no mouseEnter or mouseExit callbacks are made - only
mouseDrag messages are sent to the component that the mouse was originally
clicked on, until the button is released. [/quote]

Here’s another possible strategy: Somehow that window is rendering itself perfectly well as it’s being dragged over other applications that are not the Demo Application - so why can’t we refuse to hand over control to the demo application until the mouse button is released?

I have some experimental code but couldn’t get dragging back in to really work quite right…

Dragging out is easy, because the main window is receiving the low-level mouse events, so even when your lightweight component is removed from it, the window still exists, and carries on getting the events. But when it’s the floating window that’s receiving the events, and then you take it off the screen, you’re removing the actual OS window that was getting the events, so there’s nothing left to receive them.

The workaround would just be to not call addToDesktop directly on your transient component, but to stick it inside a holder component, and add the holder comp to the desktop. Then when it’s time to move the transient component back into your main window, leave the holder component on the desktop, but make it small/invisible, so it still carries on collecting and forwarding the events for you.