Editor overhaul mockup - ways to add full customizability

PLyczkowski commented 1 year ago

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

Godot recently took steps to make the editor more customizable via a button to detach windows, among other things.

These kinds of implementations solve a singular user gripe without taking the bigger picture of editor customizability into account. Until that is addressed, requests for ‘one more customizability option’ will keep coming (e.g., ability to see documentation side by side with the code editor).

They also have the bad side effect of decreasing editor accessibility over time (meaning there is no consistency; ‘you just have to know’). Here are some examples of that:

Currently, the way to undock certain tabs is to use the three dots, then the undock button. Others have the undock button always visible.
You can drag certain tabs around to drop them into another area but not the detached ones.
You can’t detach tabs from the bottom area except for the Shader Editor for some reason. When you ‘detach it,’ it actually stays in place and a duplicate is created while the original becomes a blank tab.
A variation of this happens with the Script Editor, which can be detached despite not being a tab. It too stays in place despite being detached (or just its button does). But in its case, clicking on its button focuses the detached window.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The way to solve all similar and future problems of this kind is a proper tab drag and drop and detach system with fluid areas. This being a long term overhaul.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Explanation:

A window is split into a top bar and main area. The main area is populated with areas, which are populated with tabs. Additional windows behave the same.

It’s now possible to close all the open tabs and end up with an empty main area.

An additional drop-down menu is added to the top bar - Window. It contains all the tab types. Choosing a tab type adds this tab to a top left area. If a tab of this type already exists and can’t have duplicates, the tab can’t be added (preferably at least the script, 3D, and 2D tabs can have duplicates).

Tabs can be dragged and dropped between areas. Dragging a tab at an area edge highlights that edge, signifying that a new area will be added there. When a tab is dragged to a non-droppable area, it will be dropped into a new window.

The three dots are area functions: maximize, close, split horizontally, split vertically, tabs align center, tabs align left (The current maximize button is removed).

Right-clicking on a tab shows tab functions: duplicate (if available), detach, close.

The top bar has saved window layouts on it (what is currently under Editor>Editor Layout). These layouts store and restore only the window content, not all windows (layouts can be set/switched per window).

There is a second type of tabs - the tabs within 3D, 2D and Script tabs. The container they sit in is not considered an area and doesn’t have the three dots button. They are distinguished by their smaller height and font and can be dropped only in their original tab or a tab of the same type (e.g., dragging a script from one script tab to another).

The Script tab no longer has a file list in the sidebar; it now has script tabs. 3D/2D tabs no longer have a script icon on the tab for the main script; you use the script icon in the Scene tab instead.

When opening a scene or script, the first tab of the proper type going from the top left is used.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Nope.

Is there a reason why this should be core and not an add-on in the asset library?

Yup.

Project Files for this mockup (Godot 4.1)

Godot Editor Revamp.zip

EDIT:

Some more random mockups: shot_240110_164028 shot_240110_163955 shot_240110_164005 shot_240110_164016

EDIT2: I've been thinking about the 2d/3d split and I'm not sure which is better in the context of Godot where a scene can have both 2d and 3d elements (you can have a 3d scene, add a sprite as a child, and it will show at runtime). Either we could enforce if you make a 2d or a 3d scene (since you can't see both modes at the same time in the editor anyway), and then the current mockups work, or the 2d/3d tabs need to be turned into a generic Scene tab with a 2d/3d switcher, placed here for instance:

Gnumaru commented 1 year ago

In the tweet you said that "for this mockup I recreated the Godot editor in the Godot editor"

Could you share the project for this mockup as a zip file in the proposal description?

Even better if the mockup is functional. I mean, if it let you redock any tab anywhere and rearrange the layout in any way.

Gnumaru commented 1 year ago

Having a fully customizable editor would be very interesting, indeed. There are some already existing apps that allow full or almost full GUI customizability. From the top of my mind I can remember some IDEs (MS visual studio, Eclipse) and other apps (Blender, Krita) and I think anything based on ImGui is very customizable out of the box.

PLyczkowski commented 1 year ago

@Gnumaru I've attached the mockup project files. No, it's not functional, it's a mockup : )

bitbrain commented 1 year ago

I am working with Godot Engine since early 2020 and have been building many games and projects with it already. In every single case, I ran into the issue of having some piece of code that relates to some particular node, but those two being in separate sections of Godot - e.g. the "2D view" needs to be clicked to actually see the 2D node, but then the code editor disappears.

With the undocking/docking feature, that problem has been partially addressed, however, from a design perspective we still are forced into these modes of '2D', '3D' and 'Script'. This proposal attempts to address all these issues from what I can see, which I really like: the user can decide for themselves how they want windows to relate to one another. Also, the tabs are now consistent across scenes and scripts, which is quite intuitive. The one gripe I have is the overload of information/menu I am presented with here:

Capture

Compare this to something like now:

Capture2

Maybe we can find a compromise and build a 'docking'/window grouping feature without introducing a complex UI hierarchy like this, while at the same time making things consistent, e.g. everything has tabs.

PLyczkowski commented 1 year ago

@bitbrain I haven't included tab icons in the mockup, but I'm guessing they would help with the readability of what is what.

PLyczkowski commented 1 year ago

@bitbrain Here it is with added tab icons. I also corrected font size in the middle area and toned down the layouts picker.

Gnumaru commented 1 year ago

The default godot editor GUI could be naively modeled like this:

RootWindow
- SplitContainer(vertical:off)
  - MenuBar
  - MainEditorButtons
  - PlayButtons
- SplitContainer(vertical:off)
  - SplitContainer(vertical:on)
    - TabContainer
      - SceneTab
      - ImportTab
    - TabContainer
      - FyleSystemTab
  - SplitContainer(vertical:on)
    - TabContainer
      - EmptySceneTab
      - OpenedScene1Tab
      - OpenedScene2Tab
    - TabContainer
      - OutputTab
      - DebuggerTab
      - SearchResultsTab
      - AudioTab
      - AnimationTab
      - ShaderEditorTab
  - SplitContainer(vertical:on)
    - TabContainer
      - InspectorTab
      - NodeTab
      - UndoHistoryTab

Now, let's imagine a child class of SplitContainer that is able to handle any number of children instead of only two. Let's also imagine that this child class can only order its children perpendicular to the parent. That is, if the parent is horizontal, it will be forced to split vertically and vice-versa. Let's call it "SlotContainer". Let's rewrite (and simplify) the model above like this

RootWindow
- SlotContainer(vertical:off)
  - MenuBar
- SlotContainer(vertical:off)
  - SlotContainer(vertical:on)
    - TabContainer
      - SceneTab
    - TabContainer
      - FyleSystemTab
  - SlotContainer(vertical:on)
    - TabContainer
      - OpenedScene2Tab
    - TabContainer
      - OutputTab
  - SlotContainer(vertical:on)
    - TabContainer
      - InspectorTab

Let's also imagine that the SlotContainer is able to handle dragging and dropping tabs from it's direct children onto other SlotContainers that have TabContainers as direct children. It would work like this:

When the user drags a tab from a TabContainer which is a direct children of a SlotContainer onto the header of another TabContainer which is also a direct children of a SlotContainer, the tab control is reparented to the TabContainer where it was dropped onto. If the TabContainer where the control was removed becomes childless, it will be freed. If the SlotContainer parent of the TabContainer becomes childless, it will be freed, and all other parents that becomes childless will be freed in sequence.

When the user drags a tab from a TabContainer (which is a direct children of a SlotContainer) onto the area of another TabContainer (which is also a direct children of a SlotContainer) but outside of the tab header, the following behavior occurs:

1) The TabContainer where it was dropped will be replaced by a SlotContainer. 1) The previous TabContainer will become a child of the newly created SlotContainer. 1) A second TabContainer will be created as a sibling 1) The droped tab will be reparented to the newly created TabContainer 1) If the TabContainer that lost it's tab becomes childless, it will be freed from its parent and all parents in sucession.

We whould alsto need to diferentiate if the user is trying to create a new slot in a inner slot (deeper node) or outer slot, but I'll just pretend this issue does not exist for now.

So, using the previous model

RootWindow
- SlotContainer(vertical:off)
  - MenuBar
- SlotContainer(vertical:off)
  - SlotContainer(vertical:on)
    - TabContainer
      - SceneTab
    - TabContainer
      - FyleSystemTab
  - SlotContainer(vertical:on)
    - TabContainer
      - OpenedScene2Tab
    - TabContainer
      - OutputTab
  - SlotContainer(vertical:on)
    - TabContainer
      - InspectorTab

If we take the inspector tab and drop it in the header near the scene tab, we will have this.

RootWindow
- SlotContainer(vertical:off)
  - MenuBar
- SlotContainer(vertical:off)
  - SlotContainer(vertical:on)
    - TabContainer
      - SceneTab
      - InspectorTab
    - TabContainer
      - FyleSystemTab
  - SlotContainer(vertical:on)
    - TabContainer
      - OpenedScene2Tab
    - TabContainer
      - OutputTab

The InspectorTab will be reparented to the TabContainer parent of the SceneTab. The TabContainer where the InspectorTab was will become empty and will be freed, and because of that the SlotContainer which was previously the grandparent of the InspectorTab will also be freed.

Now, if we drag the inspector tab and drop it over the output tab (but not over the tab header), the TabContainer containing the OutputTab will be replaced by a horizontal slot container, the previous tabcontainer will be put as child of it, and a new tab container will be created to be the new parent of the droped inspectortab

RootWindow
- SlotContainer(vertical:off)
  - MenuBar
- SlotContainer(vertical:off)
  - SlotContainer(vertical:on)
    - TabContainer
      - SceneTab
    - TabContainer
      - FyleSystemTab
  - SlotContainer(vertical:on)
    - TabContainer
      - OpenedScene2Tab
    - SlotContainer(vertical:off)
      - TabContainer
        
        OutputTab
      - TabContainer
        
        InspectorTab

For now I'll just also overlook the issue of dragging the tab out and making it a floating window.

Gnumaru commented 1 year ago

Here's the ImGui docking thing:

https://youtu.be/lZuje-3iyVE?t=1608

Found another thing, a really interesting online demo for a Qt docking widget.

https://demos.kdab.com/wasm/kddockwidgets/dockwidgets.html

Also this docking component for react.

https://ticlo.github.io/rc-dock/examples/

YuriSizov commented 1 year ago

@Gnumaru Please use the "Edit" button on your comments.

Gnumaru commented 1 year ago

@Gnumaru Please use the "Edit" button on your comments.

sorry

reduz commented 1 year ago

I think the ultimate test for this would be to make an add-on to see if users find it useful. I don't see any reason why it would not be possible to. Maybe the add-on would not look like the proposal, but you can still have the list of layouts more or less accessible to see if it's actually useful.

TheDuriel commented 1 year ago

This represents a significant loss in vertical screen space, something already at a premium.
A horizontal tab list is limited in the amount of tabs it can reasonably display. For my own work, the script editor must be capable of easily accessing 20-50 related scripts without additional friction. (I consider vertical scrolling to be less friction than horizontal.)

Overall, while more customizability is welcome. It should not come at the loss of usable space. Something a tabbed system mandates.

The example images are of course not helped by their emphasis on thick borders everywhere.

See here. The solution to "you might not be able to fit all the editors you need into one view." is to... add another layer of tabs so you can easily switch views. It's compounding on the problem. Not solving it.

PLyczkowski commented 1 year ago

@TheDuriel For clarification the thick borders are not part of the proposal, just an artifact of my mockup making : )

Also, when switching between 20-50 scripts consider the Quick Open Script command in the editor instead of scrolling through the vertical list - it's Ctrl-Alt-O by default.

TheDuriel commented 1 year ago

Ctrl+Alt+O + Typing / Scrolling to my script is more friction than, ~~scrolling to~~ just clicking on my script. In fact, I use the File Dock and Script List in tandem to quickly reach where I need to.

My editor looks like this in 3.x and 4.x. I was actually tempted to make a proposal about making the Script Editors Script List auto expand on hover to make them more accessible.

Anyways. Sticking with my cautioning of the loss of vertical space. It's highly impactful. I absolutely despise how tiny unity and blender can force your main viewport to be, due to layout and poor usage of space (not to mention unreal) and am quite happy with godot in that regard.

Zireael07 commented 1 year ago

Duriel is worrying about vertical screen space while I tend to be worried about horizontal (I either use a smaller Godot window to see some tutorial on a second window OR an Android tablet). So my preference is for horizontal instead of vertical script list. (Can't find the other proposal # atm)

If we want "full customizability", we probably ought to support both layouts.

jordanlis commented 1 year ago

I don't really understand this proposal and what it solves. I mean, there are good ideas like displaying the docs in another tab next to the scripting tab.

But creating another new tab bar on top of the existing one is just totally confusing. I mean, you have "animation" on this new tab bar then you have animation on the bottom, then you have tabs with different kind of content it's just totally confusing.

I don't really like this approach and I think that the way it is now is quite good :

You choose on what you want to work on "master tabs" (let's call them like this) : 2D nodes, scripting, etc.
Then you can open tabs of this kind of content.

Now we've got different subjects like :

moving "animation" or any other content in these master tabs
displaying multiple content in divided viewport (docs next to scripting)

These subjects could be adressed in different proposal according to me and we should focus on what they are solving. At the moment, I don't see any issue with the current way of working (I have some ideas of small improvements) but this proposal is way too confusing according to me and I don't understand in one or 2 sentences what it should solve.

rainlizard commented 1 year ago

I noticed @PLyczkowski's mockups are displaying the scripts editor but don't include that bottom part where the errors are displayed. Untitled

I actually made a plugin for that, mainly focused on hiding the Scripts Panel (which I recognize isn't for everyone), but it also has the additional feature of hiding the bottom section of the scripts editor when it's not in use. It appears only when a script error occurs, which I think is something everyone could appreciate as it saves a lot of vertical screen space. (Premium space, as @TheDuriel pointed out)

TheDuriel commented 1 year ago

I'm really not sure what you are responding to @Discipol Did you by chance reply to the wrong PR? This is not much of a feature proposal. It is a UI restructuring proposal.

Nowhere is there a disagreement about making Dock arrangements more freeform. Someone just needs to sit down and implement it. This thread is not stopping it from happening.

Crowd driven development means that once an idea has been put forth, someone needs to man up sit down and dedicate the time and implement it. And do it in a form that users want and which does not negatively impact the existing experience.

Though I would like to point out that: Rearranging Docks, popping them out, and many other aspects of this proposal are either already included in the editor or in existing pull requests.

This proposal, like so many others, is going to be irrelevant within a year. Even without being directly addressed. Simply because the individual components of it are being addressed by other proposals and pull requests.

PLyczkowski commented 10 months ago

Tagging https://github.com/godotengine/godot-proposals/issues/1508 since it's addressing the same thing

godotengine / godot-proposals