Editor overhaul mockup - ways to add full customizability #7233
Comments
PLyczkowski
changed the title
|
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. |
|
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. |
|
@Gnumaru I've attached the mockup project files. No, it's not functional, it's a mockup : ) |
|
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:
Compare this to something like now:
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. |
|
@bitbrain I haven't included tab icons in the mockup, but I'm guessing they would help with the readability of what is what. |
|
@bitbrain Here it is with added tab icons. I also corrected font size in the middle area and toned down the layouts picker.
|
|
The default godot editor GUI could be naively modeled like this:
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
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:
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
If we take the inspector tab and drop it in the header near the scene tab, we will have this.
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
For now I'll just also overlook the issue of dragging the tab out and making it a floating window. |
|
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. |
|
@Gnumaru Please use the "Edit" button on your comments. |
sorry |
|
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. |
|
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. |
|
@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. |
|
Ctrl+Alt+O + Typing / Scrolling to my script is more friction than,
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. |
|
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. |
|
I don't really understand this proposal and what it solves. 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 :
Now we've got different subjects like :
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. |
|
I noticed @PLyczkowski's mockups are displaying the scripts editor but don't include that bottom part where the errors are displayed. 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) |
|
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. |
|
Tagging #1508 since it's addressing the same thing |
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:
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:
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:
The text was updated successfully, but these errors were encountered: