scrollbar hidden after switching properties editor tabs #24343

New Issue

Sharp Eyez · 2010-10-20T23:43:59+02:00

Sharp Eyez commented

2010-10-20 23:43:59 +02:00

%%%The bug occurs with the Properties panel in the default interface layout.

Preliminary steps:
First, create an object with a texture. Now in the Properties->Texture tab, expand all the subsections so that there is a scrollbar, and scroll down to the bottom.

There are two slight variants:

do the preliminary steps, and then select another object with no texture: the texture tab now looks almost empty, except for a scroll bar (it would make more sense to show as much content as possible)
do the preliminary steps, activate the Materials tab of the textured object, select an untextured object, and then activate the Texture tab. Now unlike in the first variant, the Texture tab is totally empty (not even a scroll bar). However, it turns out that using the scroll wheel restores the Texture tab!

The second variant is much more serious, but I would consider both to be bugs.%%%

%%%The bug occurs with the Properties panel in the default interface layout. Preliminary steps: First, create an object with a texture. Now in the Properties->Texture tab, expand all the subsections so that there is a scrollbar, and scroll down to the bottom. There are two slight variants: 1. do the preliminary steps, and then select another object with no texture: the texture tab now looks almost empty, except for a scroll bar (it would make more sense to show as much content as possible) 2. do the preliminary steps, activate the Materials tab of the textured object, select an untextured object, and then activate the Texture tab. Now unlike in the first variant, the Texture tab is *totally* empty (not even a scroll bar). However, it turns out that using the scroll wheel restores the Texture tab! The second variant is much more serious, but I would consider both to be bugs.%%%

Sharp Eyez commented

2010-10-20 23:43:59 +02:00

Changed status to: 'Open'

Sharp Eyez commented

2010-10-21 01:05:55 +02:00

%%%Forgot to mention that this is with Blender 2.54 on Windows.%%%

The Amiman commented

2010-10-22 10:10:46 +02:00

%%%hi,

i filed almost same report some time ago. it was rejected. i agree with you it should scroll back up if there is nothing to display. just feels strange and like a bug to me. more often it is annoying than helpful.

cheers%%%

%%%hi, i filed almost same report some time ago. it was rejected. i agree with you it should scroll back up if there is nothing to display. just feels strange and like a bug to me. more often it is annoying than helpful. cheers%%%

Thomas Dinges commented

2010-10-24 20:04:41 +02:00

%%%This is definetely a Interface bug! Cinfirmed.

That should be fixed, both cases.%%%

%%%This is definetely a Interface bug! Cinfirmed. That should be fixed, both cases.%%%

Victor Wren commented

2010-10-27 22:14:33 +02:00

%%%Could not quite confirm both cases in R31878. When I select the second object (which has no material) and click the texture tab, I get the "add texture" button as normal, but if I then click back to the "Material" tab, there will be no "new material" selector or scrollbar. I have to hit "home" to get the selector to show up (or touch the scroll wheel).%%%

Ton Roosendaal commented

2010-11-10 20:06:58 +01:00

%%%Assigning to self for later%%%

Ton Roosendaal commented

2010-11-15 16:49:25 +01:00

%%%OK I've extensively reviewed the code and history of commits here.

First of all: case "2" I cannot redo (see file attachment which I tested). The scrollbar always shows here.

For case 1: there are two conflicting interests, and Brecht has committed imho the best of possible choices now. Before there were a lot of complaints about button views popping back to top view when inspecting object values, or when closing button panels. He added a memory per "tab" to ensure views are always similar when click on objects. That way you can compare settings optimally, and when you return to the object you started working with the buttons are still the same.

Even if you would store property views in objects, things would go bad if you open multiple of same property views.
Storing all views for all objects in a property window is just too much.

We do have a usability issue here, but that's a generic issue with views having too many options, forcing too much scrolling overhead. I rather work on that, which will solve (some of) this annoyance as well.

If you can make an example that hides buttons and shows no scrollbar, let me know.%%%

%%%OK I've extensively reviewed the code and history of commits here. First of all: case "2" I cannot redo (see file attachment which I tested). The scrollbar always shows here. For case 1: there are two conflicting interests, and Brecht has committed imho the best of possible choices now. Before there were a lot of complaints about button views popping back to top view when inspecting object values, or when closing button panels. He added a memory per "tab" to ensure views are always similar when click on objects. That way you can compare settings optimally, and when you return to the object you started working with the buttons are still the same. Even if you would store property views in objects, things would go bad if you open multiple of same property views. Storing all views for all objects in a property window is just too much. We do have a usability issue here, but that's a generic issue with views having too many options, forcing too much scrolling overhead. I rather work on that, which will solve (some of) this annoyance as well. If you can make an example that hides buttons and shows no scrollbar, let me know.%%%

Victor Wren commented

2010-11-15 18:15:59 +01:00

%%%Using R32738
To reproduce the second case:
1)Open default scene (default cube already has a default material)
2)Create a second cube (which has no material by default.
3)right-click first cube to select, click on materials tab.
4)Expand options under materials tab to take up maximum space, and scroll to bottom of materials window.
5)Select second cube (with no material).
6)This will leave the menu at the bottom of the scroll area, sized for the previous menu, even though it does not need a scrollbar to display the current menu.
7)click on texture tab
8)click back on materials tab
9)This will leave the menu area with no scrollbar and no menu, unless you bump the scroll wheel, or click OUTSIDE the menu area, at which point the "add new" menu will show up.

If, after step 6, you drag the scrollbar up to the top, the menu will be revealed, and it will suddenly realize that it has reserved a lot more space for the menu than it needs and will get rid of the scrollbar. This is funky.

Here's another way to lose the scrollbar:
1)start with default scene
2)Create a second mesh cube (with no texture) and move it off-center
3)re-select first (default) cube
4)Click materials tab
5)Open up enough options to require a scrollbar (if it doesn't already) and scroll to bottom of menu.
6)Right click on light object (on my screen this does not need a scrollbar to display material menu) or on camera object. Neither of these objects uses the same type of material menu as the mesh cubes, and the menus take up less room (however it does seem aware that they don't need scroll bars).
7)right-click second mesh cube (with no material).
8)This will return the menu to the mesh materials tab with no scrollbar or menu visible.

Now, for the coup de grace, right click on the first cube again (which has a material). The materials menu has returned all the way to the top (which actually would have been useful behavior on the mesh that had no material). So, not only is it killing the visibility of the "add" menu for objects that don't have materials, it is NOT preserving the position of the expanded menu on objects that DO.

This is a minor issue, because it's fairly easy to get the menu to pop back to visibility, but I can't believe this is how anybody really intended it to behave.%%%

%%%Using R32738 To reproduce the second case: 1)Open default scene (default cube already has a default material) 2)Create a second cube (which has no material by default. 3)right-click first cube to select, click on materials tab. 4)Expand options under materials tab to take up maximum space, and scroll to bottom of materials window. 5)Select second cube (with no material). 6)This will leave the menu at the bottom of the scroll area, sized for the previous menu, even though it does not need a scrollbar to display the current menu. 7)click on texture tab 8)click back on materials tab 9)This will leave the menu area with no scrollbar and no menu, unless you bump the scroll wheel, or click OUTSIDE the menu area, at which point the "add new" menu will show up. If, after step 6, you drag the scrollbar up to the top, the menu will be revealed, and it will suddenly realize that it has reserved a lot more space for the menu than it needs and will get rid of the scrollbar. This is funky. Here's another way to lose the scrollbar: 1)start with default scene 2)Create a second mesh cube (with no texture) and move it off-center 3)re-select first (default) cube 4)Click materials tab 5)Open up enough options to require a scrollbar (if it doesn't already) and scroll to bottom of menu. 6)Right click on light object (on my screen this does not need a scrollbar to display material menu) or on camera object. Neither of these objects uses the same type of material menu as the mesh cubes, and the menus take up less room (however it does seem aware that they don't need scroll bars). 7)right-click second mesh cube (with no material). 8)This will return the menu to the mesh materials tab with no scrollbar or menu visible. Now, for the coup de grace, right click on the first cube again (which has a material). The materials menu has returned all the way to the top (which actually would have been useful behavior on the mesh that had no material). So, not only is it killing the visibility of the "add" menu for objects that don't have materials, it is NOT preserving the position of the expanded menu on objects that DO. This is a minor issue, because it's fairly easy to get the menu to pop back to visibility, but I can't believe this is how anybody really intended it to behave.%%%

Ton Roosendaal commented

2010-11-15 18:54:27 +01:00

%%%I noticed that the slider draw issue has been fixed in svn (rev 33087), I didn't test release (rev 32738).

I'm aware of this annoyance, and agree it's worth to work on to improve it. But, given the over 150 open issues here, and the 100s of todos on our list, there's just priorities too. %%%

%%%I noticed that the slider draw issue has been fixed in svn (rev 33087), I didn't test release (rev 32738). I'm aware of this annoyance, and agree it's worth to work on to improve it. But, given the over 150 open issues here, and the 100s of todos on our list, there's just priorities too. %%%

Sharp Eyez commented

2010-11-23 02:27:38 +01:00

%%%> He added a memory per "tab" to ensure views are always

similar when click on objects. That way you can compare settings
optimally, and when you return to the object you started working
with the buttons are still the same.

That's a very good thing, but it's perfectly possible to fix the bug without breaking this.

For example, if the scrolling position had to be adjusted because the tab didn't have enough content for this amount of scrolling, we don't have to overwrite the adjusted position in the tab's internal properties. That way, when the user selects an untextured object, he sees the "add texture" button instead of an empty tab, and when he returns to the textured object he was working on, he will still be at the same position he used to be at. So in fact this bugfix will ALWAYS be an improvement: it can save the user some scrolling time when switching to an untextured object, and it will NEVER add more scrolling when going back to a textured object.

Now I don't know how this code is architected, but in the worst case you would only have to add another field to your scrolling data structure to differentiate between "user_requested_scrolling_position" and "adjusted_scrolling_position". Most of the code that used to refer to "scrolling_position" would now refer to adjusted_scrolling_position. The only exceptions are that you would need to read from user_requested_scrolling_position when changing the content height, and write to user_requested_scrolling_position when the user modifies the scroll position.%%%

%%%> He added a memory per "tab" to ensure views are always > similar when click on objects. That way you can compare settings > optimally, and when you return to the object you started working > with the buttons are still the same. That's a very good thing, but it's perfectly possible to fix the bug without breaking this. For example, if the scrolling position had to be adjusted because the tab didn't have enough content for this amount of scrolling, we don't have to overwrite the adjusted position in the tab's internal properties. That way, when the user selects an untextured object, he sees the "add texture" button instead of an empty tab, and when he returns to the textured object he was working on, he will still be at the same position he used to be at. So in fact this bugfix will ALWAYS be an improvement: it can save the user some scrolling time when switching to an untextured object, and it will NEVER add more scrolling when going back to a textured object. Now I don't know how this code is architected, but in the worst case you would only have to add another field to your scrolling data structure to differentiate between "user_requested_scrolling_position" and "adjusted_scrolling_position". Most of the code that used to refer to "scrolling_position" would now refer to adjusted_scrolling_position. The only exceptions are that you would need to read from user_requested_scrolling_position when changing the content height, and write to user_requested_scrolling_position when the user modifies the scroll position.%%%

Ton Roosendaal commented

2010-11-23 11:40:44 +01:00

%%%Improvement suggestion sounds good, but that's not what we use our bug tracker for.
We have enough troubles already trying to make work what was intended to work... this is for later. Thanks!%%%

%%%Improvement suggestion sounds good, but that's not what we use our bug tracker for. We have enough troubles already trying to make work what was intended to work... this is for later. Thanks!%%%

Brecht Van Lommel commented

2011-07-06 13:41:47 +02:00

%%%Moved from Blender 2.5 Bug Tracker to Todo%%%

Brecht Van Lommel commented

2011-07-06 13:43:14 +02:00

%%%Moved from Todo to Blender 2.5 Bug Tracker%%%

Brecht Van Lommel commented

2011-07-06 13:44:22 +02:00

%%%This bug was closed a bit too quick, the scrollbar getting hidden is indeed a bug that should be fixed.%%%

Bastien Montagne commented

2011-12-13 13:03:13 +01:00

%%%Added a patch that tries to solve the void window without scrollbars bug only.

That problem was caused by the fact that, in ED_region_panels (editors/screen/area.c), the panels’ uiBlocks are created with a view matrix corresponding to the view before the UI_view2d_totRect_set call, which might change the view2D… The glitch being, we have to have the current dimensions of panels to call that!

So basically, I added uiUpdateBlocksMatrices (and uiBlockUpdateMatrix) to UI_interface.h, to be able to change the uiBlock matrices’ after the final view region has been set.

Note: this seems to work fine, but as usual, my skills in this domain are not high enough to have any certitude here…%%%

%%%Added a patch that tries to solve the void window without scrollbars bug *only*. That problem was caused by the fact that, in ED_region_panels (editors/screen/area.c), the panels’ uiBlocks are created with a view matrix corresponding to the view *before* the UI_view2d_totRect_set call, which *might* change the view2D… The glitch being, we have to have the current dimensions of panels to call that! So basically, I added uiUpdateBlocksMatrices (and uiBlockUpdateMatrix) to UI_interface.h, to be able to change the uiBlock matrices’ *after* the final view region has been set. Note: this *seems* to work fine, but as usual, my skills in this domain are not high enough to have any certitude here…%%%

Ton Roosendaal commented

2012-10-21 13:01:03 +02:00

%%%Bastien: you probably found the right problem, but I'm not sure if the fix should be handled that way. I need to be doing more code work before I dare to touch this part of the code, but it's on my list again :)%%%