Workspace tools disappear when switching an area to Node Editor (Compositing/Shader/Texture) #62000

New Issue

Sam Van Hulle · 2019-02-27T03:09:10+01:00

Sam Van Hulle commented

2019-02-27 03:09:10 +01:00

System Information
Operating system: Windows, Linux
Graphics card: GTX 960, GTX 1080

Blender Version
Broken: 0f135f80f271

Short description of error
Workspace tool panels with their context set to '.objectmode' disappear from the top bar and the Properties Editor after switching an arbitrary area to any of the node-based editors, regardless of there being a 3D Viewport left in Object Mode.

Exact steps for others to reproduce the error

Switch an arbitrary area in the UI to either the Compositing, Shader or Texture Node editor.
Blender and the Curse of the Disappeared Workspace Tools.
Simply returning to the 3D View brings the tools back. If another area is still set to 3D View, switching from and to Object Mode there brings them back as well. Simply 'reminding' Blender of something being in Object Mode seems to be the sole remedy for now.

**System Information** Operating system: Windows, Linux Graphics card: GTX 960, GTX 1080 **Blender Version** Broken: `0f135f80f271` **Short description of error** Workspace tool panels with their context set to `'.objectmode'` disappear from the top bar and the Properties Editor after switching an arbitrary area to any of the node-based editors, regardless of there being a 3D Viewport left in Object Mode. **Exact steps for others to reproduce the error** - Switch an arbitrary area in the UI to either the Compositing, Shader or Texture Node editor. - *Blender and the Curse of the Disappeared Workspace Tools*. - Simply returning to the 3D View brings the tools back. If another area is still set to 3D View, switching from and to Object Mode there brings them back as well. Simply 'reminding' Blender of something being in Object Mode seems to be the sole remedy for now.

Sam Van Hulle commented

2019-02-27 03:09:10 +01:00

Added subscriber: @frameshift

Campbell Barton commented

2019-02-27 06:23:34 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2019-02-27 06:23:34 +01:00

As far as I can see this isn't a bug. The default select tool in the compositor has no options, if you switch to border select there is a single option.

Could you confirm this?

As far as I can see this isn't a bug. The default select tool in the compositor has no options, if you switch to border select there is a single option. Could you confirm this?

Sam Van Hulle commented

2019-02-27 19:21:34 +01:00

Added subscriber: @JulienKaspar

Sam Van Hulle commented

2019-02-27 19:21:34 +01:00

Just discussed this with @JulienKaspar. Seems like it's not a bug per se, only confusing behaviour emphasized by another bug.
The fact that add-ons with panels set to '.objectmode' disappear when changing modes is of course correct behaviour - the add-ons themselves are at fault for declaring they are related to Object Mode, while that's not necessarily true.
The confusing behaviour is caused by the fact that the top bar looks application-wide, but should have contents directly linked to the UI area and the tool that are currently active.
The actual bug is that the top bar doesn't update when it should, namely when focus shifts from one area to the other. Accordig to @JulienKaspar, this has been discussed before, so I assume there's already a task for that?

Just discussed this with @JulienKaspar. Seems like it's not a bug per se, only confusing behaviour emphasized by another bug. The fact that add-ons with panels set to `'.objectmode'` disappear when changing modes is of course correct behaviour - the add-ons themselves are at fault for declaring they are related to Object Mode, while that's not necessarily true. The confusing behaviour is caused by the fact that the top bar *looks* application-wide, but should have contents directly linked to the UI area and the tool that are currently active. The actual bug is that the top bar doesn't update when it should, namely when focus shifts from one area to the other. Accordig to @JulienKaspar, this has been discussed before, so I assume there's already a task for that?

Brecht Van Lommel commented

2019-02-28 13:58:31 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-02-28 13:58:31 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2019-02-28 13:58:31 +01:00

Brecht Van Lommel self-assigned this 2019-02-28 13:58:31 +01:00

Brecht Van Lommel commented

2019-02-28 13:58:31 +01:00

I think the current behavior is by design, even if it's debatable.

Automatically changing when moving the cursor is problematic if you have two editors stacked vertically, and you need to cross the top editor to get to the topbar. So the topbar only updates when changing tools.

I think the current behavior is by design, even if it's debatable. Automatically changing when moving the cursor is problematic if you have two editors stacked vertically, and you need to cross the top editor to get to the topbar. So the topbar only updates when changing tools.

Sam Van Hulle commented

2019-02-28 16:16:36 +01:00

I didn't specifically mean moving the cursor. That as a concept doesn't sit with me very well in all cases. Keystrokes are fine being tied to specific functionality in specific editors, and therefore require Blender to keep the focus in the intended area. But I don't like that to be tied to where the mouse is. While typing in the text editor or Python console, for example, this can have me pressing 237689 keystrokes in the viewport before I realise it.

I like the idea of changing focus on click rather than on mouse move. Would solve the top bar update problem immediately, and some annoyance and confusion throughout Blender.

I didn't specifically mean moving the cursor. That as a concept doesn't sit with me very well in all cases. Keystrokes are fine being tied to specific functionality in specific editors, and therefore require Blender to keep the focus in the intended area. But I don't like that to be tied to where the mouse *is*. While typing in the text editor or Python console, for example, this can have me pressing 237689 keystrokes in the viewport before I realise it. I like the idea of changing focus on click rather than on mouse move. Would solve the top bar update problem immediately, and some annoyance and confusion throughout Blender.

Sign in to join this conversation.