Reports & Warnings UI #68448
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
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#68448
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 Blender, we want to improve how the app communicates to the user, for things like warnings, info, reports and progress bars.
We already have several separate systems for this:
We have a message popup in the status bar
We also have a separate 'Info' editor
We can make this nicer by tying things together more. Here's how.
Info editor improvements
First, we need to add support for displaying messages, warnings and errors inside the Info Editor. We can do this by adding a switch at the top:
{F7655925, size=full}
When set to Messages, you'll see a list of messages and reports over time.
Currently we have two categories of messages: errors and info, but we can add a third:
This makes it clearer to the user if a message is positive (success), neutral (information) or negative (error):
Each message type has an associated color. In the Info Editor Filter popover we could filter by type.
Readability
The current Info Editor is impossibly difficult to read, visually. Everything is unseparated with text-wrap. The contents just become a wall of text that is very hard to read:
D6491 already implements some large benefits to readability by separating each notification and adding a header icon: {F8253216, size=full}
We can do even more, by using progressive disclosure to let users open or close notifications, like so:
{F8253348, size=full}
Status Bar
We can make a few improvements to the Status Bar also:
Click on message to open Info Editor window
By clicking on the message or warning, you could be taken to the Info Editor. Simplest way is to spawn it as a new window.
Persistent error symbol
If an error is unresolved, we can keep an error symbol in the Status Bar, so that the user knows the error still lingers.
Remove file info from Status Bar
Currently there isn't much space to display full info messages and warnings in the Status Bar, because the file info is in the way.
We have received many requests to move the file info elsewhere:
In a vertical list, there would be a lot more space to communicate this kind of information, and we could add a lot more. This could be moved to the viewport, or in a Stats panel in the Scene Properties, for example.
With this out of the way, we have a lot more room for nicer messages and warnings.
Added subscriber: @WilliamReynish
Added subscriber: @brecht
Added subscriber: @JulianEisel
Since this gets into the idea of repurposing of the info editor, I'd recommend checking out what we've considered during the UI workshop: https://archive.blender.org/wiki/index.php/Dev:2.8/UI/Workshop_Writeup/#Info_Editor. The full info editor should always be reachable from the status bar (e.g. a {nav More} button could spawn the info editor in full screen, or as separate temp window). So basically the status bar would be the short version of the Info Editor, the latter containing all details.
There are many examples of how other apps handle notifications. For example I like how Visual Studio Code does things:
I.e. a little bell icon with the number of currently valid notifications in the status bar, clicking it lists them. Also, I wouldn't mind if we get rid of the banner thing, and display notifications more conventional. Again Visual Studio Code is a good example: Show them in the lower left, make it easy to dismiss and move them.
Yes that's part of the idea. Pressing on the notification would open a temp Info window.
Could do that, although then they would overlap with other editors and content.
Right, we wouldn't want to be too intrusive for info or low-importance warning messages. A bit of color and animation can be handy to draw the users eye here, but an overlapping popup would be too much.
OTOH important messages like errors should be intrusive - when we get one, the workflow was already disrupted, the message just exposes and explains that fact. So IMHO a popup is fine here.
Added subscriber: @JonathanLampel-4
Looks useful!
When working with operators you might want to see errors as well. If we add a fourth filter for operators instead of a switch, wouldn't it be both more flexible and more simple?
Added subscriber: @Poulpator
We have to be careful about making a system where users have to constantly dismiss notifications. Personally I don't like the Visual Studio Code notifications much, or similar macOS and Windows notification systems. This is not due to the implementation, but due to about the large majority of notifications being useless to me. It's tempting for a developer to think that their notifications is very important and must be handled by the user, but all those add up.
Users are not programmers that need to fix every warning or error, and even as programmers we are not great at solving all warnings in the Blender code. The same goes in production, ideally every problem would be solved, but very few people have the discipline to work that way and we can't expect them to.
For persistent errors, I would like to see specific examples of what would be a good use of that. If users can't resolve them easily, it's a bad user experience to have that red icon always there. After a while users will start to ignore those errors. At the moment I can't think of one example that I would consider appropriate as a persistent error.
Think of things like cyclic dependencies or missing texture file paths.
I don't think those should be persistent errors. In production these things happen, and the person working with the assets is not necessarily able to fix them. Users should be able to easily get an overview of such issues, but that's different.
Added subscriber: @EAW
Added subscriber: @Harley
Looking into this a bit. I don't think I'd go with so much color as the entire window would look like a Christmas tree. One of my biggest peeves of the Info editor is how all items run together, especially since most wrap to multiple lines. I'd be inclined to:
Following is a mockup. On left how it looks currently, right is proposed with the exact same events. The last things done were deleting and then changing a region to a "Text Editor"
On the left I find it difficult to even know how many items there are. And I find the alignment and order to be odd.
@Harley or we could also just make the icons colored
That's true. But when I experimented with just drawing the icons with a color, instead of a colored background, they seemed to have not enough strength especially something like "caution yellow" on a light background.
Of course all up for debate and I'll defer to whatever you like. But I didn't even like zebra striping in this case (unlike so many other editors) just because of how many items are multi-line. In my capture above you can see that the existing zebra stripes don't help much to differentiate the items.
The kicker though is it is more work than you would guess...
The reason why Info displays odd (anchored to the bottom and with new items last) is because it and Python Console share drawing code. Specifically Python Console uses Info's TextView to draw itself. So you can't change one right now without it affecting the other.
In fact you get funny things like both editors define their own "CONSOLE_DRAW_MARGIN". So if you want to change the margin for Python Console, guess which one you alter? Wrong. You have change both of them. LOL
About the only good strategy I can think of right now is to simply extricate Python Console from Info's TextView code. That way each can then draw themselves any way they want. Console can get a bit of love, and then Info can get some nice padding, alignment, order, and icons.
But might make it harder to review.
Added subscriber: @ideasman42
The
CONSOLE_DRAW_MARGINissue has been resolved, replied in more detail regarding implementation here D6300#148092@WilliamReynish - Now of course you actually use Blender, unlike me (LOL), so you would have a better sense of how the Info Editor might be actually be used...
But I've always imagined it to be less informational and more practical. So rather than hide any of the details it would be all about the details. So I imagine right-clicking on any entry and selecting an item on the context menu to re-run that command. Maybe select a few in a row, assign them to a macro "slot", and then you can run them together as a group. That sort of thing. Might even be possible to save to macros that could be run on arbitrary objects if we play with them a bit.
Of course it can move in any direction that users want. This was just how I always imagined it going.
@Harley indeed that is something that was always planned, even since 2.5! The ability to record a macro and then store it as an operator which users could then re-run. But technically it turned out not to be easy to handle many cases in practice.
In any case, that functionality is only tangentially related to the Info editor, although yes, it would be a useful way to invoke this kind of thing.
If we ever get filtering it would be nice to then allow the inclusion of extra reports. I think we can, right now, start blender with command-line arguments that then log more detailed reports, including things like simple item selection. But they only go to the console. So we might be able to enable that same behavior within Info Editor.
Added subscriber: @brezdo
Added subscriber: @CobraA
This is much needed, is it possible to move everything from the system console to the info editor? I don't know about the other OS but on windows it's a big annoyance that you have to keep checking the system console and it doesn't help when it's a separate floating window.
Added subscriber: @grzelins
Removed subscriber: @brezdo
Added subscriber: @Diogo_Valadares
I don't know if I can ask for this here, if not I'll delete the comment but could we get warnings that prevents operations that could make blender stop working, for example entering edit mode in high poly meshes, increasing a value in a modifier like remesh or subdivision or rendering something without enough memory in the system?