Add dock widget support

[kkoreilly]

Describe the feature

This would be somewhat similar to the already existing splits, except instead of having a gradient handle for how much space each component should get, there would be discrete buttons that toggle each component between being displayed or not.

In fact, it may make sense to add dock functionality as an option on splits, since you may want to use both at the same time; they are not mutually exclusive. I put an example of how this could look below, although we would probably need more than just a bool option, depending on where you want to place the dock and how many different modalities you want it to have; in #742, one of the example dock widgets appears to support going between hidden, small, and full size.

I can probably work on this soon, although it would be helpful to have some more feedback about dock positioning and modalities for intended use cases.

Relevant code

sp := core.NewSplits(parent).SetDock(true)
core.NewText(sp).SetText("First")
core.NewText(sp).SetText("Second")

[runrc]

The Rust based GUI framework Egui dock has docking type functionality.

It would be useful to have the ability to,

• create dockable windows, which automatically dock into a tab or split an existing window into 2
• allow tabs for docked windows to be dragged in order to make a layout of multiple docked windows
• dockable windows can be resized, closed, dragged and docked

The following shows examples.

[rcoreilly]

The Drag-n-drop support in Cogent Code would probably need some improvements to support this egui-dock kind of functionality, including #33 for going across different windows and apps. #84 is also related. Our current event handling happens mostly on a per-Scene level, via the Events type, so coordinating across different Scenes (windows) would potentially require some additional global event coordination infrastructure.

In general, everything is a widget and widgets can be put anywhere, so there aren't any other obvious in-principle barriers to implementing such a thing in terms of the contents of the panels.

Overall, there are a number of issues with this kind of functionality that personally limit my interest in pursuing such a thing, but nevertheless, it would be good to ensure that the framework can support it if someone wants to implement it:

• It doesn't translate well to mobile and web, which are single-window platforms, potentially with small screens. In general our focus is on providing GUI designs that naturally translate across platforms, so you can CORE (code once, run everywhere) with one codebase.

• As a user of apps that employ this kind of highly customizable layout stuff, I find myself quickly getting lost, and spend more time than I would like fiddling with the layout rather than getting work done. Metaphorically, I feel that it is like the difference between C++ and Go: there is so much complexity and so many different ways to organize everything.. wouldn't it be nicer if there was a much simpler, general-purpose way of doing things? Exerting a bit of austerity and discipline might end up producing improved usability.

• For example, in the Cogent Code editor, a very simple "4 panel" design works quite well, with a file tree, 2 editor panels, and a collection of tabs for all other functions. In this design, you always know exactly where to look for any kind of random thing like find results, debugger, etc. Also, we make everything accessible using the app chooser, where you can search for all commands, files, etc, providing direct text-based access to all functionality in one spot. OTOH, on smaller screens, it might be useful to have the tabs panel go along the bottom instead of the right. But that is easily accomplished with a single toggle somewhere, and doesn't require any of the complexity of the egui_dock thing. Also, we are planning to add a double-click on split handles to collapse and expand them, along with better builtin support for persisting tab splits.

• In terms of a general-purpose implementation of this kind of approach, it seems like there are many app-specific decisions and constraints that would be needed, in terms of what kinds of things make sense to go where, and how it all connects together, that I wonder about the utility of a single framework for this functionality. You could quickly end up in a bad space of parameterizing the functionality with complex declarative data structures, in a way that inevitably won't handle the one case you end up needing.. So a more component-based, flexible, code-driven implementation would be better.

[rcoreilly]

Also all the little widget "handles" (e.g., tabs) for each panel need to live somewhere, so you need to build in spaces for these to live -- these seem like important app-specific design decisions in general. In VSCode and Adobe products, these handles proliferate everywhere and are generally rather obscure and hard to identify, and they definitely need bits of space in various places.. lots of complexity to this it seems.

[runrc]

I agree with the premise that these types of complex configurable layouts are more suited to large screen desktop type applications, rather than single, smaller screen mobile type devices.

Additionally, I also agree a more simplistic approach is better across multiple platforms. Even simplistic functionality would still be extremely useful in allowing users to organise multiple complex views.

[kkoreilly]

I agree with @rcoreilly about the general idea that excessively complicated GUI layouts are not good, and should be avoided if possible. However, I also recognize that sometimes more sophisticated functionality may be necessary.

I am certainly in favor of the changes proposed in #996, and I hope that those will fulfill most of your needs. If you have specific situations in which you need more functionality than #996 provides, please tell us about them and we will work with you on figuring out a way to structure them well. It is possible that may reveal a need for more advanced dock-like functionality. I don't want to implement things that aren't necessary, but I am absolutely happy implementing complex things if they are necessary for real use cases.