Floating Window scheme

[adam-law]

I'm enjoying learning your framework. It's well written, sane and has great documentation. Apparently, however, there's a lot of functionality well beyond what documents say.

I saw under the core manual, some mentions of the ability to have a floating window setup. In terms of the docking setup I want, what I want to actually achieve is this (sorry about my ignorance of the actual inner workings of your framework):

• Dockables don't dock with the main content area, and can only dock with each other, or to the side areas (top, bottom, left, right).
• When "detached" they "float" over the content area. Currently, as soon I move a detached dock, it attempts to rejoin the main area, and resize, both of which are behaviors I don't want.
• In relation to my other open issue regarding stacking the docking area, on top of a visual component, should there be no way to make transparency work, it was my plan to dock the visual component, make it the center-most component, and prevent anything else from stacking or becoming a neighbor in the station created for it, which will makes those dockables either float above the visual component, or be stationed outside the visual component's dock.
• Lastly, is there a way to prevent the "picking up" of a dock? I was able to make the logic you proposed using a VetoableDockRelocator, by creating a station for the visual component, and this prevents other docks from joining it, but the visual component can be dragged out of this station, and it was, it can't be put back (not that I want it to leave in the first place :)) )

I hope all of this makes sense. I haven't had much sleep :))

Thank you!

[Benoker]

Question 1 and 2:

• Override CDockable.isNormalizable and return false. This will prevent any buttons to show up that could move your dockable to the center, and disable any drag and drop operation that would move it to the center. It will stay in its own window at all times.

Question 3:

• Since I know you want to show an OpenGL canvas. Personally I would not try to put any Swing components over the canvas and have it shine through. All the OpenGL canvas I know of are AWT, and in my experience AWT, Swing and transparency are three words that do not go together. Unless you find a way to convert the canvas into a Swing-Component, your idea of putting it into the middle as Dockable is a good idea.

Question 4

• The VetoableDockRelocatorListener has a method called grabbing. It is called before a drag & drop operation even starts. Call DockRelocatorEvent.cancel to cancel the start of a drag & drop operation.

[Benoker]

I'm enjoying learning your framework. It's well written, sane and has great documentation. Apparently, however, there's a lot of functionality well beyond what documents say.

Thanks. And yes, through the ages much undocumented functionality was added, layers over layers were built. I think one can really see that DockingFrames is a lot older than GitHub :-)

You might find some additional ideas here: https://forum.byte-welt.net/c/byte-welt-projekte-projects/dockingframes

[adam-law]

Thanks for the tips! I'll be working on them today :)

I totally forgot to try out the forums. Sorry for opening topics here instead of there XD