UI: Expand List of Editors #54744
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
16 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#54744
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
** - New: Shader Editor (for Material/World/Line)
** - Compositor
** Texture Editor is not included as it is to be removed
** - New: UV Editor
5c8f1053b5**
- New: 2D Paint(postponed for 2.8x release)**
- New: Mask Editor - Read note below.(postponed for 2.8x release)**
- Image Editor -> renamed to Image Viewer, put in the Data category(postponed for 2.8x release)Animation
Scripting
Data
New: Image Viewer(postponed for 2.8x release)New: Assets Browser(in the future) (postponed for 2.8x release)Notes
Added subscribers: @Sergey, @pablovazquez, @WilliamReynish, @ideasman42
Added subscriber: @Blendify
I like these changes a lot of sense and I like them, especially Mask Editor.
Added subscriber: @Januz
+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).
Added subscriber: @ErickNyanduKabongo
@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 :)
Added subscriber: @Leroy-Xie
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 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.
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.
Added subscriber: @L0Lock
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
756b70c6c3for 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.
Added subscriber: @JulianEisel
I think the best way to go about this is what we agreed on during the 2.8 UI workshop:
See https://en.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Info_Editor.
@JulianEisel sounds good.
Added subscriber: @hjsrabi
This issue was referenced by
1ab08a2dffAdded subscriber: @JulienKaspar
@ideasman42 @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?
@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:
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.
@WilliamReynish 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?
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.
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 :)
Added subscriber: @moisessalvador
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
@WilliamReynish
Well we shouldn't decide weither to split features based on naming conventions. It's not really that straight forwards :D
Let's rather decide it based on functionality and usability.
But my questions and concerns above still stand.
One of the main reasons to do the split, is because of speed and discoverability.
Speed: It's much faster to directly be able to select the UV Editor, rather than first having to go to UV/Editor and then find the UV mode
Discoverability: A lot of users were having trouble finding the UV Editor - we were even getting bug reports about it not working, when in fact they hadn't enabled UV mode in the image editor.
Simplicity: UV Editor and Image Editor clearly and unambiguously discribe to the user what data they are editing, and what they are used for.
Naming: This means we can use descriptive names. Rather than ToasterFridge, we can call one thing Toaster and another thing Fridge. Same for UV/Image Editor. UV Editor and Image Editor are just nicer, more direct and more descriptive.
Added subscriber: @frameshift
I don't disagree with this, to be honest. A UV editor has always been a separate, extensive tool in other software packages, even if they possess functionality like texture painting. They are related features, but not necessarily ones that need to be combined. By that logic, the image and shader editor could have been combined just as well. I've never hated the UV/Image Editor, but it was confusing at first to find both of them in 'just' a sub-menu of one and the same editor.
That said, it would be cool to know what the plans for the UV editor for the future are. Separating it from the image editor, and therefore regarding it as a full-fledged editor in its own, would only really make sense if it's going to be extended in such a way that the user interface would make the UV/Image Editor too extensive and complex to remain one and the same thing. And to be honest, it could use some love.
@WilliamReynish
Well I would argue that I would only have to have one UV/Image Editor open before and I can easily use that one for multiple tasks. Switching between two Editors in a menu with dozens of them is already more time consuming than just switching between 2 modes in the same Editor.
But what happened to me already is that the 2 Editors look completely the same and are even keeping in sync in their navigation and the shown image and so I'm never sure in which Editor I'm currently in.
In the Shader or Comp Editor and the Dopesheet or Graph Edior you at least get different content shown. In the UV or Image Edior you can display both UVs and Images. The difference is that you can only edit one of them in specific Editors, which is unnecessary in my opinion.
Again: What if you have two 3D Viewports but only in one of them can you Texture Paint.
Well I could say the same right now about not being able to edit UVs in the Image Editor when I'm not noticing that there are 2 Editors now.
Or a couple months back the Texture/Vcolor/Weight Opacity Overlays were introduced and multiple people here at the studio couldn't figure it out and committed bug reports and asked developers about it.
In time people will understand and good communication and naming can help with that. But in the first moment everyone can be left confused.
So does the UV/Image Editor. It's just combining the 2.
@frameshift
I agree. If there's enough new feature planned to significantly make the 2 Editors different then the current changes make sense. But if more Tools and new UI elements can be added if it's a different Mode in the same Editor then I would absolutely prefer that instead.
@JulienKaspar
I think it's very much a matter of apples and oranges. Your example of texture painting requires your viewport to show your 3D scene. But UVs and images are, although related, different things. Editing UVs is even a pretty isolated discipline: it 'requires' the mesh to be pretty much final, and it similarly implies that your texture is by no means sacred either, if even there already.
An image being displayed in the background is therefore in many cases a convenience feature when editing UVs, but certainly not required all the time. Let alone enabling you to paint on it in the same editor. Same goes for the opposite scenario: painting textures in 2D will often benefit from showing the UV layout overlay, but not necessarily all the time - and especially not edit those UVs without adapting your model to prevent stretching. Which is something I personally do the other way around.
Again, I've never hated the combined editor, but for the above reasons I do feel good about the devs taking the opportunity to split them and let them expand separately.
Added subscriber: @brecht
I think the separation could be more like this:
In that case you could still have texture painting in the UV Editor.
Removed subscriber: @moisessalvador
@brecht What if I wanted to paint on the World texture? Good idea about separating mesh-related data and independent images. But I still don't see why UV editing and image painting have to happen in the same editor, especially if they're going to limit data access to what is selected in the viewport.
I would suggest this:
I currently don't have an opinion on the Mask Editor, haven't used the functionality before.
@frameshift Right now I don't really care about the question:
You can apply this to any part of Blender and separate everything into different editors instead of modes.
There are reasons why this is a bad idea but I don't want to discuss this much further without this question being answered:
@WilliamReynish @brecht @ideasman42 @pablovazquez
Why do they have to be different editors? Or more specifically: What do we gain from separating them?
I am really dying to know the new Tools and interface changes that must be planned to make the UV Editor not just better than it currently is but it's own thing and not just a downgraded copy of the UV/Image Editor.
If the image editor is supposed to be split into more editors like the "Image Viewer" and the "2D Paint" then this questions extends to those as well.
And unfortunate naming conventions such as "UV/Image Editor" is not a good argument in itself to split the editors :D
UV Editor: For editing UVs
Image Editor: For editing the image
The advantage is in clarity, speed and discoverability.
@WilliamReynish To be honest, that's not really answering @JulienKaspar's question. And I must admit I've asked the same before. What are the plans for the editors after they've been separated? Any new tools planned, UI revamp, ..?
The question was: What do we gain from separating them?
That question was answered a few times already.
@WilliamReynish Let's bring up some new arguments please ... or at least reply to / build on top of the ones from before ;)
It's pretty simple: There are more advantages in terms if ease of use when they are split vs combined.
Going to the UV Editor but not being able to edit UV's was confusing. Likewise, opening an image editor without the ability to edit images was also confusing.
Now, users can much more easily find what they need: UV Editor for editing UV's and Image Editor for editing the image.
It's the same reason why the Graph Editor and Driver Editor was split too - you go directly to your task, rather than having to jump through a confusing hoop on the way.
If you are new to Blender, this kind of approach makes these things much easier to find and use, and on top of that it's faster too, because you can split your editor and go more directly to what you need. So it's a win in terms of discoverability and a win in terms of speed. That is the reason.
@WilliamReynish And I personally agree with all that. It's just that @JulienKaspar and I had another question that for now remains unanswered:
Whether or not that's related to splitting editors. We're just wondering.
As far as I know there are no major changes planned to the UV editor tools and interface, nor does having it as a top level editor or sub mode really affect what can be done. That is not the motivation for making this change.
You would do that in the image editor. If texture paint mode provided some way to paint the world texture in the 3D viewport, that could be supported in the UV editor as well (though clearly the name is not very good anymore at that point, it's more of a texturing editor).
For the same reason you do both in the 3D view. The UV editor would be providing a different view on the same data. In some other apps this can also show shaded results, with the result of the material node setup rather than a single image. Maybe in a better baking workflow it can act as a preview too.
If we keep the Editors separate then I like @brecht suggestion and I'd like to try to flesh the idea out a bit.
@WilliamReynish
I don't disagree that the discoverability by splitting the editors would become better. With speed I disagree and clarity I'm also not so sure about because the Editors are almost interchangeable . The thing is you only discover them once but use them every day. That's why I stand by my argument:
If we split the editor it should be justified by giving you different information in each, or a different way of editing them. Don't ONLY restrict access in editing data.
So here's my proposal which will probably mean much more work but some aspects can grow and evolve over time:
Instead of the Image Viewer, UV Editor and 2D Paint we have 2:
In the Image Editor we can view and paint images just like now in the current image editor. So this editor is mainly supposed to be used for images without involving objects. UVs will never be displayed.
The 2D Viewport can be a responsive counterpart to the 3D Viewport. (Similar to the 3D View and 2D View in Substance Painter)
When changing the mode in the 3D Viewport the 2D Viewport will follow into a similar mode.
When Texture painting it's in Paint Mode, when in Edit Mode it's in UV-Edit Mode.
When in Object Mode you will see the UVs of all selected Objects. I'm not sure about editing UVs in Object mode with this idea. It could be done but there's some features missing then like the ability to keep the UV and Edit Mode selection in sync or only show the UVs of selected geometry.
For weight painting & vertex paint it could give a flat version of the vertex colors or vertex weights based on the active UV Map.
But this could be generally made much more powerful like @becht suggested.
The 2D Viewport could be switched to different shading modes (independently or in sync with the 3D Viewport, I'm not sure.):
This would be a much better addition in my opinion and would make both editors functionally and visibly different.
But instead of having the split between editing UVs or editing Images these modes would be about either editing only images or editing images and data in relation to objects and materials.
2d Viewport & Image Editor: There's no intuitive connection to any use-case for '2D Editor'. With the UV Editor and Image Editor it's simple and clear. Nobody is confused about what these are for. It's immediately obvious.
Let's keep it simple and clear, and not introduce all sort of unnecessary confusion.
And the speed advantage is a real thing. Every time you split the viewport to add a UV Editor, you save a step by being able to go directly to UV Editor.
Alright, I can see that this change is here to stay. No more resistance and no more devils advocate on the current split. There are just a couple of things that I would suggest:
Make it immediately clear that the user is either in the UV Editor or Image Editor.
Display the UVs very clearly at all times for all 3D Viewport Modes when in the UV Editor and maybe make them available for editing outside of Edit Mode (I know it's planned for Object Mode at least). This should make it clear that the current Editor is the UV Editor. Otherwise the 2 Editors are interchangeable.
Don't split the Image Editor into "Image Viewer" and "2D Paint" Editors.
I really hope that this is not planned and the task description is just out of date. What is the point of an Editor if you just "view" something and actually edit it somewhere else?
Unless there are some features planned to make them both their own thing, the split is pointless in my opinion.
If for example in "2D Paint" you always paint on the active texture of the selected material and even possibly get an optional 2D preview of the mixed nodes of the Material, then I can see this being a thing. This way both Editors would have behaviours that requires them to be separate.
I guess this suggestion is outside of the scope of this task and might make things confusing but this is nonetheless so relevant to bring up.
I totally agree with @JulienKaspar here. I've always found it super annoying that I had to go into edit mode just to see the UVs on a mesh. In object mode, it could even just display them, and only make them editable in edit mode - this would be very intuitive across Blender, and similar to the way Maya works as well, for example.
I have to agree here too. Please don't give us Photoshop and Windows Image Viewer in the same application.
Yes, that's exactly right. With the UV Editor separate, It makes it possible to add things like UV display or even editing while in Object Mode. It's one of the nice benefits.
Added subscriber: @De3n
really don't like this change, no more features, what's update in 2.8, more is split. split the 3d viewer, split the editor. this not means more features. combine is more useful, ex. less select from drop-down list. one editor do more things.
Removed subscriber: @frameshift