Detaching and re-attaching tabs from&to DockArea

[Adanos020]

In this thread we're discussing the design of the feature in the title.

My idea is to mimic Dear Imgui's solution:

• When a tab is dragged, it gets detached from the docking area and put in a new window.
• If the cursor hovers over a tab bar while dragging a tab, the area where the tab will end up upon dropping will be highlighted.
• If the cursor hovers over the content area of a tab, in the middle of that area there will be 5 large icons, each corresponding to the place in which the tab will be placed when the tab is dropped on it.
• If the tab is dropped anywhere outside those icons, the tab will stay in its detached window form.
• If the detached tab's window is grabbed again, the behaviour from previous 3 points also applies.

I'd also like the programmers to be able to choose if they want to have detachable tabs in a DockArea or not.

Please feel free to share your own ideas or concerns.

[Jerrody]

I think that a problem can be divided into the two parts:

• Detaching a tab. I think we can detach it when doesn't apper selection_color.
• This is one of the most hard part. We need to understand when window can be attached. I tried to implement it, but I don't understand at the current moment how to do this. Possibly, we need to rewrite some parts of code.

Also, I think that work of tabs and windows should be separated into the two threads.

[bartios]

If we drop a tab outside of the docking area and create a new window, do we want the tab to 'transform' into a window or do we want to create a window with a docking area, a tree etc and then drop the tab into that new window?

'transform' into window

• should probably not be possible to add other tabs to it
• can we just run the tabs .ui() function to render or is there some kind of obstacle
• users might want to customise this, what kind of requirements should such a window have/what should the trait look like

create new window with docking area

• this could allow dropping other tabs into this new window
• the window should probably close when the tree is empty
• users might want to customise this, what kind of requirements should such a window have/what should the trait look like

Is there even a difference between these or should we just add a behaviour setting for dropping outside of docks something like

pub enum DropOutsideDockBehaviour {
    intoNewWindow,
    intoNewDock,
}

I'm not really well read into the API and inner workings of the library as I haven't seriously used this yet but it looks really nice and people are active so I thought I'd add my two cents.

[Adanos020]

I think I'd want the new window to have its own docking area.

[smallB007]

Guys, seriously. I don't wanna say that the discussion is pointless. But it is. All answers, to all questions are included in workings of Visual Studio. If you are not sure how docking system should behave, fire up Visual Studio and observe the behavior.
Otherwise this is simply going in circles, pointlessly wasting time and energy, where all the answers are readily available...

[Adanos020]

@smallB007 What we want here is a concrete list of required features. Saying "just do what VS does" isn't helpful whatsoever.

[smallB007]

@smallB007 What we want here is a concrete list of required features. Saying "just do what VS does" isn't helpful whatsoever.

List of features yes, but discussion on them should be cut in the bud with sentence: Go and see how VS does it.
What I would like to avoid is to have comments like those guys above. Comments like that should be redirected to the "Go and see how VS does it". Those guys clearly don't really understand the topic, yet they want to say something, ideally clever, and by doing so, they simply slow down the whole process.

[Adanos020]

Closed by #149