feat: create new window when dragging tab outside the app

[soumyamahunt]

Fixed SetDraggedOutside limit. Dragging any type of set item out side the app will launch a new instance and open that set in the instance.

PR Type

What kind of change does this PR introduce?

• Feature

Other information

[0x7c13]

Did you test if dragging a tab out when the file has been deleted or renamed? Try to see if it works.

[soumyamahunt]

Did you test if dragging a tab out when the file has been deleted or renamed? Try to see if it works.

I fixed it to work when filecontent is modified outside of app. For renamed/moved/deleted I am adding their content to the new file, can't think of a better solution. Anything on mind??

[0x7c13]

Did you test if dragging a tab out when the file has been deleted or renamed? Try to see if it works.

I fixed it to work when filecontent is modified outside of app. For renamed/moved/deleted I am adding their content to the new file, can't think of a better solution. Anything on mind??

This is exactly why I am limiting it to empty file only.......... I could not make it work for deleted files scenarios.

[0x7c13]

Did you test if dragging a tab out when the file has been deleted or renamed? Try to see if it works.

I fixed it to work when filecontent is modified outside of app. For renamed/moved/deleted I am adding their content to the new file, can't think of a better solution. Anything on mind??

This is exactly why I am limiting it to empty file only.......... I could not make it work for deleted files scenarios.

If you cannot solve the problem, just disable the drag out in this case and re-pop the message to notify user that file has been moved or deleted (so he or she knows why dragging out of such tab won't work).

[soumyamahunt]

If you cannot solve the problem, just disable the drag out in this case and re-pop the message to notify user that file has been moved or deleted (so he or she knows why dragging out of such tab won't work).

Fixed it.

[0x7c13]

Another thing is that when you drag a tab outside to a desktop for example, it shows a "move" menu instead of creating the new instance directly and you have to manually cancel the menu before it can work. This needs to be solved otherwise the UX will be very confusing.

[soumyamahunt]

Another thing is that when you drag a tab outside to a desktop for example, it shows a "move" menu instead of creating the new instance directly and you have to manually cancel the menu before it can work. This needs to be solved otherwise the UX will be very confusing.

Fixed this, however some apps like VS Code and Firefox still able to intercept drop action even if the tab doesn't contain any file. Also, some downside of this fix is no more drag and drop sharing between notepads and other programs may be implementing "sharing" or "open with another app" features will be the way to go.

[0x7c13]

Another thing is that when you drag a tab outside to a desktop for example, it shows a "move" menu instead of creating the new instance directly and you have to manually cancel the menu before it can work. This needs to be solved otherwise the UX will be very confusing.

Fixed this, however some apps like VS Code and Firefox still able to intercept drop action even if the tab doesn't contain any file. Also, some downside of this fix is no more drag and drop sharing between notepads and other programs may be implementing "sharing" or "open with another app" features will be the way to go.

If this is going to break the sharing between notepads then I would say don't do it....

Another approach I think:

1. Keep everything as it is: 1) User can still drag out empty tabs. 2) Dragging out tab which has a file to third party apps will still work. 3) Dragging between notepads is un-touched.

2. Add one more menu item in TabContextFlyout and call it "Open in new window". Put 100% of your logic/changes there.

[soumyamahunt]

1. Keep everything as it is: 1) User can still drag out empty tabs. 2) Dragging out tab which has a file to third party apps will still work. 3) Dragging between notepads is un-touched.
2. Add one more menu item in TabContextFlyout and call it "Open in new window". Put 100% of your logic/changes there.

I went for the opposite approach. I kept my implementation of tab drag and drop. To share files to other apps via drag and drop user can drag the PathIndicator to the other app. This will clear any ux confusion. Is this acceptable??

[0x7c13]

1. Keep everything as it is: 1) User can still drag out empty tabs. 2) Dragging out tab which has a file to third party apps will still work. 3) Dragging between notepads is un-touched.
2. Add one more menu item in TabContextFlyout and call it "Open in new window". Put 100% of your logic/changes there.

I went for the opposite approach. I kept my implementation of tab drag and drop. To share files to other apps via drag and drop user can drag the PathIndicator to the other app. This will clear any ux confusion. Is this acceptable??

Still feeling awkward since this is not a well established UX behavior. Since WinUI's TabView will eventually abandon the ListView based TabView and will use ItemRepeater for proper implementation. So we will be able to use it as well. At the time, we can get rid of the annoying drag n drop behavior brought by the ListViewBase. Once that happens, we can just point it to the code you have written. That's also why I suggest you to go with "Open in new window" route and keep everything as it is.

Btw, you have to make sure the file has been successfully moved and shown from one instance to another before you call "DeleteTextEditor", you can not assume the file write will work. I have seen it on my end that in some cases we are not able to write file to the package folder. This will get things even messier if you are taking this into account. This safety check can only be done with something like a background service and you sync with two instance on the handling of the drag n drop file. But this is too overkill for such small benefits.

Since Notepads already supports move from one to another. I would say let's focus on something else and revisit this one when WinUI's TabView gets a newer implementation so that we can borrow.

[soumyamahunt]

Still feeling awkward since this is not a well established UX behavior.

The typical behavior of dragging tab outside of an app is to create new window of the app. This seems to be standard across various tabbed interfaces like browsers and editors. That's why I think implementing file transfer through setsitem drag-drop will confuse user.

Since WinUI TabView will eventually abandon the ListView based TabView and will use ItemRepeater for proper implementation. So we will be able to use it as well. At the time, we can get rid of the annoying drag n drop behavior brought by the ListViewBase. Once that happens, we can just point it to the code you have written. That's also why I suggest you to go with "Open in new window" route and keep everything as it is.

If you don't want to implement this now I would suggest to keep it open until WinUI 3 releases. Currently users can create a new window and drag the instance to that window I don't think cluttering the TabContextFlyout is necessary for this.

[soumyamahunt]

@Jasonstein I have made this behavior consistent for tabs for which files are either renamed or moved. Hope this removes any kind of confusion. You can implement this whenever you want.