Proposal: Remove bottom headers #61244

New Issue

William Reynish · 2019-02-06T16:37:19+01:00

William Reynish commented

2019-02-06 16:37:19 +01:00

Following on from D4302 here.

It may be good to remove the ability for headers to be at the bottom of editors. Here's why:

Popovers don't work well when opened from the bottom.
When the height varies, the contents gets pushed around:
Opening old blend files is now a pain, because users have to go ahead and manually move all the headers to the top
It makes it possible, or at least easier, to add footers to some areas, such as in the Text Editor to better give space for the file path:
We can then remove the header position preference, which is a small simplification.

Following on from [D4302](https://archive.blender.org/developer/D4302) here. It may be good to remove the ability for headers to be at the bottom of editors. Here's why: - Popovers don't work well when opened from the bottom. When the height varies, the contents gets pushed around: ![Screenshot 2019-02-06 at 16.21.21.png](https://archive.blender.org/developer/F6528942/Screenshot_2019-02-06_at_16.21.21.png) - Opening old blend files is now a pain, because users have to go ahead and manually move all the headers to the top ![Screenshot 2019-02-06 at 16.26.03.png](https://archive.blender.org/developer/F6528950/Screenshot_2019-02-06_at_16.26.03.png) - It makes it possible, or at least easier, to add footers to some areas, such as in the Text Editor to better give space for the file path: ![Screenshot 2019-02-06 at 16.31.50.png](https://archive.blender.org/developer/F6528993/Screenshot_2019-02-06_at_16.31.50.png) - We can then remove the header position preference, which is a small simplification.

William Reynish commented

2019-02-06 16:37:19 +01:00

Added subscriber: @WilliamReynish

William Reynish commented

2019-02-06 16:37:43 +01:00

Added subscribers: @ideasman42, @JacquesLucke

Duarte Farrajota Ramos commented

2019-02-06 17:16:28 +01:00

Added subscriber: @DuarteRamos

Demeter Dzadik commented

2019-02-06 17:27:24 +01:00

Added subscriber: @Mets

Demeter Dzadik commented

2019-02-06 17:27:24 +01:00

As someone who moved all their headers back to the bottom when moving to 2.8, I think we should keep the option.

I would however suggest making all headers be in the same position for all panels of the same type. Ie., if you flip a header to top/bottom, in a 3D View, it should flip in all 3D views, in all workspaces. This could be taken further to where the "Load UI" button under File->Open ignores these header positions, ie. the header positions would become part of of user prefs, not necessarily exposed in the user prefs UI, but they could be.

I like the idea of footers but they could simply be on the opposite side from where the header is.

As someone who moved all their headers back to the bottom when moving to 2.8, I think we should keep the option. I would however suggest making all headers be in the same position for all panels of the same type. Ie., if you flip a header to top/bottom, in a 3D View, it should flip in all 3D views, in all workspaces. This could be taken further to where the "Load UI" button under File->Open ignores these header positions, ie. the header positions would become part of of user prefs, not necessarily exposed in the user prefs UI, but they could be. I like the idea of footers but they could simply be on the opposite side from where the header is.

Harley Acheson commented

2019-02-06 17:36:07 +01:00

Added subscriber: @Harley

Harley Acheson commented

2019-02-06 17:36:07 +01:00

First, I love the idea of editors always having an (optional) header on top and (optional) footer at bottom. So I am very in favor of removing the option of headers on the bottom.

However, this should not be tied in any way to popover issues as they are not really related.

For example, take an editor (with header at the top and also has menus and popovers), put it at the bottom of the main main window and make it smaller. At some point you see that the pulldown menus necessarily pop up, rather than down. You'll see that the popovers also pop up. I don't think you are proposing eliminating this feature.

The central problem is that we are opening up a temporary window that is tied to a location and so odd things will happen if the size of that window changes while being used.

Just think about collapsing panel areas. When in Properties they are part of a larger area that is anchored in place and is scrollable. So as you open and close panels it stays the same size, remains in the same place, and acts in a predictable way. But in a popover, they add some complication. When closed do they leave blank space or make the popover smaller? When opened do they make the popover longer or are scrollbars added? If the popover changes in length what happens when you run out of space? And do you have to move the whole thing around if popping up (as shown earlier)? You might even pop down when popping up would be better once the popover got larger.

Personally, I think the answer we will eventually get to is that popovers should not change size and never add scrollbars. Which means also not having collapsible sections. But as they get big and complicated that means they need a change in how they are thought of and laid out.

I think a main problem is that popovers started as an evolution of dropdowns. Dropdown menus are naturally long and tall vertical things. And so popovers turned into long and tall vertical things. But I think the ideal proportion for popovers is wide and more closely matching the proportions of the editors themselves. Make them wider, rather than longer, and you can fit much more things on them. This is exactly what happened to the "Editor Type" menu.

First, I **love** the idea of editors always having an (optional) header on top and (optional) footer at bottom. So I am very in favor of removing the option of headers on the bottom. However, this should **not be tied in any way to popover issues** as they are not really related. For example, take an editor (with header at the top and also has menus and popovers), put it at the bottom of the main main window and make it smaller. At some point you see that the pulldown menus necessarily pop **up**, rather than down. You'll see that the popovers also pop up. I don't think you are proposing eliminating this feature. ![PopOverUp.png](https://archive.blender.org/developer/F6529331/PopOverUp.png) The central problem is that we are opening up a temporary window that is tied to a location and so odd things will happen if the size of that window changes while being used. Just think about collapsing panel areas. When in Properties they are part of a larger area that is anchored in place and is scrollable. So as you open and close panels it stays the same size, remains in the same place, and acts in a predictable way. But in a popover, they add some complication. When closed do they leave blank space or make the popover smaller? When opened do they make the popover longer or are scrollbars added? If the popover changes in length what happens when you run out of space? And do you have to move the whole thing around if popping up (as shown earlier)? You might even pop down when popping up would be better once the popover got larger. Personally, I think the answer we will eventually get to is that popovers should not change size and never add scrollbars. Which means also not having collapsible sections. But as they get big and complicated that means they need a change in how they are thought of and laid out. I think a main problem is that popovers started as an evolution of dropdowns. Dropdown menus are naturally long and tall vertical things. And so popovers turned into long and tall vertical things. But I think the **ideal proportion** for popovers is wide and more closely matching the proportions of the editors themselves. Make them wider, rather than longer, and you can fit much more things on them. This is exactly what happened to the "Editor Type" menu.

William Reynish commented

2019-02-06 17:39:49 +01:00

@Harley In fact there will probably be more collapsible sections in popovers in the future. The plan is to make each panel inside the popovers collapsible. In the Overlays popover, for example, each section there is actually a separate panel. These flexible-height popovers works best when the popover is spawned top-down from a top header.

Harley Acheson commented

2019-02-06 17:51:16 +01:00

In fact there will probably be more collapsible sections in popovers in the future

Yes, that is why I mentioned it.

The plan is to make each panel inside the popovers collapsible

Yes, that is why I posed the questions of how those collapsible sections will behave when opened and closed. I went into detail about how they are different in popovers.

These flexible-height popovers works best when the popover is spawned top-down from a top header.

Which is why I mentioned there are TWO ways a popover can spawn bottom-up. Not just from a bottom header, which is your first reason for removing bottom headers, but also when the area below is too small.

> In fact there will probably be more collapsible sections in popovers in the future Yes, that is why I mentioned it. > The plan is to make each panel inside the popovers collapsible Yes, that is why I posed the questions of how those collapsible sections will behave when opened and closed. I went into detail about how they are different in popovers. > These flexible-height popovers works best when the popover is spawned top-down from a top header. Which is why I mentioned there are TWO ways a popover can spawn bottom-up. Not just from a bottom header, which is your first reason for removing bottom headers, but also when the area below is too small.

Harley Acheson commented

2019-02-07 18:17:38 +01:00

Just in case my long explanation was unclear...

A pulldown menu or a popover can spawn top-down or bottom-up, but the direction is not just dependent on whether the header is at the top or bottom of its editor. With the header on top, these things can spawn top-down or bottom-up. With header on the bottom they can spawn bottom-up or top-down.

Therefore forcing headers to always be at the top of their editor does not ensure that dropdowns and popovers will spawn top-down.

Just in case my long explanation was unclear... A pulldown menu or a popover can spawn top-down or bottom-up, but the direction is **not** just dependent on whether the header is at the top or bottom of its editor. With the header on top, these things can spawn top-down or *bottom-up*. With header on the bottom they can spawn bottom-up or *top-down*. Therefore forcing headers to always be at the top of their editor does not ensure that dropdowns and popovers will spawn top-down.

ChristopherAnderssarian commented

2019-02-07 22:31:36 +01:00

Added subscriber: @ChristopherAnderssarian

ChristopherAnderssarian commented

2019-02-07 22:31:37 +01:00

I don't understand the rationale behind your points.

Your first point:

When the height varies, the contents gets pushed around.

'Scuse me for pointing out the obvious, but that just hasn't been implemented, hasn't it?
The order should be reversed, like it is on the rest of the menus.


The UI Currently

Your Second point:

Opening old blend files is now a pain, because users have to go ahead and manually move all the headers to the top.

This is untrue as of {afd4bf869498}.

Your Third Point:

It makes it possible, or at least easier, to add footers to some areas, such as in the Text Editor to better give space for the file path

...add footers to some areas

Adding footers would be a good idea, but should work in tandem with headers (Toggle region alignment and Toggle display)

...to better give space

How does removing the option to Flip headers give more more space?

In D4302 #97564, @WilliamReynish wrote:
... headers on the bottom works very poorly in 2.8. They don't work well with popovers which change height. So IMO it's ok to demote bottom headers, and not provide toggle to get them back - this will just create user expectation that headers on the bottom work just as well as headers on the top, which they don't.

@WilliamReynish May I ask why, in your comments, your first thought to 'fix' this was by simply removing it and not seeing what the root cause is? (You also did this in #61136#613155)

I don't understand the rationale behind your points. *Your first point:* > When the height varies, the contents gets pushed around. 'Scuse me for pointing out the obvious, but that just hasn't been implemented, hasn't it? The order should be reversed, like it is on the rest of the menus. | ![Headers Menus.png](https://archive.blender.org/developer/F6542073/Headers_Menus.png)| | -- | | *The UI Currently*| *Your Second point:* > Opening old blend files is now a pain, because users have to go ahead and manually move all the headers to the top. This is untrue as of {afd4bf869498}. *Your Third Point:* > It makes it possible, or at least easier, to add footers to some areas, such as in the Text Editor to better give space for the file path > ...add footers to some areas Adding footers would be a good idea, but should work in tandem with headers (Toggle region alignment and Toggle display) > ...to better give space How does removing the option to Flip headers give more more space? ____ > In [D4302](https://archive.blender.org/developer/D4302)#97564, @WilliamReynish wrote: > ... headers on the bottom works very poorly in 2.8. They don't work well with popovers which change height. So IMO it's ok to demote bottom headers, and not provide toggle to get them back - this will just create user expectation that headers on the bottom work just as well as headers on the top, which they don't. @WilliamReynish May I ask why, in your comments, your first thought to 'fix' this was by simply removing it and not seeing what the root cause is? (You also did this in #61136#613155)

Harley Acheson commented

2019-02-07 22:57:39 +01:00

I don't understand the rationale behind your points...order should be reversed, like it is on the rest of the menus.

He is saying that they are wanting to add collapsible panels to the popovers in an attempt to keep their sizes and complexity in check.

So the popover starts at some small and reasonable size. Then, as you open up sections, the popover gets longer. This works reasonably well when the popover starts at the top and opens down. However, when the popover pops up from the bottom there is no extra space below, so the only idea is to shift the entire thing upwards as each section is opened, which is horrible.

But, as I pointed out, there would remain times when popovers have to spawn bottom-up even if headers remained at the top of editors. And you can't literally swap the order and behavior like we do with menus. For example you don't want to add content upwards when opening panels.

I think the only real solution that includes collapsible panels is for the popovers to remain a fixed size, with scrollbars added as panels are opened. I personally don't like this idea and was offering the thought that panels should be built without collapsible panels at all, and instead be designed to be much wider instead of tall and vertical things.

> I don't understand the rationale behind your points...order should be reversed, like it is on the rest of the menus. He is saying that they are wanting to add collapsible panels to the popovers in an attempt to keep their sizes and complexity in check. So the popover starts at some small and reasonable size. Then, as you open up sections, the popover gets longer. This works reasonably well when the popover starts at the top and opens down. However, when the popover pops up from the bottom there is no extra space below, so the only idea is to shift the entire thing upwards as each section is opened, which is horrible. But, as I pointed out, there would remain times when popovers have to spawn bottom-up even if headers remained at the top of editors. And you can't literally swap the order and behavior like we do with menus. For example you don't want to add content *upwards* when opening panels. I think the only real solution that includes collapsible panels is for the popovers to remain a fixed size, with scrollbars added as panels are opened. I personally don't like this idea and was offering the thought that panels should be built without collapsible panels at all, and instead be designed to be much wider instead of tall and vertical things.

William Reynish commented

2019-02-07 23:35:14 +01:00

Added subscriber: @brecht

William Reynish commented

2019-02-07 23:35:14 +01:00

We already have collapsible sections in popovers - see Shading popover. Using this popover when the header is at the bottom doesn't work as nicely.

@ChristopherAnderssarian: Making popovers flip everything probably won't work well either. Then headers and labels will be below the sections they describe.

The larger, unstated question that lies between the lines of your response is 'why remove features or options?'.

Same reason the horizontal properties was removed. It was not a well supported configuration. Keeping things around that you don't intend for users to use is not good practice, and keeping Blender lean, removing complexity has value for maintainability and adding other, more valuable features down the road.

Removing bottom headers is not, in and of itself, something of huge importance, but a possible way to simplify things a bit.

I'll defer to @brecht, @ideasman42 and @JacquesLucke for now.

We already have collapsible sections in popovers - see Shading popover. Using this popover when the header is at the bottom doesn't work as nicely. @ChristopherAnderssarian: Making popovers flip everything probably won't work well either. Then headers and labels will be below the sections they describe. The larger, unstated question that lies between the lines of your response is 'why remove features or options?'. Same reason the horizontal properties was removed. It was not a well supported configuration. Keeping things around that you don't intend for users to use is not good practice, and keeping Blender lean, removing complexity has value for maintainability and adding other, more valuable features down the road. Removing bottom headers is not, in and of itself, something of huge importance, but a possible way to simplify things a bit. I'll defer to @brecht, @ideasman42 and @JacquesLucke for now.

Jacques Lucke commented

2019-03-14 15:57:11 +01:00

The main reasons I'd like to see headers at the bottom being removed:

There is absolutely no usability benefit.
It is annoying when you open different files and the headers are not where you expect them to be.
Opens up the possibility to have a footer in the future.
Finally the name "Header" would not be confusing anymore.
Simplifies the code by removing some unnecessary (I'd argue even annoying) flexibility.

I know that switching from bottom to top headers requires maybe a few hours to get used to.
However, since most (afaik) Blender 2.8 users have the header at the top already, that should not be a bit deal.
The very real benefits far outweigh the downsides imo.

The main reasons I'd like to see headers at the bottom being removed: - There is absolutely no usability benefit. - It is annoying when you open different files and the headers are not where you expect them to be. - Opens up the possibility to have a footer in the future. - Finally the name "Header" would not be confusing anymore. - Simplifies the code by removing some unnecessary (I'd argue even annoying) flexibility. I know that switching from bottom to top headers requires maybe a few hours to get used to. However, since most (afaik) Blender 2.8 users have the header at the top already, that should not be a bit deal. The very real benefits far outweigh the downsides imo.

Brecht Van Lommel commented

2019-03-14 15:59:55 +01:00

I rather not make any potentially controversial changes here, let's leave it as is and focus on more important things.

William Reynish commented

2019-04-02 14:00:17 +02:00

Let's leave this as-is for now - it was merely meant to simplify things a little, but also isn't really much of an issue.

All the headers are at the top by default anyway. I would not want this to be a blocker for adding footers to the places where we need them.

Let's leave this as-is for now - it was merely meant to simplify things a little, but also isn't really much of an issue. All the headers are at the top by default anyway. I would not want this to be a blocker for adding footers to the places where we need them.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Proposal: Remove bottom headers #61244