Make DragDropStage open at the dropped location and be ownerless

[richmeyer7]

When a user drag-drop gesture creates a DragDropStage, it opens centered on the sourceStage (I think) and owned by the sourceStage.
In our application's usage, we prefer the new DragDropStage to open where dropped, and be ownerless so that it is not "always in front" of the sourceStage.
One way to accomplish this is to configure a custom StageBuilding on the Bento instance; for example (Kotlin):

/**
 * A [StageBuilding] whose [initializeFromSource]
 * initializes the new [Stage] without an owner
 * and positions it at the current mouse position.
 */
class StageBuildingOwnerlessAtMousePosition(
    bento: Bento,
) : StageBuilding(bento) {

    override fun initializeFromSource(
        sourceScene: Scene,
        newScene: Scene,
        sourceStage: Stage?,
        newStage: DragDropStage,
        sourceIsOwner: Boolean,
    ) {
        super.initializeFromSource(
            sourceScene,
            newScene,
            sourceStage,
            newStage,
            // Do not make the source Stage the owner of the
            // new Stage. Thus, the new Stage is not "always in front"
            // of the source Stage, and doesn't minimize with it.
            false,
        )

        // Apply mouse position to the new stage before it is shown.
        val robot = Robot()
        val mousePos: Point2D = robot.mousePosition
        newStage.x = mousePos.x
        newStage.y = mousePos.y
    }
}

Request as an improvement a way to initialize and configure the new DragDropStage without a custom StageBuilding.

The following change could suffice:

• Add a property Consumer<DragDropStage> configureDragDropStageBeforeShowing (with a default no-op) to Bento, and change setOnDragDone(...) inside method Header.withDragDrop() to pass the new DragDropStage to bento.configureDragDropStageBeforeShowing before calling stage.show(). The client application could, for example, then implement configureDragDropStageBeforeShowing to call newStage.initOwner(null) (to counteract StageBuilding's call to newStage.initOwner(sourceStage);) and set the newStage position as desired.

[Col-E]

Currently, the override is the intended way to handle this. The Bento class has no top-level properties and I'd like to avoid doing so. My reasoning is that with the current setup its logically consistent on how to modify behavior. If you make one thing a property on the top level it'll stand out. So why not then make X a top level property? What about Y?

I'm open to overall architecture improvements, the whole reason why I'm keeping the version at 0.X is because I anticipate that as features get worked on some larger scale changes will need to be made anyways. If you have ideas on how to improve things don't be afraid to suggest them even if it requires some refactoring, now is the time to do so.

[philliplbryant]

@Col-E : I'm curious about your comment "The Bento class has no top-level properties and I'd like to avoid doing so."

As I understand things, an application can have multiple Bento instances. I'm not sure the intended use case for this - perhaps one might want to listen for DockEvents on one Bento but not another, different StageBuilding implementations, etc. Regardless, the possibility exists for multiple Bentos. As such, when persisting and restoring a docking layout, one would need to associate docking controls with the proper Bento and this necessitates a way to identify the Bento. And the obvious way to do this is to add a top level "identifier" property to the Bento class.

Are you opposed to adding an identifier to the Bento class?

Am I wrong in assuming multiple Bentos might exist?

[Col-E]

As I understand things, an application can have multiple Bento instances. I'm not sure the intended use case for this.

My intention with multiple instances of Bento isn't really that they would operate functionally the same where you have two systems tracking different sets of dockable content. Here's a screenshot of Recaf with some highlights for reference:

The 🟥 is the "main" instance of Bento and is what backs all of the docking behavior in Recaf.

The 🟦 is what is shown in one of the dockables of 🟥 - An embedded Bento (I literally have a EmbeddedBento class defined in Recaf) with most features overridden to be no-op. It comprises of a branch, and two leaves. The one on the left has a null side, and its only Dockable is the text editor where you see the Java code. The one on the right has a RIGHT side, which you can see with the titles for "Fields & Methods" and "Inheritance". With the limitations in-place the only thing it can do is collapse content on the right when clicking on the headers. This makes it function like the tool tabs you have in IntelliJ.

As such, when persisting and restoring a docking layout, one would need to associate docking controls with the proper Bento and this necessitates a way to identify the Bento. And the obvious way to do this is to add a top level "identifier" property to the Bento class.

Following from the prior example, the 🟦 is wrapped in its own custom control. So when you would serialize the 🟥 and provide a factory for creating the component displayed for the "Extractor" tab, it would inherently create the 🟦 without any additional work necessary by the serialization logic.

Are you opposed to adding an identifier to the Bento class? Am I wrong in assuming multiple Bentos might exist?

As you've pointed out, if one had multiple proper instances of Bento then you'd need some top level identifier. At least in the most literal sense it doesn't need to be a Property<String> since such an identifier would likely be immutable anyways. If that were to be added, persisting a Bento instance would still have all configured properties defined in the branches, leaves, and dockables.

Outside of the use case I've listed, I cannot think of any circumstances where you would want to have multiple instances of Bento. The way I'm using it is really just to recycle the collapsing behavior of the branch container.

[philliplbryant]

Does that mean you'd be OK with me adding a final @Nonnull String identifier attribute to the Bento class?

In my fork, I continue to provide the default constructor, which creates an identifier using DockBuilding.uid(), and a constructor with a single final @Nonnull String identifier parameter.

[Col-E]

Does that mean you'd be OK with me adding a final @Nonnull String identifier attribute to the Bento class?

Sure 👍