N key doesn't open N-panel in tight space #52979

New Issue

Serge Lyatin · 2017-10-02T23:22:39+02:00

Serge Lyatin commented

2017-10-02 23:22:39 +02:00

System Information
Win7 64bit, screen resolution 1352*697 px

Blender Version
Broken: 2.79

Short description of error
N key doesn't work until manually click on tiny plus sign, after that it works good.

Exact steps for others to reproduce the error

Press N key in green highlighted area -> won't open
Click-drag plus sign of N-panel and press N key -> OK
untitled.blend

**System Information** Win7 64bit, screen resolution 1352*697 px **Blender Version** Broken: 2.79 **Short description of error** N key doesn't work until manually click on tiny plus sign, after that it works good. ![untitled.png](https://archive.blender.org/developer/F932344/untitled.png) **Exact steps for others to reproduce the error** 1. Press N key in green highlighted area -> won't open 2. Click-drag plus sign of N-panel and press N key -> OK [untitled.blend](https://archive.blender.org/developer/F932347/untitled.blend)

Serge Lyatin commented

2017-10-02 23:22:39 +02:00

Changed status to: 'Open'

Serge Lyatin commented

2017-10-02 23:22:39 +02:00

Added subscriber: @SergeL

Vuk Gardašević commented

2017-10-03 00:04:41 +02:00

Added subscriber: @VukGardasevic

Vuk Gardašević commented

2017-10-03 00:04:41 +02:00

If the area is made wider (by dragging the border) than the default width of T and N regions in pixels - they will be displayed.
Also, they will show if the T and N regions were previously resized to fit the width of the area.

There is some difference in how with + sign those act compared to using shortcuts - so the report is about making them uniform?

@JulianEisel should this be considered as a ToDo since the similar behavior is there for a long time?

If the area is made wider (by dragging the border) than the default width of T and N regions in pixels - they will be displayed. Also, they will show if the T and N regions were previously resized to fit the width of the area. There is some difference in how with `+ sign` those act compared to using shortcuts - so the report is about making them uniform? @JulianEisel should this be considered as a ToDo since the similar behavior is there for a long time?

Vuk Gardašević commented

2017-10-03 01:18:55 +02:00

Added subscriber: @JulianEisel

Konstantins Visnevskis commented

2017-10-03 23:34:48 +02:00

Added subscriber: @KonstantinsVisnevskis

Konstantins Visnevskis commented

2017-10-03 23:34:48 +02:00

Could be called a minor headache but this sometimes does lead to confusion and thinking that keyboard button isn't working or something like that (had been banging it a few times :) ). "Instinctively" one often assumes that the panel will get reduced in size to available space or would even get displayed in any way possible rather than not show up at all. Especially problematic when opening a project saved on a big monitor on a smaller computer. Makes one wonder why suddenly all the panes "stopped working".

Konstantins Visnevskis commented

2017-10-03 23:45:59 +02:00

@VukGardasevic "If the area is made wider (by dragging the border) than the default width of T and N regions in pixels - they will be displayed." At least in 2.79 and before this seems not to be the case. If the n-panel in the viewport is scaled up and the viewport is reduced in size after, it won't show up regardless if there is space for the default size.

Vuk Gardašević commented

2017-10-03 23:56:02 +02:00

There is a difference between the first shortcut run and the consequent ones after resize of the Regions.

Basically if the regions were not resized in width to fit it'll try to open up the default one and get collapsed if the area is too small.

There is a difference between the first shortcut run and the consequent ones after resize of the Regions. Basically if the regions were not resized in width to fit it'll try to open up the default one and get collapsed if the area is too small.

Konstantins Visnevskis commented

2017-10-04 00:20:40 +02:00

It is possible that I didn't fully understood what you mean, so I'll describe my thought in detail:

The N/T-panel can be scaled up considerably (in full screen region mode or on a bigger monitor for example).
Then the region gets reduced back to it's normal size or the file gets opened on a smaller monitor and the N/T-panel collapses due to lack of space.
The user presses N/T shortcut but nothing happens as current N/T-panel width is larger than can be displayed in current region or even the monitor.

Wouldn't it be logical that in this situation the panel would be scaled down back to default instead of not showing up?
(I mean only the situations when the user explicitly presses T/N shortcut of course)

It is possible that I didn't fully understood what you mean, so I'll describe my thought in detail: - The N/T-panel can be scaled up considerably (in full screen region mode or on a bigger monitor for example). - Then the region gets reduced back to it's normal size or the file gets opened on a smaller monitor and the N/T-panel collapses due to lack of space. - The user presses N/T shortcut but nothing happens as current N/T-panel width is larger than can be displayed in current region or even the monitor. Wouldn't it be logical that in this situation the panel would be scaled down back to default instead of not showing up? (I mean only the situations when the user explicitly presses T/N shortcut of course)

Anthony Edlin commented

2017-11-06 23:02:10 +01:00

Added subscriber: @AnthonyEdlin

Anthony Edlin commented

2017-11-06 23:02:10 +01:00

This is a long standing issue with design of areas and regions. There are many ways you can get the regions to force hide and therefore get it so that opening the region will fail with shortcuts. Scaling window like you said is just one.

It isn't even consistent in behavior.

For example, you can simply shrink 3d area with both N and T regions open and N region will close once they cross over each other. Now press T to close the tools region. N region will open up because it now has room, and you would think that the T region wouldn't open if you pressed T again because now it doesn't have room, that would be consistent with how you described the issue. But instead, the T region does open up and it force closes the N region again. This is because in the code the T region just happens to come first in the list of regions and therefore get's priority. In the image editor the T region comes after the N region so it works the opposite way.

Another example it isn't consistent is that if a region is hidden and wouldn't fit into the entire area's available space when shown, if you click the plus button on screen instead of the shortcut key it will actually resize the region to fit in the space available. This doesn't work if the region will not fit in the remaining space, only if it doesn't fit in the whole area's available space.

Very confusing to users if you don't understand internal data structures.

This is a long standing issue with design of areas and regions. There are many ways you can get the regions to force hide and therefore get it so that opening the region will fail with shortcuts. Scaling window like you said is just one. It isn't even consistent in behavior. For example, you can simply shrink 3d area with both N and T regions open and N region will close once they cross over each other. Now press T to close the tools region. N region will open up because it now has room, and you would think that the T region wouldn't open if you pressed T again because now it doesn't have room, that would be consistent with how you described the issue. But instead, the T region does open up and it force closes the N region again. This is because in the code the T region just happens to come first in the list of regions and therefore get's priority. In the image editor the T region comes after the N region so it works the opposite way. Another example it isn't consistent is that if a region is hidden and wouldn't fit into the entire area's available space when shown, if you click the plus button on screen instead of the shortcut key it will actually resize the region to fit in the space available. This doesn't work if the region will not fit in the remaining space, only if it doesn't fit in the whole area's available space. Very confusing to users if you don't understand internal data structures.

Brecht Van Lommel commented

2019-04-04 05:29:04 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-04-04 05:29:04 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2019-04-04 05:29:04 +02:00

Brecht Van Lommel self-assigned this 2019-04-04 05:29:04 +02:00

Brecht Van Lommel commented

2019-04-04 05:29:04 +02:00

Should be fixed by 822c67364e.

Should be fixed by 822c67364e.

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

N key doesn't open N-panel in tight space #52979