3d view's header no longer transparent (with Tool Settings hidden) #92844

Closed
opened 2021-11-05 09:20:36 +01:00 by MACHIN3 · 25 comments

System Information
Operating system: Linux-4.15.0-159-generic-x86_64-with-glibc2.27 64 Bits
Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.91.03

Blender Version
Broken: version: 3.0.0 Beta, branch: master, commit date: 2021-11-02 22:38, hash: 11392829ad
Worked: 2.93 and earlier
Short description of error
The 3D view's header at the top or bottom of the screen is no longer transparent in 3.0, when the Show Tool Settings is disabled, as it used to be in earlier versions. I really liked the additional amount of screen space you could gain by disabling the tool settings.

See screenshot and compare green(before) with orange(now).
additional_screen_space.jpg

Whatever you do, there's now always the thick double bar at the top/bottom of the screen with plenty unused space.
In the 3D view's theme space, the header transparency only affects the tool settings, not the header itself.

Exact steps for others to reproduce the error

  • disable Show Tool Settings in 2.93 and 3.0
**System Information** Operating system: Linux-4.15.0-159-generic-x86_64-with-glibc2.27 64 Bits Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.91.03 **Blender Version** Broken: version: 3.0.0 Beta, branch: master, commit date: 2021-11-02 22:38, hash: `11392829ad` Worked: 2.93 and earlier **Short description of error** The 3D view's header at the top or bottom of the screen is no longer transparent in 3.0, when the `Show Tool Settings` is disabled, as it used to be in earlier versions. I really liked the additional amount of screen space you could gain by disabling the tool settings. See screenshot and compare green(before) with orange(now). ![additional_screen_space.jpg](https://archive.blender.org/developer/F11726930/additional_screen_space.jpg) Whatever you do, there's now always the thick double bar at the top/bottom of the screen with plenty unused space. In the 3D view's theme space, the header transparency only affects the tool settings, not the header itself. **Exact steps for others to reproduce the error** * disable `Show Tool Settings` in 2.93 and 3.0
Author

Added subscriber: @MACHIN3

Added subscriber: @MACHIN3

#92779 was marked as duplicate of this issue

#92779 was marked as duplicate of this issue
Member

Added subscribers: @ideasman42, @PratikPB2123

Added subscribers: @ideasman42, @PratikPB2123
Member

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'
Member

Hi, thanks for the report. Not bisected but I think this has been introduced because of 4cf4bb2664

This would lose the transparency on the header area, but add it on the tool settings, so the end result should be the same with the bottom portion being transparent if desired.

@ideasman42 , is this an expected behavior? At least Harley's comment is saying this behavior is intended (#91536#1222571)

Hi, thanks for the report. Not bisected but I think this has been introduced because of 4cf4bb2664 >This would lose the transparency on the header area, but add it on the tool settings, so the end result should be the same with the bottom portion being transparent if desired. @ideasman42 , is this an expected behavior? At least Harley's comment is saying this behavior is intended (#91536#1222571)
Author

Thanks for finding that commit!

This would lose the transparency on the header area, but add it on the tool settings, so the end result should be the same with the bottom portion being transparent if desired.

As shown in my screenshot, it's not the same when Tool Settings are disabled.

Also, it looks like @ideasman42 inquired about exactly this already:

Allow the header background to be transparent (in the current patch the header background seems hardcoded to be opaque, regardless of the theme)

In the current patch only the tool-header can be made transparent by changing the "Header" alpha in the theme settings (matching current behavior where only one becomes transparent), are you saying you would want both headers to be transparent, controllable separately?

So, let me just say that yes, I would very much want to be able to do that.

Thanks for finding that commit! > This would lose the transparency on the header area, but add it on the tool settings, so the end result should be the same with the bottom portion being transparent if desired. As shown in my screenshot, it's not the same when Tool Settings are disabled. Also, it looks like @ideasman42 inquired about exactly this already: >> Allow the header background to be transparent (in the current patch the header background seems hardcoded to be opaque, regardless of the theme) > > In the current patch only the tool-header can be made transparent by changing the "Header" alpha in the theme settings (matching current behavior where only one becomes transparent), are you saying you would want both headers to be transparent, controllable separately? So, let me just say that yes, I would very much want to be able to do that.
Member

Added subscriber: @Harley

Added subscriber: @Harley
Member

My comment was unrelated. It was part of some question and cautions I had about the design when it was first proposed by Francesco. I wasn’t part of any planning of, or implementation of, this feature so don’t know what is intended.

My comment was unrelated. It was part of some question and cautions I had about the design when it was first proposed by Francesco. I wasn’t part of any planning of, or implementation of, this feature so don’t know what is intended.

Note that this is more of a design decision, swapping the headers also swapped their overlay setting, ignoring the tool header - this means that the regular header (which used to overlap) now doesn't.

We could overlap both, although it feels a bit crowded to have 2x rows of buttons floating at the top of the 3D viewport.

diff --git a/source/blender/editors/screen/area.c b/source/blender/editors/screen/area.c
index 8523496bdbd..663034fde6e 100644
--- a/source/blender/editors/screen/area.c
+++ b/source/blender/editors/screen/area.c
@@ -1289,6 +1289,7 @@ bool ED_region_is_overlap(int spacetype, int regiontype)
                RGN_TYPE_UI,
                RGN_TYPE_TOOL_PROPS,
                RGN_TYPE_FOOTER,
+               RGN_TYPE_HEADER,
                RGN_TYPE_TOOL_HEADER)) {
         return true;
       }
Note that this is more of a design decision, swapping the headers also swapped their overlay setting, ignoring the tool header - this means that the regular header (which used to overlap) now doesn't. We could overlap both, although it feels a bit crowded to have 2x rows of buttons floating at the top of the 3D viewport. ``` diff --git a/source/blender/editors/screen/area.c b/source/blender/editors/screen/area.c index 8523496bdbd..663034fde6e 100644 --- a/source/blender/editors/screen/area.c +++ b/source/blender/editors/screen/area.c @@ -1289,6 +1289,7 @@ bool ED_region_is_overlap(int spacetype, int regiontype) RGN_TYPE_UI, RGN_TYPE_TOOL_PROPS, RGN_TYPE_FOOTER, + RGN_TYPE_HEADER, RGN_TYPE_TOOL_HEADER)) { return true; } ```
Author

We could overlap both, although it feels a bit crowded to have 2x rows of buttons floating at the top of the 3D viewport.

I understand that. But I tend to work without the Tool Settings. So 2 rows of floating buttons are no concern to me.

> We could overlap both, although it feels a bit crowded to have 2x rows of buttons floating at the top of the 3D viewport. I understand that. But I tend to work without the Tool Settings. So 2 rows of floating buttons are no concern to me.

Added subscriber: @SergienkoEugene

Added subscriber: @SergienkoEugene

If possible, I would support the idea of "optionality" of the header.
I also like more free space on the screen.
An overabundance of buttons and interface hinders, it's like a step back. I think so.

If possible, I would support the idea of "optionality" of the header. I also like more free space on the screen. An overabundance of buttons and interface hinders, it's like a step back. I think so.

Added subscriber: @apprenti90

Added subscriber: @apprenti90

Added subscriber: @Positivity

Added subscriber: @Positivity

Is there any ETA, for Fixing this or adding a new option for alpha on the header? Its Blender 3.2 already and this issue have not moved a bit !

Is there any ETA, for Fixing this or adding a new option for alpha on the header? Its Blender 3.2 already and this issue have not moved a bit !
Member

Added subscribers: @MeshVoid, @Alaska, @LloydAlmeida, @EAW, @fsiddi

Added subscribers: @MeshVoid, @Alaska, @LloydAlmeida, @EAW, @fsiddi
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:22:45 +01:00

Is there any update on this Issue. This is a huge regression.

Is there any update on this Issue. This is a huge regression.

As Campbell previously mentioned, there was a design decision to flip the toolbar and header menu content. This decision was independent from the ability to make header background transparent. This seems to be an option in the theming system, but setting alpha there does not work. This could be considered an issue that needs to be addressed. Can @Harley have a look at this?

As Campbell previously mentioned, there was a design decision to flip the toolbar and header menu content. This decision was independent from the ability to make header background transparent. This seems to be an option in the theming system, but setting alpha there does not work. This could be considered an issue that needs to be addressed. Can @Harley have a look at this?
Member

Will do.

Will do.
Member

First let's restate what we are wanting just to give you a chance to correct me.

With Blender with factory startup and preferences, the feature "Region Overlap" (Edit / Preferences / Interface / Display) is ON by default. This feature allows some regions of the 3DViewport to have transparency. Turn that off and you will see a solid background behind the sidebar and toolbar.

On prior versions of Blender, before 3.0, "region overlap" made the 3DViewport header be transparent. But with 3.0 a new header-like region was added called "Tool Settings" and it is that which becomes transparent, not the header.

You are wanting to have both regions, basically everything up there, allow transparency? For the following I will give captures that change the default header color to be fully transparent.

Would it work? Yes, it is possible to make both regions show the same color (or no color) and it works quite well

image

Does it ever look weird? Yes. There would be times when there is more information shown on Tool Settings than the header and it looks a bit strange because it leaves a funny hole. This is the sort of thing that caused this change in behavior with Region Overlap:

image

The biggest downside I can imagine is that there will be many user who are used to having Tool Settings transparent but non-transparent header. So a change that could be jarring to some.

You can't have a new preference just to make this one thing transparent. We currently do it all with a single switch so it would be a steep hill to get approval to break that up into four separate settings.

We could add a separate theme setting for Tool Settings separate from Header. Right now they are both drawn with the same color. I personally wouldn't like to do that as I think our themes are complex enough.

Do you want a build created so you can test drive this?

What do you think @pablovazquez ? I like it.

image

First let's restate what we are wanting just to give you a chance to correct me. With Blender with factory startup and preferences, the feature "Region Overlap" (Edit / Preferences / Interface / Display) is ON by default. This feature allows some regions of the 3DViewport to have transparency. Turn that off and you will see a solid background behind the sidebar and toolbar. On prior versions of Blender, before 3.0, "region overlap" made the 3DViewport **header** be transparent. But with 3.0 a new header-like region was added called "Tool Settings" and it is that which becomes transparent, not the header. You are wanting to have both regions, basically everything up there, allow transparency? For the following I will give captures that change the default header color to be fully transparent. Would it work? Yes, it is possible to make both regions show the same color (or no color) and it works quite well ![image](/attachments/c45a8242-346a-4285-b3b8-f970fa1d0c5c) Does it ever look weird? Yes. There would be times when there is more information shown on Tool Settings than the header and it looks a bit strange because it leaves a funny hole. This is the sort of thing that caused this change in behavior with Region Overlap: ![image](/attachments/a3c9bc4c-84a0-43e7-b4f3-190ec6eeabee) The biggest downside I can imagine is that there will be many user who are used to having Tool Settings transparent but non-transparent header. So a change that _could_ be jarring to some. You can't have a new preference just to make this one thing transparent. We currently do it all with a single switch so it would be a steep hill to get approval to break that up into four separate settings. We could add a separate theme setting for Tool Settings separate from Header. Right now they are both drawn with the same color. I personally wouldn't like to do that as I think our themes are complex enough. Do you want a build created so you can test drive this? What do you think @pablovazquez ? I like it. ![image](/attachments/4228c5b6-251f-4356-87ff-bbc5c046cd4f)
136 KiB
240 KiB
168 KiB

@Harley That looks so much better.

Couple of points.

Currently the Tool Settings are available in 3 Places.
Not everyone uses the Tool settings in the 3D View.
All the Workspaces look OK if they are both Transparent.
The only Workspace it looks a bit strange is Sculpting, which again, not everyone uses Sculpt, the user has the option of making it not transparent and there's no visual difference as the tool settings cover the entire width.

As stated its best to find a solution that does not need major approvals as that could take a long time.
Maybe both regions show the same color ( or no color ), the only point is the Sclupt tool that covers the width of the Viewport anyway . Also most of the Sculpt videos I have seen, people use the Properties Panel.

Or simpler, a different color setting for the Header and Tool Setting. [ I don't know how complex this would be to do ]

@Harley That looks so much better. Couple of points. Currently the Tool Settings are available in 3 Places. Not everyone uses the Tool settings in the 3D View. All the Workspaces look OK if they are both Transparent. The only Workspace it looks a bit strange is Sculpting, which again, not everyone uses Sculpt, the user has the option of making it not transparent and there's no visual difference as the tool settings cover the entire width. As stated its best to find a solution that does not need major approvals as that could take a long time. Maybe both regions show the same color ( or no color ), the only point is the Sclupt tool that covers the width of the Viewport anyway . Also most of the Sculpt videos I have seen, people use the Properties Panel. Or simpler, a different color setting for the Header and Tool Setting. [ I don't know how complex this would be to do ]
Member

What do you think @pablovazquez ?

I think it could work. However, there were two big issues in the past:

  1. The main issue was that the tiny areas between buttons could be clicked and it was a bit of hit and miss. Not a great experience.

  2. Since the header area is used for showing temporary info in modal operators, like transforms, the header flicker issue is even more obvious.

The fist issue has been solved a few versions ago, but the second issue remains. Attached a video to see it in action.
image

I quickly tested it using Campbell's code and it works:

diff --git a/source/blender/editors/screen/area.cc b/source/blender/editors/screen/area.cc
index 1b6cb2a80de..5cd50f98c51 100644
--- a/source/blender/editors/screen/area.cc
+++ b/source/blender/editors/screen/area.cc
@@ -1247,6 +1247,7 @@ bool ED_region_is_overlap(int spacetype, int regiontype)
                RGN_TYPE_UI,
                RGN_TYPE_TOOL_PROPS,
                RGN_TYPE_FOOTER,
+               RGN_TYPE_HEADER,
                RGN_TYPE_TOOL_HEADER)) {
         return true;
       }

I'm fine with enabling Region Overlap for the header, but we should solve these issues first. Perhaps as a separate design task/PR, this is not related to this bug report in particular.

> What do you think @pablovazquez ? I think it could work. However, there were two big issues in the past: 1. The main issue was that the tiny areas between buttons could be clicked and it was a bit of hit and miss. Not a great experience. 2. Since the header area is used for showing temporary info in modal operators, like transforms, the header flicker issue is even more obvious. The fist issue has been solved a few versions ago, but the second issue remains. Attached a video to see it in action. ![image](/attachments/b2b5dea0-c648-419c-9f7f-7d99f413d135) I quickly tested it using Campbell's code and it works: ``` diff --git a/source/blender/editors/screen/area.cc b/source/blender/editors/screen/area.cc index 1b6cb2a80de..5cd50f98c51 100644 --- a/source/blender/editors/screen/area.cc +++ b/source/blender/editors/screen/area.cc @@ -1247,6 +1247,7 @@ bool ED_region_is_overlap(int spacetype, int regiontype) RGN_TYPE_UI, RGN_TYPE_TOOL_PROPS, RGN_TYPE_FOOTER, + RGN_TYPE_HEADER, RGN_TYPE_TOOL_HEADER)) { return true; } ``` I'm fine with enabling Region Overlap for the header, but we should solve these issues first. Perhaps as a separate design task/PR, this is not related to this bug report in particular.

Any update on the Header Regression ?

Any update on the Header Regression ?
Member

This has been fixed by d308f35896 .

image

This has been fixed by d308f35896 . ![image](/attachments/7ebe63a3-b76e-4d20-9e8e-de042b17ab0a)
Blender Bot added
Status
Archived
and removed
Status
Needs Info from Developers
labels 2023-08-18 11:46:15 +02:00
Author

Thank you!

Thank you!
Sign in to join this conversation.
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
11 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#92844
No description provided.