Drag and drop custom editors to other windows issues

[bpasero]

We have some code in fillResourceDataTransfers to fill the data transfer object for when the user drags an editor (or a file) to another window. That code among other things makes it possible to drag an editor to another window and have it open there (even if dirty).

One immediate issue is that a custom editor will not open as custom editor in the target window unless configured to be the default, so I think we would have to carry over the ID to use for override to know which editor to pick:

The other (possibly bigger) issue is how to restore dirty contents in the target. We currently only support to preserve and restore textual content (here and here), but would need a different approach to support custom backups.

I would think that restoring dirty editors is P2 but the support for custom editor DND is something to look into first.

[lramos15]

@bpasero I added the drag and drop support for custom editors and notebooks. I really hate the way the typings came out and wonder if we should make a central viewType editor input. Let me know if we should make a separate debt issue for transferring dirty state.

[bpasero]

@lramos15 I think we should not probe on properties of the editor input that we don't know about. Agree that we need a proper solution that does not require to probe on properties.

I never liked the name viewType and we already have typeId as property to know which editor to use for a given input. It almost seems to me that we have 2 competing concepts here:

• typeId is used when the editor input is already resolved after the overrides have kicked in to find out the EditorPane to create to show the input
• viewType when used as override allows the override handler to create the proper editor input
• an editor input can only have one typeId but possible many viewTypes (?)

Somehow it feels weird that the editor input would provide such a property given that the viewType is the thing that was only used to find the right override?

I feel this needs some more thoughts...

Here is another idea: instead of putting the resource into the drag and drop transfer, why not literally use the editor serializer to product a JSON form of the input and then in the target unserialize?

[bpasero]

As outlined in #124394 (review) I think we should delegate to the editor what get's added into the transfer object.

[bpasero]

via ab793cf