Page MenuHome

Reports & Warnings UI
Confirmed, NormalPublicDESIGN

Description

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:

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:

We can do even more, by using progressive disclosure to let users open or close notifications, like so:

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.

Event Timeline

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 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.

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 More button could spawn the info editor in full screen, or as separate temp window).

Yes that's part of the idea. Pressing on the notification would open a temp Info window.

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.

Could do that, although then they would overlap with other editors and content.

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.

Looks useful!

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.

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?

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.

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.

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:

  • Anchor the items to the top, rather than the bottom
  • Show newest items first
  • Increase the space between items, but not between individual wrapped lines.
  • Add an icon column that can help show importance and help break into items

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 Acheson (harley) or we could also just make the icons colored

@William Reynish (billreynish) - 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.

The CONSOLE_DRAW_MARGIN issue has been resolved, replied in more detail regarding implementation here D6300#148092

@William Reynish (billreynish) - 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 Acheson (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.

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.

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?