Docking / Dock Panel Layout

[Flix01]

[ADMIN] EDIT: There is now an official docking branch. See #2109 for details.

I'd like to see if somebody is interested in a Mini Dock Panel Layout: I implemented a very basic one a few months ago (I still have to port my code to the new version of ImGui).

This is an old screenshot of what it looked:

Basically it just supports one docked window per side, with a "hover" window (when the mouse hovers the buttons that are not active), with no animation and no drag and drop at all, and no re-arrangeable buttons and windows.

This is very limited compared to a "full featured" dock panel implementation but it's better than nothing and is OK for my needs (although it's currently just a proof of the concept not tested for real usage).

[thennequin]

I start to create mine too, but it's more like an small window framework who used ImGui than an extensions for ImGui.
And thanks Omar for created an easy and powerful gui lib ;)

[extrawurst]

@thennequin that looks awesome! ;)

[codz01]

@thennequin thats really great .

[Flix01]

Hands down: @thennequn that's much better than mine!

[Pagghiu]

@thennequin this is great stuff!

[ocornut]

Really cool. Thibault's code is here:
https://github.com/thennequin/ImWindow

[ocornut]

@thennequin I'd be curious to hear about what you've learned / think about the current architecture you've developed. It looks interesting and I'd eventually want to incorporate some form of docking into ImGui. Do you think some aspect of it could be adapted to be included in the core library? How could ImGui evolve to support that sort of extension more naturally?

[thennequin]

Thanks everybody.

@ocornut I wanted to make one simple way to create windows for easily create editors for the company where I work. Actually, the scene editor of our engine (it's PlayAll, maybe you've heard about this at Darkworks :) ) is based on old technologies and it's slow and very hard to evolve, so we want to recreate it from scratch.
We are searching for a good alternative for implementing new features easily but during our research we couldn't find a good and light alternative to our old version of wxWidgets used in our scene editor.
Last year i learnt to use Unity and make custom tools, it was easy to make new windows just by instancing class who inherited from Editor class, it's just perfect for our needs.
So my current architecture is probably based on the ImGui of Unity.
At first i created a new widget for wxWidgets for use wxAUI (docking system of wxWidgets) but this attempt had many problems so i started to create this library from scratch and your samples.
My goal is to use your library without modifications, so i won't search a way to include dock system directly in ImGui. I don't know where to start, but if you want to include dock system, i think you can look at the class ImwContainer.

[Flix01]

Just to say that I added my worse implementation (the first screenshot of this thread) here: https://github.com/Flix01/imgui, together with other (mostly outdated and non-functional) ImGui "addon widgets".

[Edit:] Live Demo Here (proof-of-the-concept test demo of my mini imgui panel manager, with a custom font).

I also made a wiki page of my addon branch here: Addons Wiki .

[ocornut]

@Flix01 Thanks! always useful to have more example/reference code available.

@thennequin Branimir has reworked your code here (haven't looked at it in details yet myself)
imgui_wm.cpp / .h in this folder:
https://github.com/bkaradzic/bgfx/tree/master/3rdparty/ocornut-imgui

• Made it single compile unit .h/.cpp file.
• Fixed internals to use ImGui utility functions and macros instead of custom ones
• Made input and window handling use data passed to ImGui::IO structure.

I heard of PlayAll (it is a french middleware partly developed by Darkworks) but never seen it. Did we met at Darkworks? I only spent sometimes like 9 weeks there in the summer of 2008, so I don't recall everyone :)

I don't know when I'll be able to tackle docking but it's very good to have those different attempts working.

[thennequin]

@ocornut Indeed, he reduced my lib into a pair of files. That's pretty cool, but i will still continue to use my multi files structure for a possible growth.

I worked at Darkworks at that time but we couldn't meet each other because there were over a hundred people at the company, it's impossible to get to know everyone.

Branimir use only one RenderWindow. So when he docked a WIndow ouside of his RenderWindow, he lost it because he didn't recreate a new RenderWindow, It can be a future feature for my lib to restrict the number of RenderWindow.

[Flix01]

Just to say that I'm doing something like @thennequin (I'm on Linux, I cannot use his code!) using imgui only.

It's still W.I.P. and I don't know if it will work across different imgui windows. [Edit:] it works, see updated gif.

However here is a preliminary animated .gif:

P.S. Some buttons shaped like tab labels would be useful...

Happy new year to all imgui users (and to the developer) !

[thennequin]

It seems pretty cool :)

[Flix01]

@thennequin : thanks.

However my preliminary tests show that I cannot make "tab buttons" fly from an ImGui::Window to another... :(.

Never mind... I was thinking of using this kind of layout only in the "central window" (e.g. "document window") of my "Mini Dock Panel Layout".

[EDIT] flying tabs work now.

[ocornut]

Also see LumixEngine code by @nem0 https://github.com/nem0/lumixengine

IMGUI_API bool BeginDock(const char* label, bool* opened = nullptr);
IMGUI_API void EndDock();

https://github.com/nem0/LumixEngine/blob/master/src/studio_lib/imgui/imgui_user.inl

Looks like a fairly small amount of code and it could be ported/redesigned to work in ImGui code perhaps.

EDIT I'd suggest experimenting with the idea of making this an extension e.g ImGuiDock.cpp

[Flix01]

Yes, lumixengine's dock seems better than mine, for a lot of reasons:

• tab buttons are shaped like tab labels.
• tab buttons can become imgui floating Windows.
• code looks very compact.
• it seems to be a "pure imgui" solution (mine too, but @thennequin's depends on the Windows OS AFAICS).
• As far as I can see, it has load/save support.

So I guess it's better to use @mem0's code as a reference for a future ImGuiDock system.

[emoon]

Also the way I did my docking system was to have it fully outside of the ImGui code and just doing SetWindowNextPos/Size. In my cases it makes it much easier as I have no divergences with the core ImGui code which is preferable imo.

[nem0]

@Flix01

it seems to be a "pure imgui" solution (mine too, but @thennequin's depends on the Windows OS AFAICS).

I plan to support os windows too and keep the "pure imgui" interface too, using concept similar to io::RenderDrawListsFn

As far as I can see, it has load/save support.

It uses my own structures for saving and Lua for loading, but it should not take more than 10 minutes to rewrite it. However I do not know about any way/interface to connect to imgui's save/load at the moment and I would prefer pure imgui save/load.

code looks very compact

it's still far from finished, has some known bugs and missing features

[Cthutu]

Looks great but you can't drag outside the confines of the window it seems.
@thennequin's can.

On Sat, 2 Jan 2016 at 08:13 Mikulas Florek [email protected] wrote:

@Flix01 https://github.com/Flix01

it seems to be a "pure imgui" solution (mine too, but @thennequin
https://github.com/thennequin's depends on the Windows OS AFAICS).
I plan to support os windows too and keep the "pure imgui" interface too,
using concept similar to io::RenderDrawListsFn

As far as I can see, it has load/save support.
It uses my own structures for saving and Lua for loading, but it should
not take more than 10 minutes to rewrite it. However I do not know about
any way/interface to connect to imgui's save/load at the moment and I would
prefer pure imgui save/load.

—
Reply to this email directly or view it on GitHub
#351 (comment).

[Flix01]

Looks great but you can't drag outside the confines of the window it seems. @thennequin's can.

I don't know, I've never tried.
However I've managed to do it with my code (see the updated animated .gif above).

Still, lumixengine's solution is much better than mine.
I guess I'll stop developing mine, maybe making a gist and/or adding it to my imgui branch.

For now this is what I got (and what I need).

If I'll find time in the future (or I'll need something more complete), I know where to look at (= lumixengine's dock system).

[EDIT] Added gist: https://gist.github.com/Flix01/2cdf1db8d936100628c0
[EDIT] Added to my imgui branch and to the central window of the Live Demo Here : press the last button on the top to show it (and it should be straight-forward to turn one of the "lateral windows" into an ImGui::TabWindow, so that it can exchange content with the central window).
[EDIT] Added some changes in the tab label look and serialization, but only in my branch here ATM: https://github.com/Flix01/imgui/wiki/ImGui-Addons-Branch-Home.

[nem0]

@ocornut I refactored it a bit and now it's a standalone file and the code style should be closer to imgui's style. There is still custom save/load.

[ocornut]

Thanks a lot, looking great. I don't know when I'll have time to look at it myself (maybe this week-end?) in the meanwhile I suppose you'll find more things to fix/improve :)

[r-lyeh-archived]

hey @nem0 great work indeed. pretty cute :D

@ocornut,
as a start, and similar to what we did with colorpicker, here you have a more polished version, which should compile out-of-the-box: msvc friendly now, serialization disabled (for now), and overloaded operators for imvec2 are not required anymore.

https://gist.github.com/r-lyeh/a4ff6019062a8c9b402a

to use it just switch from Begin()/End() to BeginDock()/EndDock() as nem0's suggested in #123

[r-lyeh-archived]

is the internal load/save .ini API exposed anywhere? it would be nice to bypass the serialization there

[ocornut]

Thanks! Serialization API isn't exposed yet, the system is really primitive right now.
I haven't looked at the docking data structures yet. Might want to expose INI but there's probably some serious work to be done there even more so if we expect the end-user to use it. We could improve and expose minimal no-warantee-given stuff in imgui_internal.h if it makes sense and that probably would be easier as a first step. Or perhaps the docking data could be stored in a manner that minimize the requirement, e.g. just add a "ParentWindowName" field that is saved in .ini and the rest is sort of implicit from pos-size?

But I haven't really considered the problem in details. There was a request #437 and we might want to move some of the discussion there, personally I wanted to avoid the issue as long as possible but I realise it would be a sort of requirement for docking!

[itamago]

Thanks r-lyeh for sharing this source code.
I started to look at it. It works pretty well !

I see two minor issues, and maybe you have ideas to fix them :

• The flag ImGuiWindowFlags_ShowBorders is not used when the windows are docked. But when they are floating, it is correctly used.
• When detecting if a window is focused, the result is irrelevant because all the docked windows are children of a single window (###DockPanel), so a new function should exist (something like ImGui::IsDockFocused).

Thanks for your help.

[ocornut]

When detecting if a window is focused, the result is irrelevant because all the docked windows are children of a single window (###DockPanel), so a new function should exist (something like ImGui::IsDockFocused).

I haven't been able to look at the docking code yet, but if you refer to IsWindowFocused() it differenciate child windows, so if you call that within the Begin/End block it should work and not give you false positive due to the parent.

The 3 available functions are

bool IsWindowFocused();                // is current window focused
bool IsRootWindowFocused();            // is current root window focused (top parent window in case of child windows)
bool IsRootWindowOrAnyChildFocused();  // is current root window or any of its child (including current window) focused

We could iterate and perhaps adjust on those. Ideally we shouldn't need a new function or we could make existing functions dock-aware if that made sense. Not against pushng minor dock-related features upstream to help

[LawlietRyuzaki]

@ocornut wow, amazing work! Can you share separate window docking, please?

[ocornut]

@LawlietRyuzaki Part of the work in is #1542, docking itself isn't public. Now that Multi-Viewport are becoming more usable I may be able to get back to work on Docking.

[LawlietRyuzaki]

@ocornut Is there an easy way to integrate the docking system from LumixEngine into the multi-viewport system? What need to change in imgui_dock? Thank you.

[ocornut]

I'm not using the LumixEngine docking system so I don't know. I guess you'll have to try by yourself because AFAIK nobody has been trying to combine them.

[nem0]

I tried, it was not straightforward, but also not impossible. I did not have time to finish it and I also don't want to use API that is not yet final.

[JackMcCallum]

Looking forward to these docking and viewports features!

…

On Tue, Apr 24, 2018 at 5:37 AM, Mikulas Florek ***@***.***> wrote: I tried, it was not straightforward, but also not impossible. I did not have time to finish it and I also don't want to use API that is not yet final. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#351 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGQa7ZWyhj1Y1oTaCpahRNuZzVME59LCks5tri1pgaJpZM4GEUn1> .

[JSandusky]

@LawlietRyuzaki I use one of the variants of the Lumix dock (vassvik/imgui_docking_minimal), notes should be close - but may include stuff that's no longer an issue in the Lumix code.

Getting it working with the Viewports stuff was:

• Changing the dock slots drawing to use the overlay draw list instead of a bogus window (dropping the clipping)
• Dock slot and the getDockedRect don't honor the assigned area
  • getDockedRect was doing a mismatch of size vs position based rects, adding max to min is not correct, unsure why it wasn't screaming obvious before
• The dockspace rect given might as well be ignored, had to fix that so border dock slots draw in the right area, ImRect(ImVec2(0,0), GetIO().DisplaySize) is not OK
  • Coordinates look like their in flux, seem to work in client-space right now, didn't bother to check for sure
• Ditching the phantom-painting of the dragged status for treating it like a floating window except with a 0.2 alpha override.
• Cheating to set the ImGuiContext::MovingWindow when status is status_dragged, otherwise it's hit-or-miss on whether an undocked window can promote into a platform window or not, which is super bad if you drag it off window, it'll get lost

Windows that are external viewports obviously ignore the alpha-override, haven't looked into if enabling the compositor on the hwnds for those is viable (it's at least doable on windows, might be too much pain to be worth it though).

Edit: There was already stuff for viewport transparency, two liner change to pass the next window BgAlpha onto the viewport alpha.

[ocornut]

I'd be interested in seeing your exact diff, out of curiosity. While I hope people will want to switch to the future docking system, it's a perfect study case and I'd still like it to be solvable perfectly without touching imgui.cpp.

Changing the dock slots drawing to use the overlay draw list instead of a bogus window (dropping the clipping)

In one of my test I've been trying to work with multiple overlays so they can span multiple windows, but that needs to be perfectly synchronized (it easily exhibit issues where viewports are not refreshed/vsync together). One similar use case is that in the viewport branch io.MouseDrawCursor = true can draw a cursor straddling multiple rendering contexts. Without synchronized vsync you can see shearing when the software cursor straddles viewport.

Coordinates look like their in flux, seem to work in client-space right now, didn't bother to check for sure

Yes I updated the coordinate systems recently in the Viewport branch, basically all imgui positions are now mapping to your natural OS positions (so e.g. on Windows, (0,0) is always the upper-left of the primary monitor). This simplified many things compared the previously virtualized multi-viewport positioning. As a result however, SetNextWindowPos(ImVec2(0,0)) with absolute values are likely not what you want, you can currently use SetNextWindowPos(GetMainViewport()->Pos) (tho remember all those API in in flux). Along with reading back from GetMousePos() being in the same coordinate systems, this will be the only breakage with enabling viewports. And with this approach there will be no change for viewport-unaware application, since the "main viewport" position will stay an untouched (0,0) in those apps.

Edit: There was already stuff for viewport transparency, two liner change to pass the next window BgAlpha onto the viewport alpha.

I'm still working on that, the problem I have is that full-viewport alpha will never be equivalent to the same factor applied on every color so there are annoying discontinuities when transitioning from embedded to separate viewport. Perhaps on Windows 10 we could optional offer support for per-pixel transparency, if you want to experiment with getting this working (my earlier experiments with it failed to get it working).

[JSandusky]

The files can be found in this mashup of the viewport branch into MonoGame that I did the other day, basically monkey-tosses the Win32 DX11 demo into a Windows Forms program. I have a copy of the specific clean sources I used so I can toss a diff up of what I actually changed for viewport purposes somewhat soon-ish.

imgui_dock.h/.cpp has the dock specific stuff I had to do in order to make it work, I did not tackle docking in multiple windows - not something I care for other than as docking tabs.

Wouldn't take any of the changes in there too seriously, monkey tossing poo really to force things to work.

[ocornut]

A bit of an update on Docking, I'm currently working on a V2 (which I restarted from scratch recently) and will start sharing an early branch with selected people in the upcoming weeks, then move it to a public branch to receive move feedback.

GIF from a few weeks ago:

When it is a little more ready-er I will create a new thread and close this one.

[dev0-1]

@ocornut That is really nice you have there! Is there any way I could join the beta program and be early tester? ;)
I have been waiting so long for that.

[ocornut]

@dev0-1 Yes probably, send me an e-mail. It'll be my focus of the next few weeks to move this into a branch.

[dev0-1]

@ocornut Sure, but what is your email address? The one in the readme?

[ocornut]

FOR IMMEDIATE RELEASE
Paris, France: After what seems like forever, just as @ocornut drew his last breath he pushed a WIP 'docking' branch in #2109 and managed to close the old thread #351. The general population of docking enthusiasts are encouraged to scrutinize and report on this effort in #2109.