Issue #18: Make DragDropStage open at the dropped location and be ownerless

[philliplbryant]

These changes allow the default behavior defined in the issue without adding top-level properties to the Bento class.

New default behavior when undocking a Dockable to a `DragDropStage:

• Open the DragDropStage at the dropped location.
• Make the DragDropStage ownerless.

[philliplbryant]

I'm not sure if the sourceIsOwner parameter should default to false.

Setting sourceIsOwner to false allows the DragDropStage to be closed with no guaranteed way of reopening it or otherwise recovering the Dockable(s) in it.

@richmeyer7, I experimented with keeping the previous owner settings to confirm the DragDropStage still opens where dropped and does not block the sourceStage. Since that's the case, do you still have a preference for the DragSropStage to remain ownerless?

[richmeyer7]

@philliplbryant - I assume by "does not block the sourceStage" you mean the owned DragDropStage does not have window or application modality, which is good, because it does not prevent interaction with other Stages. However, I believe if it is owned by the sourceStage, it is always "in front" of the sourceStage in Z-order, which I don't like, because that prevents the user from moving the sourceStage in front of the DragDropStage. Also, if the user minimizes the sourceStage, it minimizes the owned DragDropStage, which doesn't seem like behavior we want. An owned Stage is commonly used for subordinate windows like modal dialogs or utility/toolbox windows. I think we want independent top-level DragDropStages so the user can bring the sourceStage in front of it if desired, and can minimize the sourceStage without minimizing the DragDropStage. For example, the user may want to drag out the Map pane to its own DragDropStage and then minimize the main Stage, viewing only the Map. Or Alt-Tab, or Windows-key-Tab, or Taskbar select between the main Stage and any DragDropStages with each one being able to appear in front of every other one.

Regarding closing the DragDropStage, I don't have time to investigate right now, but I believe it shouldn't affect our choice of sourceIsOwner value because AFAIK the user can close the DragDropStage regardless of whether it has an owner Stage (please check that). I don't recall what happens to the Dockables when that happens. Do they revert to the root dock, or are they closed? Either way, I assume our application will have a way for the user to navigate to each standard Dockable via the main menu regardless of whether that Dockable currently exists or is displayed. JRE Client does that for the JIDE dockables, and IDEA does it. In other words, I don't think it would be desirable to force all our Dockable Nodes to always remain open. If the user closes a non-root dock and its Dockables get closed, we should do whatever we must to ensure that closing the Dockables is not a problem. I guess we will choose whether to retain a reference to a Dockable (or its wrapped Node) when it becomes closed, or not retain a reference and just rebuild it when we redisplay it. That choice could be on a case-by-case basis, or always the same approach. If we choose to rebuild, then any display state for which we haven't implemented persistence will revert to defaults (think TableView scrollbar positions, column sorting, filtering, etc.). If a Dockable contains a settings editor that has unsaved changes and the user performs any action that will discard it, we need a way to prompt for confirmation before actually closing the Stage or Dockable, like how our current MVC UI pattern routes all close requests (via the "Close" button and the Stage top right X) through SendToServerViewUiAdapterFx.safeHide(contextClosing: Boolean).

[philliplbryant]

I added top-level properties sourceIsOwner and applyMousePosition to StageBuilding, as well as setters for both, allowing users to easily change the behavior.

I chose to continue using the values prior to this change as the default behavior:
applyMousePosition = false
sourceIsOwner = true

[Col-E]

I don't recall what happens to the Dockables when that (close button) happens

DragDropStage if constructed here will always have a scene with a DockContainerRootBranch as its content. Then on WINDOW_CLOSE_REQUEST if we have a container still as the scene's root it will walk the dockable elements contained in that container hierarchy and attempt to close them via DockContainer#close(Dockable)

There are a number of options you can take as a library consumer to intercept this behavior and do what you wish.

• The dockables could be marked as non-closable, which will prevent the new window from being closed so long as at least one dockable remains in the UI. Any closable dockables will be closed though.
• The container's close method fires off a cancellable event, which you can intercept, do some action, and then mark as cancelled if you wish. For your settings example you could toss up a dialog prompt when you observe the close happen for a dockable containing the settings pane.

[Col-E]

Any remaining action items? If not I'll merge.

[philliplbryant]

I'm unaware of any remaining action items. If I find any, we can always open another issue.