You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I was wondering if there's been any discussions about using the viewports feature but in a scenario where the platform windows are owned and maintained by the application. This would happen for example when retrofitting Dear ImGui onto an existing application, which already has a framework of creating, moving and docking (platform) windows and would like to use ImGui for additional rendering.
One approach would be to keep each platform window completely indepenent and give it its own ImGui context, without using the docking branch. This would work for truly independent content, but breaks down if you'd like to implement drag & drop of items (not ImGui windows) from one platform window to another.
The docking branch would get us very close, as it has a single context and maintains separate draw lists for each viewport. What would be needed is a way for the application to register its platform windows (and a viewport per window) with ImGui, as well as functions to update them (e.g. when the window is moved/resized).
The scenario I'm describing is probably well outside the scope of the docking/viewport branch, but if there any suggestions on what I should watch out for if I was to try and do this myself that would be super helpful!
Docking Dear ImGui windows into a parent application dock can be done by creating a Dear ImGui window and DockSpace pair for each of the parent application's docks. Then the backend code perform any necessary special handling for docking into the parent application when initializing the DockSpace's parent window's viewport.
I use this technique in ReaImGui for docking Dear ImGui windows into REAPER's docks.
Hi, I was wondering if there's been any discussions about using the viewports feature but in a scenario where the platform windows are owned and maintained by the application. This would happen for example when retrofitting Dear ImGui onto an existing application, which already has a framework of creating, moving and docking (platform) windows and would like to use ImGui for additional rendering.
One approach would be to keep each platform window completely indepenent and give it its own ImGui context, without using the docking branch. This would work for truly independent content, but breaks down if you'd like to implement drag & drop of items (not ImGui windows) from one platform window to another.
The docking branch would get us very close, as it has a single context and maintains separate draw lists for each viewport. What would be needed is a way for the application to register its platform windows (and a viewport per window) with ImGui, as well as functions to update them (e.g. when the window is moved/resized).
The scenario I'm describing is probably well outside the scope of the docking/viewport branch, but if there any suggestions on what I should watch out for if I was to try and do this myself that would be super helpful!
#1542
The text was updated successfully, but these errors were encountered: