Move to new Window

[Gamemap]

Could you add the function that you can move the containers to new windows with the size that the container had before (and back again)?

Multible Windows come in Godot 4.0 or 4.1.

[gilzoide]

Hmm, that's a nice feature to have, but if it would only be supported on Godot 4.0+, breaking changes to scripts are needed, like @onready annotations.
There could be a separate branch for 4.0 code, but I've never used Godot 4 and am not planning on doing so soon.

Does in-app floating windows work for you? I know it's not the same, but it is a nice feature DockableContainer could have and would still work on Godot 3.

[Gamemap]

I would like to use multiple screens. in-app floating windows are also a great feature to have but can't solve my "problem".
If you like I could try to update the addon for Godot 4.0 and include this feature.

[gilzoide]

Feel free to implement Godot 4.0 support, but this will not be in the main branch until 4.0 is widely used.
I've created a godot-4.0 branch so you can open a PR to it =]
If you need any help, give it a shout!

Just out of curiosity, are you using Godot 4.0 yet?

[Gamemap]

Just out of curiosity, are you using Godot 4.0 yet?

Only for testing and for my project ideas that need multiple windows. (And there only the first tests, because there is no documentation.)

[Gamemap]

In the video you can see what I thought with multiple windows and why I think it fits very well in your addon.

2021-06-18.20-37-47.mp4

[gilzoide]

Yeah, I also think this would be a really awesome addition!
I'll just not invest my free time in this while Godot 4.0 isn't released.

[Gamemap]

I am trying to implement this, but I have not found where the dragged container is stored. Can you tell me?

[gilzoide]

The child Control objects are maintained as direct children of the DockableContainer object, only their rectangles and visibility are changed.

Whenever a DockableContainer's layout is sorted again, what happens is that DockablePanels, which are TabContainers, are created for tracking the Controls that are tabbed there.
All tabs in DockablePanels are instances of DockablePanelReferenceControls, objects that track the original Control objects and mimics its own rectangle and visibility in them.
That way, we don't need to mess with the scene tree hierarchy regarding the children Control objects.

So the flow of the positioning is:

1. The DockableContainer fits the DockablePanels in the right rectangle based on the calculated layout
2. Since DockablePanels are TabControllers, only the current tab is visible and is expanded to this same rectangle
3. All tabs mimic their rect and visibility to the tracked original Control objects. This way, only the current tab has its tracked Control object visible and all other tabs' tracked Controls get hidden. In the same sense, whenever the tab has its rectangle changed, the tracked control will be moved to the same rectangle.

Now, to make floating windows, we'd need a way in the Layout to mark Controls as floating windows and not store them in any of the panels.
Also, I don't know how floating windows work in Godot 4, but it may or may not work in this "don't move the original Controls in the scene tree hierarchy" policy that is currently in place.

[Gamemap]

Thank you for your explanation. I understand it better now.

Now, to make floating windows, we'd need a way in the Layout to mark Controls as floating windows and not store them in any of the panels.

I haven't looked at this piece of code yet, but maybe the checkbox-hide functionality can be used for this.

Due to this bug, we are currently unable to drag the container out of the main window to create a new window. :( (godotengine/godot#53170)
My new idea was to double-click the tab to open it in a new window and add the drag functionality once the bug is fixed. What do you think about it?

[gilzoide]

Thank you for your explanation.

No problem! I'm really sorry about the delay, things have been busy lately.

but maybe the checkbox-hide functionality can be used for this.

Not exactly, but it should be something just like it. Just like there is the _hidden_tabs Dictionary, there could be a _floating_tabs array holding which Controls are floating windows or something like that.

About dragging to create the new window, maybe the best is doing like some apps do and detach the window if you drag it to the center of a tab. Something like that (imagine this rectangle is the panel and you're dragging another tab inside it):

The DragNDropPanel script is resposible for drawing the drop preview and finding which margin will be split, you could change it to handle the panels' center. DockableContainer's _drop_data_fw method is where the layout is actually changed after dropping a tab inside another panel.

[Gamemap]

I have prepared the central selection (hiding and floating isn't implemented yet):

• What do you think about it?
• Should the central panel be larger? (The container is currently quartered.)
• Diagonal lines like in your picture?

2022-04-17.22-58-43.mp4

[Gamemap]

I have created the floating windows. Sadly, the new Godot 4.0 code contains some bugs. (Ghost tabs - disappear when clicked or are not clickable)

for example:

• 2 tabs "Control2" disappear
• 1 tab "@@28" not clickable

The bugs appeared before I coded the new window function, so the floating windows aren't the cause for this. I started with my current main branch (https://github.com/Gamemap/godot-dockable-container) with godot 4.0 alpha 2.
I will update the project to the next alpha version as soon as it is released.

Here is a video showing the floating windows and the bugs:

2022-04-18.18-04-54.mp4

[gilzoide]

I have prepared the central selection (hiding and floating isn't implemented yet):

I don't know if it will be 100% clear the window is going to be detached, but it looks pretty nice to me! =D

Can the detached windows be docked again inside a panel?

As for these bugs regarding tabs, they seem related to the handling of the Layout internal to DockableContainer. Maybe the tabs are not being removed from the LayoutPanels, so the container thinks they are still tabbed?
By the way, in the end of your video I can see that there are 5 scripting errors in the Debugger panel, you should check them out, as they are probably related to these strange behaviors.

[Gamemap]

Can the detached windows be docked again inside a panel?

Currently only by closing the separate window with the Quit button.

[Gamemap]

I reproduced the errors (now only 4). Error 2 and 4 are at line 60 (layout_panel.gd) Error 3 is at line 81 (layout_panel.gd)
Next week I won't have much time, but after that I can continue working on it.

[Gamemap]

Today I tried the addon with Godot alpha 9 and I think the bugs were fixed by Godot developers (of course there are some smaller new ones). I think it would be better to wait until Godot 4.0 goes into beta to continue this.

• What do you think about this layout for detaching a window (see links below)?
• Do you have an other programm as an example for detaching a window?
• What do you think of the way Open Broadcaster Software (OBS) detaches panels (detach on dragging and append with release on the main window)?

Original Site (in german): https://wiki-de.dmxcontrol-projects.org/index.php?title=Panel-Konzept_DMXC3
google translated site: https://wiki--de-dmxcontrol--projects-org.translate.goog/index.php?title=Panel-Konzept_DMXC3&_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=de&_x_tr_pto=wapp

[Shadowblitz16]

Any info on this for 4.0 now that it's out?
Also you should make the center fill the whole container not undock it dragging it outside should undock it.
Take a look how imGui does it

[gilzoide]

Well, from my end, I'm totally not looking into it right now. I'm currently more invested in porting Lua PluginScript to Godot 4 + GDExtension and other small Unity packages that I use on my day-to-day.

There is PR #20 that ports the code to Godot 4, but it has an unsolved issue and wasn't merged yet. Also no floating/detachable windows in it.
#19 added a manual method for detaching panels, but since the information is not registered with the layout and reattaching those windows to a panel is quite limited, I think it isn't ready for merging to the main branch. Still, this uses Godot 3 Window control nodes, not actual Godot 4 system windows.

[Gamemap]

I thought to make a separate PR for the floating windows after the update PR. Sadly, I got stuck because I didn't know how to fix the issue. If it is OK for you, @gilzoide, I could integrate the floating windows in the PR #20 .
Personal I liked to detach the window by dragging to the center, but I'm not sure how to close it.

Would you like to close it by using the X-Button, and it appears at the same position where it was detached?

[gilzoide]

dragging it outside should undock it.

My issue with that is that the Dockable Container might be the covering the whole screen, so in a full screen experience it could be difficult to drag a panel "outside". My references for dragging tabs to the center of any other to detach them are the Unity editor and After Effects, I think it works very well. One can drag the panel to the tabs header to "fill the whole container", something that Dockable Container already does.

[gilzoide]

If it is OK for you, @gilzoide, I could integrate the floating windows in the PR 20 .

Well, sure!

but I'm not sure how to close it.

I guess 2 viable options are:

1. When you close or minimize the floating window, it reappears in the same place it was before. Now, that last bit (in the same place it was before) is what I think PR 19 was missing, the floating window information should be stored in the Layout resource. Well, that and the fact that ideally the child Control object should not be reparented, to maintain the object hierarchy, but I know that this may not be possible.

   But! Just reattaching the window to the first panel the container can find is quite fine, but that's probably not the best user experience.

2. Dragging the floating window bar triggers docking just as dragging a panel does, so one can dock that window anywhere to the corresponding Dockable Container. I think this one is simpler, since we might not need to store the floating window previous position, storing a "floating_windows" array in the LayoutRoot should be enough.

Either way, we also could have a way to tell the container which panels are closable and just close panels and not dock them back, in case they can be safely closed.