Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Obsolete 2D, 3D, Script, Assetlib and MainWindow in favor of dockable tabs like Unity Engine #1890

Open
Shadowblitz16 opened this issue Nov 24, 2020 · 9 comments

Comments

@Shadowblitz16
Copy link

Shadowblitz16 commented Nov 24, 2020

Describe the project you are working on:
Sprite Editor

Describe the problem or limitation you are having in your project:
Not related to the issue

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Make center panel obsolete in favour of true dock system. and resource/node based editors like what unity does

This allows developers more control over what their workspace looks like.

  • Want to have 2d window docked on above and 3d window docked below?
  • Want to drag the inspector tab over to main window?
  • Want to resize a side panel so its bigger then the 2d or 3d viewport?
  • Want to have tab based scripts windows so you can use the whole horizontal space to code?

All of these can be achieved with a true docking system.
you would literally be able to dock panels in panels in panels

This would get rid of the need to have dock buttons on panels because you could literally drag and drop it anywhere beside anything.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Basicly the editor would have 5 dockable area's

  • center
  • top
  • bottom
  • left
  • right

You would be able to enable panels through a view menu and dock them in each area or have them floating.
Each tab would additionally have these 4 areas where you could dock things to split it regardless of weather its docked or floating...

  • top
  • bottom
  • left
  • right

A script editor is opened by clicking on a script or a existing script tab.
2d a 3d scenes would be abstracted away into a scene view control with a 2d and 3d toggle tool mode similar to unity.
The asset lib would be relocated under the project menu.

Each of these panels would be resizeable to 0 or the whole editor size and both x and y axis
When they become hidden due to resizing them too big or small they would need to be enabled again through the view menu

Plugins would then be made to support opening custom editors when a Node or Resource is selected
Resources would probably require a double click

If this enhancement will not be used often, can it be worked around with a few lines of script?:
I can guarantee this system would be used more because its mostly the same system its just more flexible.
Also it can't be worked around without redesigning the whole editor with plugins

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

@YuriSizov
Copy link
Contributor

Just look up how unity3d editor tabs work

It's easy to say "just do it the same way as that other thing looks", but this requires actual practical proposed solution and research into the matter. This proposal provides neither. We all have our wishes about UX of the editor, but we need concrete suggestions, not vague ideas. Sorry.

@fire fire changed the title Make 2D, 3D, Script, Assetlib and MainWindow obsoleate in favor of dockable tabs like unity Obsolete 2D, 3D, Script, Assetlib and MainWindow in favor of dockable tabs like unity Nov 24, 2020
@fire fire changed the title Obsolete 2D, 3D, Script, Assetlib and MainWindow in favor of dockable tabs like unity Obsolete 2D, 3D, Script, Assetlib and MainWindow in favor of dockable tabs like Unity Engine Nov 24, 2020
@Shadowblitz16
Copy link
Author

I edited the original post

@Zireael07
Copy link

Duplicate or related to #1508 ?

@Shadowblitz16
Copy link
Author

@Zireael07
They are related but not a duplicate .
Mine add more to the table then his suggestion

@Zireael07
Copy link

I wasn't sure, that's why I said "or" :P
At any rate, it's good to have a link to related issues.

@FeatherAntennae
Copy link

FeatherAntennae commented Apr 8, 2021

I love the idea, but I think the whole docking system using predefined section is kind of clunky and is bound to have limited functionalities that will inevitably conflict with someone's idea of a perfect workspace.

I think the implementation could be made simpler and more flexible if we took a different approach to the whole thing. I think Blender has a good approach for this.

First we'd need a better "subdivisable container" with only a few basic purposes :

  • Contain a subdivisable area with children containers.
    • By default, only one.
    • Can add as many subsections as we want, but they're either ALL vertical or ALL horizontal. (Adding children "subdivisable container" to a section to have both horizontal and vertical sections is my suggestion, but it could probably be done straight in the container too.)
    • Subsections can be resized independently by dragging a division between them.
    • Each subsections can set an optional minimum size, maximum size or forbid resizing in which case there's no or a different divider.
    • Each subsections can by default be collapsed completely. This wouldn't remove the section, just give it a size of 0 and stop it from rendering anything.
    • Right clicking a division should give a menu allowing to (shortcuts possible):
      • Resizing (but not removing) one of the two sections to zero, so the other one takes all the space.
      • Fill the parent container with one of the two division (left or right / up or down), automatically collapsing (but not removing) all other sections.
      • Fill the parent container AND it's own parents recursively, if they're also "subdivisable containers".
      • These functions should be accessible through code so we can show a button that would automatically collapse a few sections in one go if wanted.
  • Each sections can hold other containers (same or different types) which:
    • Can be set through code.
    • Can be done by the end-user by dragging and dropping another element that would then fill the section.
    • Can show a dropdown with a list of all "dockable" / "pinable" default views that could be shown there. (this would require the API to expose a full list of all the type of views available.
  • Each sections can be "popped", removing it as a children and becoming it's own floating window with all its children, which could in turn, be pushed back into a "subdivisable container" as a new section.

This would make every part of the editor a lot more flexible while also making it a lot easier to maintain by immensely reducing the complexity. We wouldn't have to differentiate between a few dozen different types of docks, windows, popups, menus, tabs, and views JUST for visually organizing the editor.

We would just have a list of windows / views / containers that would really be just floating sections waiting to be either pinned to a "subdivisable container" or popped as its own window that can be "docked" or "pinned" to any of those container in time.

Engine devs could build a solid default workspace that's easy to tweak as needs evolve, plugins could add different workspace configurations for the user to choose, and the user could change the entire workspace as they need.


Not that I think everything should be redone from scratch, far from it, but I think that to get something like this to work well, we need to make abstraction of the current content of the editor and how it is actually implemented (because that's very much spaghetti), while keeping in mind only what type of content is or could be in the editor at the highest level; without thinking about the sub-components.

Looking at it as such, the editor is pretty simple. The main elements are :

  • A tool/menu bar which can contain:
    • A menu (Currently main menu)
    • Buttons and drop downs (Currently play/pause/stop + debug + backend select)
    • Switches (Currently 2D/3D/Script/AssetLib switch)
  • Main Screen views (2D/3D/Script/AssetLib) which can be made to stretch horizontally.
  • Popup Windows like the editor and project settings, which I honestly wish I could just open as tabs.
  • Containers that can be both a floating window or docked.
    • Some can stretch vertically (bottom dock)

It would be pretty easy to reproduce this behaviour with such a container available, while also making it easy to improve.

@Jummit
Copy link

Jummit commented Apr 8, 2021

I love the idea, but I think the whole docking system using predefined section is kind of clunky and is bound to have limited functionalities that will inevitably conflict with someone's idea of a perfect workspace.

l but I think the implementation could be made simpler and more flexible if we took a different approach to the whole thing. I think Blender has a good approach for this.

This is quickly getting off-topic as many proposals do, but I think it was already decided that a fully-customizable UI system is not on the table, because it makes it harder to make context-dependent adjustments.

I have no strong opinion on the matter, but I made a "Customizable UI" plugin that adds what you described: https://github.com/Jummit/customizable-ui, which could be used for reference.

@Shadowblitz16
Copy link
Author

Shadowblitz16 commented Apr 9, 2021

@FeatherAntennae I really don't want to do anything like blender's split containers.
I find blender to be the most unintuitive gui layout possible

@Jummit what do you mean context dependant adjustments?
I still can't use godot on my 1 monitor screen with youtube which unity can do fairly easily

@Anutrix
Copy link

Anutrix commented May 10, 2023

Now that godotengine/godot#62378 is merged, what's the plan 2D, 3D, Asset Manager sections. Any plans on making them also undockable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants