Hosting windows on multiple viewports

[Coen4622]

Version/Branch

Version: commit 49fb8e6c451b53dddd0be061d9e2aaeecb27ff76 Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_SDL.cpp Compiler: VS2017 Operating System: W10

My Issue/Question:

I want to be able to merge imgui windows in other imgui windows/viewports using multiple displays. I am currently working on a grid where this only works on a windows platform level (as seen in the end of the GIF). Is there any way to do this?

Screenshots/Video

// No code example needed

[ocornut]

Hello,

You haven’t much clarified your issue/question compared to yesterday. I still don’t understand precisely what you are looking for, nor what you have done or tried already.

-Omar

(PS: next time please reuse same issue instead of opening duplicate issues, thank you)

[Coen4622]

Apologies for the duplicated issues,

When I drag my window out of the SDL renderer, a new viewport / platform window is created. When you drag this back into SDL, the window is being merged into it and the viewport / platform is destroyed. I want this behaviour to happen when I drag one imgui window into another OUTSIDE SDL. Is this possible?

Thank you for the quick response,

Coen

[Coen4622]

The title is more clear now, however I must ask whether this is possible at this moment?

Thank you in advance,

Coen

[ocornut]

Hello, It isn’t possible at the moment (unless docking into another window).

There’s a Host flag for viewport which is used for the main viewport. We need to refactor that to 1/ make the main host viewport optional and 2/ also the user to have more than one.

It may be already possible with some work but there’s various code that assume that only the main viewport has the host flag.

[Coen4622]

Yeah I got a hard coded proof of concept working earlier. Thank you for the response. However this is of course not a solution due to the need of updating imgui regularly

[fungos]

I've been hacking something that would make use of a generic solution about the Host flag (and related things like window handle, owned flag). So, for this reason I'm commenting here as I think this issue overlaps with my current situation.

Omar, I'm sure I've seen somewhere, you saying something about supporting (or not) the use of Dear ImGui's windowing/drawing for replacing the OS window frame, and I'm not sure if your opinion changed since then considering the Docking feature that is 98% there already.

And considering that Dear ImGui is increasingly being used for more than debug ui tool for games - as evidence in gallery issues shows, we see aHavi lot of desktop applications using it to replace classic desktop GUI toolkits - I ask here what is your interest about this right now, and would you be open to accept PR in this direction?

[ocornut]

@fungos I'd be happy to look into such a change. In fact I received a similar patch from @malamanteau colleague two months ago. I haven't looked at it yet because it was provided as an entire folder (a little unwieldly) and when I tried to extract a patch I ran into carriage returns issues and I put that on hold. I'll try to extract their patch and post it here a base for discussion.

[fungos]

Right, my current solution is more of a workaround as I tried to not be too intrusive into core code as a way to easy merging and upgrading versions. I can give a shot into doing it the right way, and if you do want help, I can look at the work from @malamanteau and try to isolate and simplify into something mergeable / PR-worth and at the same time see if I can salvage something from my current work into it.

[ocornut]

I took some time to turn that folder into a patch then made it fit for the latest version. Attached the original patch + latest one with a few minor changes/fixes. I hope I didn't make a mistake in there, had to reapply all changes to imgui.cpp manually as the code drifted in quite some location (mostly due to large moving of code done since).

host_viewport.zip

I think it is unfit for merging as-is, but it pretty much covers the locations that needs to be looked at and is a great reference to work on this topic and look at design issues.

I'm probably going to see if I can make some easy changes in the current branch to simplify this going work (e.g. stop relying on viewport 0 being a main viewport, but rather use or add individual flag).

[Coen4622]

That's mostly what I did to make a proof of concept working. I had some edge cases though, like merging a docked window into the second viewport would cause a crash. Thank you for looking into this!

[fungos]

So I had a little free time to work on it, did a bit of cleanup and some fixes to asserts being triggered in different situations. Now, the major outstanding issue is in relation to (probably) the vp 0 or a missing update to the root viewport.

What happens is that after moving a ImGui window and hosting it in another OS window, it seems to still keep referencing the vp 0 as a reference for draw positioning.

This is easily reproduced by instancing a second os window, dragging a ImGui window into it and then resizing the OS window. I spent some time trying to track where this happens, but still didn't find how this is managed internally. I'll keep looking as this is related to the issue I currently have trying to make the ImGui window itself to match the root viewport, but any hints where to focus will be awesome.

[fungos]

@Patuti found the issue and fixed it. Here a new version rebased on top of latest docking branch: https://github.com/fungos/imgui/commit/3e6fd152eda334dceba0b7ad95dc5a12f0d83274 This looks good, I'll now focus on the feedback on the design and then move on to the feature I need myself (binding a imgui window to the host viewport).

[fungos]

Updated the changes to latest origin/docking here https://github.com/ocornut/imgui/compare/docking...fungos:host_viewport?expand=1