Page MenuHome

UI: Expand List of Editors
Open, NormalPublic

Description

In 2.79b the Editor Type dropdown was a vertical list of literally all the editors available in Blender.

In Blender 2.8, the first step of splitting this list into columns/categories makes the layout a bit clearer. But we are still showing only the editors themselves, hiding a lot of important features under sub-editors.

Some examples of hidden functionality is how the Compositor and Shading Nodes editors are combined into the Node Editor entry even though their purpose is completely different. And with Animation Nodes or Modifier Nodes in the future this is only going to get worst.

This proposal is to expand sub-editors into their own entry to gain exposure and discoverability. They would work as sort of shortcuts to their own section.

List of changes:

General

  • 3D View -> simply renamed to 3D Viewport
  • Nodes Editor ->
    • New: Shader Editor (for Material/World/Line)
    • Compositor
    • Texture Editor is not included as it is to be removed
  • UV/Image Editor ->
    • New: UV Editor rB5c8f1053b5f0
    • New: 2D Paint
    • New: Mask Editor - Read note below.
    • Image Editor -> renamed to Image Viewer, put in the Data category
  • Movie Clip Editor -> renamed to Motion Tracking

Animation

  • New: Drivers (sub-editor of Graph Editor)
  • Timeline: Now a sub-mode of Dopesheet Editor
  • NLA -> simply renamed to Nonlinear Animation

Scripting

  • Info: see note below

Data

  • New: Image Viewer
  • New: Assets Browser (in the future)
  • User Preferences: remove it

Notes

  • Mask Editor: The Mask editing functionality is duplicated in both the Image editor and the Movie Clip. The only difference is that they work with either Images (or render result) or Videos. These could be merged into one single editor, to be discussed with @Sergey Sharybin (sergey).
  • Info Editor: I propose to remove it from the list. The top-bar will take over the menu entries, the status bar will take over the stats. The print of the operators runned is better fit as a sub-editor of the Python Console.
  • Remove menu header. Not only makes it cleaner but also makes the "Editor" in entries not redundant. Removing 'Editor' from some entries introduce confusion (e.g. "Shader" could be confused with Properties or the Asset, "Graph", "Text", etc).

Event Timeline

I like these changes a lot of sense and I like them, especially Mask Editor.

+1 to all these changes. Question: would it be too wide if scripting was the 4th column? It looks kind of weird below animation (maybe because it's the only one like that). Also, that way the properties panel would get a shortcut (on e).

@venomgfx it seems like you forgot some of this guys here ;) and i m afraid that all this might be too crowded, I don't know you guys decide :)

Only one problem, why don't show hot keys in editor lists, lots editors have hot keys, but no body know it, even for lots old users. Please keep hot keys.

@venomgfx it seems like you forgot some of this guys here ;) and i m afraid that all this might be too crowded, I don't know you guys decide :)

I didn't forget them. They are the same kind of data applied to different types, so they do belong as sub-editors. Unlike cases of completely different kind of data like Compositor vs Shading nodes.

Only one problem, why don't show hot keys in editor lists, lots editors have hot keys, but no body know it, even for lots old users. Please keep hot keys.

I'm a huge advocate of the hotkeys for editors, I use them constantly. That said, for Blender 2.8 we should be careful about which hotkeys do we ship with (anyone can still set their own hotkeys), but that's another topic for another thread.

Why remove the user preferences from the list ?

Why remove the user preferences from the list ?

It's confusing to mix editors for actual productions with those for personal/system preferences. Usually User Preferences are under an "Edit" menu, which Blender now has!

Committed rB756b70c6c34d596558f6fadf808ecb2a4bf8e3bf for node space types only.

Other changes here require more refactoring - eg, adding a new mode for the image editor.

Regarding the info space.

The keymap, operators and selection work differently so merging with the Python console isn't really nice.

Also, if we are to have some kind of logging the user can see - this isn't something you would think to use a Python console for (you might want to see a log of actions but not care about Python).

While the info space currently it's weak - I'd rather not mix it with the py-console. Instead - improve usefulness of logging / debug output - for eg, the ability to view output from our C logging API.

I think the best way to go about this is what we agreed on during the 2.8 UI workshop:

Info Editor

Since we plan to introduce the global top bar, we can also repurpose the Info Editor. It would be the expanded, much more detailed version of the status bar. Our place for all kinds of statistics and logs.

The Info Editor could contain:

  • Notification logs (log of last displayed warnings, errors and hints)
  • Information about currently open .blend file
  • Log of executed operators
  • Detailed information about on-going jobs
  • Diverse statistics (memory, polygon count, object count, ...)
  • Hardware/Driver information (maybe system-info.txt can be integrated a bit nicer here?)

See https://en.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Info_Editor.

Aaron Carlisle (Blendify) triaged this task as Normal priority.Tue, Nov 13, 6:38 PM

@Campbell Barton (campbellbarton) @Pablo Vazquez (pablovazquez)

I'd like to know more about the reasoning behind splitting the UV/Image Editor into 4 distinct Editors.
I get the reasoning behind making a Mask Editor since the masks are used in other Editors as well, but I don't see any reason for the others.
So we'll we have 3 editors that basically look the same and share similar functionality. To me this change seems very nonsensical and unintuitive.
Are all these Editors going to share the same interface and selected Image anyway, syncing up on all times in terms of panning and zooming? Then why have them separate Editors when we already had them as separate Modes.

This seems to me like splitting off the different Modes in the 3D Viewport into seperate Editors. You do different tasks in each but they share the same interface, switching between them is easy and fast and entering a different mode already gives a new set of Tools with only minimal necessary interface changes.

These workflows are much closer together and it's the same with Images and UVs since they interact and can be overlayed on top of each other.
So I really don't quite get the need for splitting the Editors. Is there something I'm missing?

@Julien Kaspar (JulienKaspar) I'm not sure what you are talking bout with splitting UV/Image Editor into 4 distinct Editors. It isn't split into 4 - it's split into 2: UV Editor and Image Editor.

There are a few reasons for the split:

  1. UV vs Image Editor edit different categories of data. With the UV Editor, you don't edit the image at all, but the UVs. For Image Editor it's the reverse.
  2. The old way had a lot of confusing implications for the toolbar
  3. With this change, we can better support UV Editing in Object Mode too

tdlr: It allows us to support tools better, allows for more interesting possibilities later on, and is a more logical split from users perspective, to either edit image or UVs.

@William Reynish (billreynish) Right now it got split into 2 Editors but I was talking more as in what is planned (Or what I think is planned)
I think I misread one point above. I got the impression that the "New: 2D Paint" means that it becomes its own Editor as well. Would this still be part of the Image Viewer?

With the UV Editor, you don't edit the image at all, but the UVs. For Image Editor it's the reverse

Isn't it more like that in the Image Editor you "View" the image. That's why it will be renamed into "Image Viewer" right?
And in the UV Editor you would do both. That was the confusing part for me. The only moment when the image gets edited is when painting but since this was also handles as a separate mode (at least I hope it will still be), having a mode for editing the UVs too made sense to me.

In the 3D viewport you would also paint textures in Texture Paint Mode instead of editing the mesh or the objects themselves. Each mode is different but the general UI stays the same.

With this change, we can better support UV Editing in Object Mode too

Wouldn't that also be possible if the UV Edit Mode stays in the UV/Image Editor? You could select multiple Objects and switch to UV Edit Mode from the UV/Image Editor. You wouldn't need to switch to Edit Mode in the 3D Viewport.

Another question I have is: Would the view manipulation (zoom, panning) stay synchronised between the UV Editor and the Image Viewer or are these Editors planned be completely separated?

I think I am very interested in the improvements and Tools that can be added when the UV Editor is its own thing. If a lot can be gained then I guess I'm ok with that. But with the current version these changes make no sense to me.

The fact that we used to have to call it the UV/Image Editor in itself demonstrates that it makes more sense to be split.

The Image Editor can be used for editing the image - UV Editor for editing UVs. Pretty straight forward.

No need for Toaster-Fridges :)

I'm going to side with Julien. Being able to switch between UV editing with or without images, Image viewing with or without UV's, and Painting with or without UV's, is more easy as one editor. There are enough permutations and combinations that separating it into two editors will make some of those permutations not possible unless they are added as redundant features from one editor to the other, which is more work for developers. Also, the bespoke UV editing mode was a great adition for handling tools and the toolbar, I don't see how that isn't enough for things like Object mode uv editing