Page MenuHome

scrollbar hidden after switching properties editor tabs
Closed, ResolvedPublic


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.



Event Timeline

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


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.


This is definetely a Interface bug! Cinfirmed.

That should be fixed, both cases.

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).

Assigning to self for later

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.

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.

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.

> 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.

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!

Moved from Blender 2.5 Bug Tracker to Todo

Moved from Todo to Blender 2.5 Bug Tracker

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

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…

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 :)


Found simple fix by removing 2 lines of code.

Things behave now consistent on all clicking and tab switching.

Ton Roosendaal (ton) closed this task as Resolved.Oct 25 2012, 4:50 PM