Adding support for multiple viewports.

[LennysLounge]

Dear-Imgui has the docking branch where it supports docking and multiple viewports.
The egui_dock crate is a good start to get docking into egui.

Viewports allow you to take some egui ui (most likely a egui::Window) and display it in its own native platform window. This is great because a egui::window is now no longer contrained to its host window and it can expand freely beyond it. For docking it is interesting because it allows you to take a docked tab and undock it into its own native window.

Actually implementing the multiple viewports is a feature that the windowing integration would have to implement.
For this reason it is only really relevant for platforms that support the idea of multiple windows in the first place. Egui would still have to support the idea of viewports to the bare minimum to make it possible for a backend to integrate it correctly.

Current constraints

Currenty, everything that happens within a egui::Context happens within the same viewport. A egui::Window cannot escape thie viewport of the cotext it is created in. To have multiple viewports means having multiple contexts too. Properly implementing this with a nice api for the user is quite a bit of work. The end user api could look something like this even:

// This is within the original egui context
ui....
ui....
backend.viewport(|ctx, backend|{
    // This is the new context
    egui::CentralPanel::default().show(ctx, |ui|{
        ui....
        ui....
    });
});

This is suboptimal because it requires you to use this particular backend for your project. Any library like egui_dock would then require you to use a particular backend.

What could egui support look like.

Egui could add some mechanism to create a new viewport. Lets call it egui::Viewport for now. What this does is that it tells egui to associate any shape drawn within this viewport with a unique id. The backend can then look at all shapes that are generate for this frame and decide for itself, if it needs/wants to render those shapes in a new platform window or not.
For the user this looks like this:

ui...
ui...
egui::Viewport::new().show(ui, |ui|{
    ui...
    ui...
});

All using the same context.

Thirdparty libraries like egui_dock can now safely create a new viewport and either benefit from multiple platform windows or revert back to the current behavior. The downside of this approach is that every viewport associated with a context is rendered every frame. This is just how immediate mode guis work and i dont see a way around this. However it is still possible for the backend to provide a way to create new contexts with their own windows and their own render cycles.

What can egui do now:

Egui has the egui::Area container. Per the documentation it is :"the foundation for windows and popups" which is exactly what is needed for viewports. In the end_frame method of the context, these area are sorted and drained of their shapes.
If egui could return the list of areas instead, then the backend can sort the areas themself and draw them all in a single native window or split into multiple windows.

Of course there is more work to do to make the interaction across the main viewport boundaries correct. However i feel like changes to egui are relatively small. Changes to eframe however would require quit a bit more work.

Conclusion

Having viewports and by extension proper multi window support can push egui quite a bit forward in terms of usability for desktop applications. It allows thridparty libraries to create better docking, file save/open dialogs, confirmation dialogs, error messages etc.