Fixing artificial header UI in animation editors

I have been investigating this bug: https://developer.blender.org/T97530

The long & short of the reason why this happens is because the search bar is simply a part of the view region and is artificially being anchored to the top of the view in the draw code. When the text box is focused, it attempts to make sure the text box plus padding is totally visible in the region, hence the jumping behaviour.

To fix this, my initial thought was naturally to separate the channel area and the text box into separate UI areas. So I thought maybe I could make it so that the channel region has its own header that I could put the filter in, but it seems like a “space” can only have one header. Is there any precedent for this kind of “second header” separation in Blender? How might I accomplish this?

I don’t see why making the text box focus should cause jumping behavior, to me that sounds like a problem in that implementation.

Regions are generally things a user can hide/show, not a feature for UI layout within a region.

I think the issue here is that the search box is assumed to move along with the view2d, while it’s floating on top instead. The UI code should be made aware of this somehow.

@brecht so the “ui code should be made aware” doe that mean that it is a bigger fix needed outside of the Animation Module work /fix here? What is the best way to approach this fix?

It needs a change in the UI code, but developers working on modules will generally need to touch various parts of the code that are shared between modules. So I was expecting @cmbasnett to either implement a fix or ask for more help.

An alternative fix could be to not scroll the 2D view if the button is fully visible without padding, and only when it’s not fully visible to scroll it into view with padding. That’s probably reasonable behavior also in other UI regions, and easy to implement.

To make it completely ignore the 2D view for such a float button I imagine it a new UI_BLOCK_ flag would be added to uiBlock to indicate a UI region with absolute position. That’s probably a relatively simple change as well.

1 Like

Thanks for the response @brecht.

I was hoping that there would be a way to create a hierarchy within these UI “areas” and have the text box live in it’s own region, and the channel list would be in a separate region entirely, so there would be no strange interactions like this. Having looked through the UI code, it seems this isn’t really possible.

I think the flag option is probably the best approach since it can be focused on fixing this particular scenario instead of modifying the behaviour across Blender.

1 Like

Just wanted to follow back up with this and see if it is something that can get back on the short term list.

This is fixed in 3.6

2 Likes