Status Bar & Statistics re-shuffling
Confirmed, NormalPublicDESIGN
Actions

Assigned To

Authored By

	William Reynish (billreynish)
	Apr 13 2020, 8:40 AM

Description

This is a design document related to recent patches to make changes to the Status Bar and Statistics display in Blender. Several patches will be submitted, so this document serves as an overview of the main reasons why, and the bigger picture of how things fit together.

Currently, the right hand side of the Status Bar is filled with a statistics section:

The issues with this are:

This is only relevant for the 3D View. If, for example, you are using the Sequencer, you still get a permanent display of the number of vertices in the 3D View, which serves no useful purpose in that case
While useful in some cases, for things like making game assets with polygon budgets, we don't need to permanently always show this information
It's hard to read visually, with many abbreviations and pipe symbols in between items
It takes up a lot of permanent room, which could be used to better notifications and also just to show the keyboard input for complex operators

For the above reasons, we would like to make a few changes:

1: Move 3D statistics to the 3D View

Moving the stats to the 3D View allows us to make sure this information only appears where it is relevant.
It also makes it possible to list the statistics in a more readable way that resembles a list:

An important change here, is that this information should not be enabled by default. If you need to see this, it can be enabled as an overlay option:

2: Status Bar changes

With the above change, that leaves the Status Bar with two items: The version number and the amount of memory used.
The version number is mainly something that tutorial makers could optionally enable if they wish, and is not necessary to keep visible by default. While using the app, you don't need a constant reminder of the current Blender version.

The amount of memory used can be useful in rare cases, but usually the system process monitor will give you a more useful display of this information. For this reason we should hide this by default, but we can still include in option to show it:

Right-clicking on the Status Bar here will allow you to show these items optionally, similar to adding items to a system tray.

Because the memory used is hidden by default, we can also include the option to show the amount of VRAM used, which Blender knows but is simply currently not shown.

When we *do* show this information, we can do so in a slightly nicer way than before, by removing the pipe symbols, which broke the spacing between items:

This is much easier to read.

These changes will leave the bottom right side of the Status Bar blank by default. This is intentional. This means we can move the notifications and progress bars here instead, which would allow us to use better notifications, always appearing in a consistent place, without interfering with the keyboard shortcuts:

Related Objects

Mentioned In: D7557: UI: Status Bar Changes
D7410: UI: Show Stats in 3DView
Mentioned Here: D7557: UI: Status Bar Changes
D7515: UI: Comma as Decimal Separator

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Overlay statistics is a very useful feature. People think whether you need poly count or such, no, overlay statistics is for everything you want to show as an overlay. We already have a few stats; framecounter, camera view, collection... this only expands the stats on an optional way.

This is good, now what's not is the implementation it has been done here. We are now chopping the status bar stats and telling what should be shown where... this is bad design. You have people that find the overlay distracting, and there are other that find the status bar not maximizing workspace full screen enough. In such terms you should be able to show the same stats on the status bar and the overlay, otherwise you end up in the middle of nowhere having to disable or enable both.

I already explained on the patch discussion why commited memory or blender version is useful. It should be customizable though, but at this point I don't know if it's worth it having so many free addons that do the job like AStats.

"Blender is known to have issues with heavy meshes, having committed memory is very useful for sculpting. Blender version, the open source nature of it makes it so many people keep at least 2 or 3 versions of Blender at the same time."

One more thing. I see that there was problem before with instanced objects.

Both numbers (initial and total) tris are important for performance. So it looks like there should be 4 numbers for tris in object mode.
Like 16/128 (8/32) where first pair is total numbers for selected and scene and second pair do not count repeating instances.
For edit mode all can be the same, as is.

In T75672#924386, @Vyacheslav (hitrpr) wrote:

One more thing. I see that there was problem before with instanced objects.

Both numbers (initial and total) tris are important for performance. So it looks like there should be 4 numbers for tris in object mode.
Like 16/128 (8/32) where first pair is total numbers for selected and scene and second pair do not count repeating instances.
For edit mode all can be the same, as is.

So we are talking about statistic modes then.

Selection stats mode - selected object stats are shown - useful for optimizing assets/scene. Entire scene / visible collections stats for comparisons can be obtained with selecting everything.
Editable stats mode - every editable geometry stats are shown - current default mode.
Full stats mode - every visible geometry stats are shown, including visible links and instances and etc - useful to control overal scene viewport load when combining final scene to know how much it weights.

Those modes are needed for different types of tasks, therefore there is no need to display them together, so their appearance can be solved with proper design.

In T75672#924488, @Paul Kotelevets (1D_Inc) wrote:

there is no need to display them together

Sometimes I need to see
a) selected/unselected for mesh or objects to understand proportions and compare.
b) as you said, I need total polycount for object to control it in lowpoly.
c) selected/visible/instanced polycount in object mode to undestand how much I can or should keep as instances

But it would be much nicer to have checkboxes, what to show and where + ability to save few presets, or, at least, to make simple text-config file for presets.
And no disputes about what better. I am not a big fan to fill workspace with unnecessary info. But sometimes I need to see it.

I haven't had a problem with any changes made to blender since 2.8 .. and agreed with every UI change so far, as they made sense. But this one, I have to politely, yet STRONGLY disagree with. Here is my reasons & suggestions on the matter (see the image below):

Ahmad Bilal (SomeAB) awarded a token.May 5 2020, 7:50 PM

I'm gonna be "that guy" and say I want it like this:

3 right-aligned columns for scene (only measures objects that are not hidden), selected objects, and selected components, with numbers in fixed locations that have nice spacing in between.

No messy slashes / or pipes | between numbers.
Numbers are not pushed too close to each other.
Numbers don't slide left and right when digits are added or subtracted.

It's just about the most organized and least cluttered presentation you can get.

But maybe with a better stroke, drop shadow, or translucent box to improve visibility on top of bright objects.

And the ability to choose which stats appear since that seems to be a popular request (and makes sense if we're going to add more stats like number of objects selected, multires level, etc..). For example, current collection, object name, and frame number are useless to me and I would prefer they not take up space (and I can do that by unchecking "Text Info" in the overlays, which is good). But others may want to keep that but they do not care about the entire row for UVs or the entire column for Selected Components.

Chris Kohl (ckohl_art) awarded a token.May 5 2020, 10:03 PM

@Ahmad Bilal (SomeAB) = suggestions on the matter (see the image below)

Having the stats in an Editor that is separate from the 3D View means that we could only ever show global scene stats. Ideally these numbers would vary per viewport, for example if you view Local in one it would be nice to just see local stats there. They don't do that now of course, but at least that is something that could be done now.

@Chris Kohl (ckohl_art) - I'm gonna be "that guy" and say I want it like this:

Ideally a mockup for this should include the text overlay as well to better illustrate how much this intrudes into the working area. Even better if it includes part of the interface so we know the scale you have used. Setting the Interface to 1X scale, setting the blender window to something that fits within our required monitor size, and with the capture including the all of the 3D View editor. Again, just to get a better sense of how this fits within the whole.

In T75672#924964, @Harley Acheson (harley) wrote:

Ideally a mockup for this should include the text overlay as well to better illustrate how much this intrudes into the working area.

That's a good point.

setting the blender window to something that fits within our required monitor size

There's a required size? I'm assuming from the context that it's a specified size to reference for testing designs? Is that listed in a doc somewhere?

@Chris Kohl (ckohl_art) - There's a required size?

Sorry, really not trying to make you do anything specific, and really do enjoy all mockups. I just mean it is best if you make it in a way that we gives maximum information and is a reasonable size.

Our minimum requirement is for display that can do 1280×768, but I find that a bit too small to represent proposals well. I generally start with 1X on an 1920 x 1080 monitor with the default theme and default layout. Then I scale it down slightly to give some breathing room around. In this specific case I would then capture the whole thing but clip out just the 3D View editor (including header) since the rest is superfluous to this. The result says a lot about the size and proportions of things.

That said, nothing is ever off the table in this kind of thing. So if your proposal needs a smaller font size then mention that too and perhaps give something to indicate the size difference.

Something else nice for this particular issue is to not only include that text overlay but also to include more variety in the stats display too. The problematic ones for this is the "Triangles" count as it only has a total and not a selected. And there are a few stats like that so they can't always fill a nice grid and where to put the oddballs can look funny. LOL

The stats should be a popover, a dropdown menu with each line as an option, whatever that makes them easily toggleable instead of just one toggle in the overlays.
Blender is not just a modeling app, each workspace should have certain stats shown and their "visiblity" enabled by default.
As of now, we don't have much control over them and them being disabled by default will cause more headaches and bug reports when the 2.83 gets released...so best to avoid that and enabled the stats for all the workspaces/templates.

Remember this is only for 2.9x, not for 2.83.x. As time passes and this conversation continues, and I try to use the new stats, the more convinced I am that we should just re-expose the stats through python to at least allow addons to display them as necessary.

Barring that, then I'll throw support behind the following in hopes of having something that looks and works nice:

Column aligned stats
- 10 digits of space between columns; allows 9,999,999_ to be displayed, higher values are allowed to shift without being aligned. Bonus points if you widen all columns as soon as one column exceeds 10 digits.
Show selected items before their totals. i.e. 5 30 for 5 selected verts out of 30 (not the other way around)
Allow the stats to be individually selected (e.g. I never care about Tris so I never want to see them ever. I don't care about Edges while in Object mode either)
Right aligned text labels

objects 1    2
  verts 5    30
  edges 2    20
  faces 0    15
   tris ...

In T75672#924755, @Vyacheslav (hitrpr) wrote:

But it would be much nicer to have checkboxes,

For sure, we are talking about optional checkboxes.

9,999,999

I know, quantity is always integers, but pleeeeease DON´T ever use comma or point to separate digits like this.

Just compare: «price is $9,999.99» and «price is $9’999.99»

For well-read fonts and high dpi (books) you should use thin spacing.
If it is not enough (font is small, very condenced, very irregular) other thin spacer as «’» (apostroph) or «'» (second) or «´» (unar quote, top comma)
If font very limited and have no thin spaces, no apostrophs, no seconds and minutes — regular spacing, but two spaces before and after digit.
It is very important for fast reading.
And this typographic rule is already broken in Blender.

@Vyacheslav (hitrpr) - ...you should use thin spacing....other thin spacer as «’» (apostroph) or «'» (second) or «´» (unar quote, top comma)

I would LOVE LOVE LOVE to change to using thinspace as digit group separator (yes, we have it in our fonts). I'd rather not consider the others though as they favor the convention in Switzerland and Liechtenstein and I'd rather we went to the new international standard favored by:

For sure, thinspace solution is better for subitizing perception ability.

@Harley Acheson (harley) what do you think about comma instead point as float/fraction separator?
Of course, for input point should remain as more familiar/habital mark.

@Vyacheslav (hitrpr) - what do you think about comma instead point as float/fraction separator?

I wish we could offer a choice for that... https://developer.blender.org/D7515

Okay, Now I see the Idea: statistics per viewport. May be It is nice. Perhaps it is less confusing, than stats in status bar only for active viewport.
But list of stats should be optional and readability over complex backgrounds should be improved.

I see using stats only this way:
No stats by default, I am pressing hotkey, looking at stats (they have solid background), releasing key, stats disappear.

It is very useful bahavior (shift-alike). It is already exist for sculpt (Ctrl for inverse brush and shift key for smooth).

But it have additional power, for example in Paint tool Sai: if key clicked — new brush selected permanently and for next click brush returns to previous.
if key pressed long enough, brush changes, but returns on key-release.
Useful for eraser, for example: sometimes you just need to erase small spot and sometimes you need to work wit eraser long.

The same for stats. Sometimes you want to see it once and sometimes you need to keep it in the corner.

In T75672#927384, @Vyacheslav (hitrpr) wrote:

No stats by default.

No stats by default - no new users knowing that stats exists.
Default stats are needed anyway.

Sometimes you want to see it once and sometimes you need to keep it in the corner.

This is why they need to switch between the status bar and the viewport.

In T75672#925010, @Jesse Y (deadpin) wrote:

Remember this is only for 2.9x, not for 2.83.x. As time passes and this conversation continues, and I try to use the new stats, the more convinced I am that we should just re-expose the stats through python to at least allow addons to display them as necessary.

Hmmm ,I am sure i have seen Pablo's stream showing stats in 2.83 unless that was reverted, i mainly compile 2.90 after the master branch was pushed to 2.90, but if stats are not yet in 2.83 then it's good because all these issues need to be resolved before the official release.

In the Sequencer is the only reason for having the Preferences in the workspace, checking on the render resolution and project FPS, until the user needs to render. If it is possible to have an option to expose these two values in the statusbar in the Sequencer, the Preferences could be removed from the workspace(for rendering, the users can switch to the render tab instead).

In T75672#927389, @Paul Kotelevets (1D_Inc) wrote:

This is why they need to switch between the status bar and the viewport.

What variant do you suggest? Stats only for active viewport?
What is active viewport in this case? Clicked or just mouse over?
What stats it will show, when active area is not viewport?
Remind that we need local stats (selected, or local-space) too.

In T75672#927498, @Vyacheslav (hitrpr) wrote:

In T75672#927389, @Paul Kotelevets (1D_Inc) wrote:

This is why they need to switch between the status bar and the viewport.

What variant do you suggest? Stats only for active viewport?
What is active viewport in this case? Clicked or just mouse over?
What stats it will show, when active area is not viewport?
Remind that we need local stats (selected, or local-space) too.

Last visited viewport.

Okay. So we ended up with:
Switch between status bar and viewport.
Custom list of properties (to have ability to exclude all unnecessary things).
Local/selected stats.

Another one question: should ram/version will be in the same list or separate?
I propose same but with separator.

In T75672#927874, @Vyacheslav (hitrpr) wrote:

Okay. So we ended up with:
Switch between status bar and viewport.
Custom list of properties (to have ability to exclude all unnecessary things).
Local/selected stats.

Well, it seems to satisfy most of possible cases and conditions in my opinion.

Separator

I think it would be nice.

William Reynish (billreynish) added a project: User Interface.May 11 2020, 1:45 PM

William Reynish (billreynish) added a subscriber: User Interface.

Gilberto Rodrigues (gilberto_rodrigues) awarded a token.May 14 2020, 9:34 AM

To me, this would be way better in the Item panel when you press N.

Peter Fog (tintwotin) removed a subscriber: Peter Fog (tintwotin).May 15 2020, 8:56 AM

I was not a fan of this info placement when I used Maya. Could there be an option to display it in a single line of text as it was before at the bottom of the 3d viewport?

Off topic: the whole info bar at the bottom of the overall window, any chance there could be an option to toggle it to the top of the window. It is often full of useful info for some tools (while other tools for some reason show their info within the top of the 3d viewport) and I'd see it better if I could move it to the top.

In T75672#937574, @thin soldier (thinsoldier) wrote:

I was not a fan of this info placement when I used Maya.

Yes, it is well known Maya issue.

In T75672#937574, @thin soldier (thinsoldier) wrote:

and I'd see it better if I could move it to the top.

Indeed, it was a readable way better when it was on top.

@thin soldier (thinsoldier) agree: it is not so handy when some info about current operation in the top of window, and another part (hotkeys) in the bottom.
Perhaps it would be nice to bring em closer to each other.

Frankly, I don't like this change for default. It can be an option, but no default. Vertex count in the status bar is a clear solution. I don't need statistics for all the time in the viewport. Sometimes I need to check vertex count or tris count - that's all. Now I will have to turn on statistics overlay and then turn it off? - that's a stupid idea. I need 3D viewport for 3D creation not for statistics, but I need to know how many vertexes I selected/ how many vertexes are in the loop. And why vertical not horizontal? Respect 3D viewport space and eyesight/vision

Sebstian (bosman) added a comment.May 24 2020, 8:13 PM

This comment was removed by Sebstian (bosman).

I have been working on an addon that provide similar functionality: https://github.com/muhuk/meshstats FYI

Perhaps you can highlight a few ideas from my proposal on rightclickselect
https://blender.community/c/rightclickselect/7qcbbc/

StrictlyIncreasing (StrictlyIncreasing) awarded a token.May 27 2020, 11:58 AM

In T75672#937782, @Sebstian (bosman) wrote:

Frankly, I don't like this change for default. It can be an option, but no default. Vertex count in the status bar is a clear solution. I don't need statistics for all the time in the viewport. Sometimes I need to check vertex count or tris count - that's all. Now I will have to turn on statistics overlay and then turn it off? - that's a stupid idea. I need 3D viewport for 3D creation not for statistics, but I need to know how many vertexes I selected/ how many vertexes are in the loop. And why vertical not horizontal? Respect 3D viewport space and eyesight/vision

I actually agree. This looks so much Maya now... And I thought the stat info in the status bar was so elegant and way better when I switched from Maya. Now the status bar looks kinda sad and useless =)). I'd keep stat data horizontally in the bottom as it was previously, but make it an overlay inside the viewport along with the other info like tips for controls and get rid of the status bar.

Vitalii Vlasov (Fracture128) awarded a token.Jun 3 2020, 10:52 AM

Gilberto Rodrigues (gilberto_rodrigues) removed a subscriber: Gilberto Rodrigues (gilberto_rodrigues).Jun 4 2020, 10:33 PM

Well tbh I never used maya or max extensively, but I like the changes that are presented here. Instead of saying No to this change maybe you guys could try to give some suggestions to improve the new implementation

With the following patch you have the (current) option of showing the stats in the 3D viewport OR in the statusbar as it used to be. Just right-click on the statusbar to see the options:

https://developer.blender.org/D7557

In T75672#956449, @Harley Acheson (harley) wrote:

showing the stats in the 3D viewport OR in the statusbar

Gorgeous. Thank you)

In T75672#956449, @Harley Acheson (harley) wrote:

showing the stats in the 3D viewport OR in the statusbar

Goooood~
Will wait for custom statistic list to get rid of quantity of vertices and edges.

@Vyacheslav (hitrpr) - Will wait for custom statistic list to get rid of quantity of vertices and edges.

What exactly do you want to see in the statusbar stats?

In T75672#957173, @Harley Acheson (harley) wrote:

What exactly do you want to see in the statusbar stats?

In object mode and most of the time it is important (for me) to see amount of tris (selected, full-total, instance-reduced, local view) to keep scene not overloaded. And memory use ofc.
Rarely (in obj mode) I need to know how many vertices or polys I have on the mesh (when I emit hairs/particles for example).

In sculpt mode — triscount mainly. May be quadcount for multires. For current sculpt and total visible in the scene.

In edit mode I also use quantity of selected edges or vertices (for checker deselect or mesh analisis).

@Vyacheslav (hitrpr) ...tris (selected, full-total, instance-reduced, local view) to...

Local View is a per-3d view type of thing. We can (hopefully) one day show local view-specific data in the 3Dview overlay version, but will take some work to get there. But there is only one statusbar for a window that could contain more than one 3Dview so those stats can't take local view in account. Being able to (one day) show differing stats per 3d view was one of the reasons for starting on that overlay version.

I'm mostly asking what you like to see in the statusbar stats in case this is an opportunity to turn that one "Show Scene Statistics" into one or two separate checkboxes. But not really seeing any way that breaks up into any logical groupings.

@Harley Acheson (harley)
In status bar I prefer to see tris selected/total in object mode, in sculpt mode polys on current mesh + total visible. If it is dyntopo polys==tris. If it is quadmesh, polys==quads. Pretty simple.

In edit mode: faces selected/total, tris total, vertices selected, edges selected.

But there is only one statusbar

I thought about it and asked Paul (here, higher). And the idea is pretty simple: you use only one active viewport in every single moment. So you can show stats for one and cache stats until viewport will change.

I am not against statistic per viewport. Idea is nice. But it is hardly readable sometimes. And that is the problem.
Statistics in two or more viewports can benefit only ability to compare em faster. Nothing more.

May be, the solution is switching temporary statistics-background for all visible viewports: if there is noisy scene, you can switch it on and see stats clear.
@Paul Kotelevets (1D_Inc) what do you think about this variant?

In T75672#957681, @Harley Acheson (harley) wrote:

I'm mostly asking what you like to see in the statusbar stats in case this is an opportunity to turn that one "Show Scene Statistics" into one or two separate checkboxes. But not really seeing any way that breaks up into any logical groupings.

Basically, stats are workflow-dependent.

Architectural/CAD/hardsurf/historic restauration modeling types are pretty much ok with the default vertices-oriented stats, because there is no need in exact tris values, and because there are vertices pointclouds as references.
Gamedev/web modeling is all about being tris-oriented. For example, when sketchfab stats were designed, we suggested to make it tris-oriented, since models there are web-compatible. As a result we has got system like

Triangles 404
Quads 173.7k
Ngons 32
Total triangles 347.8k
Vertices 187.3k

Also showing in the status bar statistics of the active viewport is a nice solution in my opinion.
Hopes I got question right.

In T75672#956449, @Harley Acheson (harley) wrote:

With the following patch you have the (current) option of showing the stats in the 3D viewport OR in the statusbar as it used to be. Just right-click on the statusbar to see the options:

https://developer.blender.org/D7557

That is awesome! Waiting for it to be reviewed and implemented, having these options both in viewport for real-time editing and at the bottom for huge scenes with the ability to turn them off is the way to go!

Julian Eisel (Severin) moved this task from Backlog to Blender 2.90 on the User Interface board.Thu, Jun 25, 12:26 PM

Julian Eisel (Severin) edited projects, added BF Blender (2.90); removed BF Blender.

I didn't want this piece of feedback above to be lost: As time passes and this conversation continues, and I try to use the new stats, the more convinced I am that we should just re-expose the stats through python to at least allow addons to display them as necessary.

Is it planned to add back the python scene.statistics API, in some form, so that addons can more flexibly put stuff in the viewport if desired? I feel it's a needless API break especially now that the stats string was added back to the status bar area.

Continuing a design discussion from D7557 here.

There's a question of at which level the status bar options should be:

Preferences -> Settings are "global" for a user
Status-bar -> Settings can vary for every .blend
Screen-layout (or workspace?) -> Settings can change with the screen-layout (or workspace).

A mixture is also possible. E.g. we could have a default defined in the preferences, but still have the actual settings in the status-bar, so per .blend.

I think the viewport overlay settings would stay where they are, so be per viewport.

I don't think that saving statusbar per .blend is a good idea - because it will make necessary to change it every time you've got some file from another person (like product manager from multiple artists during production process).
Also, statusbar is independent from the workspace, so statusbar is independent from workspace changes by definition.
So it will be better to make statusbar option saved per application, as a global preference.

Viewport statistics is ok to be saved as regular overlay, since it is a regular overlay.

This way the placement determines statistics saving behavior, and this is pretty much expectable solution.

In T75672#969758, @Paul Kotelevets (1D_Inc) wrote:

it every time you've got some file from another person

Even working with different projects, I use similar settings for similar workspaces.

In T75672#969648, @Julian Eisel (Severin) wrote:

I think the viewport overlay settings would stay where they are, so be per viewport.

Agree.

Here a raw idea.

Status bar statistics per application (On/off/what to show).
Status bar settings per file (On/off/what to show)
Checkbox for «override status bar» in the open dialog (same place as «Load UI» checkbox) and file browser will remember state of checkbox permanently (per application).

Ability to switch on the fly (from status bar context menu) between two presets: by file by application. This settings will influence «overide status» checkbox in the filebrowser.

Need critique!

I don't remember that kind of switching override anywhere in the software.
Also, I don't see the reason to keep statusbar setup per file on the off-chance.

The question behind storing statusbar stats per file is "do I need to see statusbar setup made by someone for his purposes?"
I can't find cases, that could possibly bring other answer than "no".

Statusbar stats is always set up to provide info that is needed to your workflow. It is your tool, that you would like to see in the way and order, predictable by you.

It's not so much that per .blend file is important, but per workspace, which come along with .blend files by default. Statistics about the number of vertices would be disabled in e.g. the video editing workspace if we supported this.

How well that works for you depends if you use the Load UI option or not, but there is a use case even for individual users that use Blender for multiple purposes.

In T75672#975194, @Brecht Van Lommel (brecht) wrote:

It's not so much that per .blend file is important, but per workspace, which come along with .blend files by default. Statistics about the number of vertices would be disabled in e.g. the video editing workspace if we supported this.

How well that works for you depends if you use the Load UI option or not, but there is a use case even for individual users that use Blender for multiple purposes.

This is fair for overlay viewport statistics, which, for sure, is and should be workspace dependent (as a regular overlay), while statusbar is not a part of a workspace system.
We are discussing statusbar one, which is used when viewport is overloaded or when realtime stats control is not needed.

The "Show Status Bar" option is per-workspace, by the current the design the statusbar is definitely part of the workspace.

And just logically, it makes sense that the statusbar can be customized for every workspace. If it's worth the trade-off is a decision to be made.

In T75672#975255, @Brecht Van Lommel (brecht) wrote:

The "Show Status Bar" option is per-workspace, by the current the design the statusbar is definitely part of the workspace.

And just logically, it makes sense that the statusbar can be customized for every workspace. If it's worth the trade-off is a decision to be made.

I am a project manager, that works with multiple artists.
So, does that means that I should just lock "load ui" option forever to get predictable stats, to avoid having a deal with everyones creativity?

But that's already the case isn't it? Every artist can create their own custom workspace, have multi-window setups, etc. The statusbar doesn't seem like a big step beyond that.

So, everybody, including me and all our artists should keep that option off to work togerher on a complex project?
To simulate saving settings per application on every load instead of just having it?

If you care about having the same user interface layout every time you open a .blend file, then yes? If not, no? Or you can all use a shared set of workspaces? None of this is new.

I don't care particularly strongly about the choice here, there are pros and cons. I think in terms of consistent design it would have to be part of the workspace, but inconsistency is sometimes needed for practical reasons.

I mean, the flexibily of Blender setups, stored per file, makes Blender scene too much personal.
More flexibility - less control, more control - less flexibility.
Extensive flexibility makes issues during teamwork.

If there is no ability to provide defaults that will satisfy everyone, and everyone will create its own approach using providen flexibility, measures should be taken to avoid mess during intensive teamwork.
Teamwork should be taken into account during design.

For instance, if you provide a solution that requires "Load UI" checkbox state lock permanently, you should at least provide "Load UI" checkbox state lock option.

It is a preference already.

Yes, but this preference influences everything, including, for example, viewport layouts.
You are able to reset everything just to obtain proper stats or reset nothing and resetup stats manually every time.
So this question is not that simple.

Maybe we will end up with yet another "setup my blender" single button script that will control statusbar stats, normals display, facedots display, tweak tool selection and other things that are usually resetuped every time, to launch it on every scene opening.
A preset-driven personalizing setting over settings.
It will override setup stored in file, keeping windows layout.
It is hard to imagine other affordable solution.
Too much actions needs to be taken before you start working with someone else's scene at the moment.

In T75672#975131, @Paul Kotelevets (1D_Inc) wrote:

The question behind storing statusbar stats per file is "do I need to see statusbar setup made by someone for his purposes?"

For me it sounds different: someone did settings, situable for this certain file and probably I would like it.
Or: I made different settings for this file (sculpt preset) and I don`t want to switch settings every time I go from sculpt to retopo preset.

I agree with Brecht it is more important per workspace and per pipeline.

@Paul Kotelevets (1D_Inc)
I suppose, We will end up with few presets for each workspace.
Now, when I add new workspace to existing file, It loads from default template with almost all settings
So you will have similar workspaces with your work group, but everyone can have his own tweaks via presets.

In T75672#975429, @Vyacheslav (hitrpr) wrote:

I agree with Brecht it is more important per workspace and per pipeline.

For sure, every artist will vote for such flexibility during single work, and start setup war during intense teamwork, driving project managers insane.
Known issue.

Now, when I add new workspace to existing file, It loads from default template with almost all settings

Do you mean for hundreds of views of different files per day?

I suppose, We will end up with few presets for each workspace.

Some of the people we work with do not even use workspaces.

Do you mean for hundreds of views of different files per day?

No, I use similar views and similar workspaces for different templates.
And it is obvious to use some standarts for studio work. But it is obvios too, that each artist wants a bit more comfort and tweaking workspace for himself.

In T75672#975533, @Vyacheslav (hitrpr) wrote:

And it is obvious to use some standarts for studio work.

Yes.

But it is obvios too, that each artist wants a bit more comfort and tweaking workspace for himself.

Yes.

Here is the conflict we are trying to make less painful.

@Paul Kotelevets (1D_Inc) So for you, the best solution will look like «override someone`s settings by defaults»
Is it right?
Probably, I would prefer the same in most cases.
But it is good to have ability to override settings per workspace + editable templates.

In general: theoretically we will have few levels of influence on settings: global (application), file-template, workspace
And common list of templates: each of them tell Blender what to show or not in the status bar.
So user can decide, what will rule.
Application? Okay — one for all, easy to manage.
File template? Spend time, set up once for each file, use it. I think, file templates usually used for one pipeline.
Workspace? Select existing template from previous tuning, change it a little, save.

Conditions.

If application rules, no matter what settings are in file or workspaces. They saved there but ignored.
If not: 2a. If workspace have own settings, use it or delete it. 2b. If workspace settings not exist, use file settings and you can create settings for workspace.

Now it works pretty similar with workspace settings: we can retune em, or delete workspace and create it back with settings from default file.
And if there is no template for them, blender uses factory settings.

Conditions.

If application rules, no matter what settings are in file or workspaces. They saved there but ignored.
If not: 2a. If workspace have own settings, use it or delete it. 2b. If workspace settings not exist, use file settings and you can create settings for workspace.

It is pretty much complex proposal, I want to analyze it.

Turning Load ui checkbox off is an emergency option, so using emergency option for regular work is quite strange, and usually depicts that system have a problem.

I need some time to think about system requirements.

But turning off UI isn`t required. Just turning on override for status bar in settings.

p.s. I turn off UI not only in emergency cases (broken ui) but even if someones workspaces are too crumpled for me and it is easier to understand project structure without it, step by step with my own UI

In T75672#976332, @Vyacheslav (hitrpr) wrote:

But turning off UI isn`t required. Just turning on override for status bar in settings.

Yes, I mean, if developers propose solution, that requires permanent UI load lock as the main working tool, we need to look for better possible solutions, like, may be, your.
So we need to analyze it to check how much is it better, at what cost, and so one...

p.s. I turn off UI not only in emergency cases (broken ui) but even if someones workspaces are too crumpled for me and it is easier to understand project structure without it, step by step with my own UI

Guess you do not use it often, do you?
So is there really too much difference between broken UI, and UI that causes recognition problems from the point of usability, if you use the same tool for fixing them?

Guess you do not use it often, do you?

True
And yes, generally not so much difference: both are UIs causing problems.