Widening pop-ups - how to proceed?

I have become quite frustrated by the fixed width menus in the blender UI. In moderately complex scenes using linked scenes, the pop-up struggles to provide the full property name and also the linked scene name). I wondered if there might be a way to address this, and where this might lie in the code base. Does this need to be addressed on a case-by-case basis?



Digging around, I found this line :

uiItemR(row, &strip_ptr, "action", 0, NULL, ICON_ACTION);

in nla_buttons.c. I am still chasing this down. It’s all rather less than obvious at the moment.

I naively thought this would make a difference, but it doesn’t seem to:

uiItemR(row, &strip_ptr, "action", UI_ITEM_R_EXPAND, NULL, ICON_ACTION);

I haven’t been able to pin down the sequence of events that gives rise to the pop-up action menu when clicking the actions button. I am missing something here with how that “action” thing is handled.

With some help on blender.chat, it looks like the width is coming from UI_searchbox_size_x() as:

const int searchbox_width = UI_searchbox_size_x();

within ui_searchbox_create_generic_ex

This generic path seems to be confirmed with a breakpoint that shows a call sequence:


I’m thus uncertain how to change this without impacting all other generic users. Most of what I can find for similar sites making use of UI_searchbox_size_x() show seemingly arbitrary factors to multiply the value, with little visible explanation as to the values chosen, and no obvious consistency in the scaling factor applied.

Is it problematic to add a similar generic factor here, or would a change to widen this menu/pop-up need to involve refactoring away from this generic code path (which I would not know how to undertake)?

Differential at ⚙ D16857 Widen the NLA action drop-down menu


I’ve made some additional forays, but run into some obstacles. I’m hoping a kind soul will provide some guidance : ⚙ D16857 Widen the NLA action drop-down menu

Still hoping for some guidance on this. I don’t see how to move forward, or an alternate approach.

I’m not good at programming but I thought I’d attempt to offer a TINY bit of help. It seems you currently want to know the proper way to get uiSearchItems instances into functions like ui_searchbox_create_generic_ex() . The following MAY be useful to give you some clues about how to proceed. :crossed_fingers:

After a minimal look I saw a function in file interface_region_search.cc called ui_but_search_refresh() . Well, uiSearchItems * items actually gets memory allocated for it WITHIN that function and then partially filled out and then I think the items instance gets filled out after being passed to ui_searchbox_update_fn() .

Also, the function UI_search_item_add() seems to be pretty important to filling out uiSearchItems . I think attribute_search_item_add() might also be worth investigating.

I was wondering what the plan might be here now, but the old developer site is read-only, and the discussion cannot continue there. I don’t fully understand how the new system works and whether it has an equivalent. It also seemed that there might be interest from the core UI team in picking this up somehow.

1 Like

The idea did indeed get picked up and was merged. :slight_smile: See this pull request: #104603 - UI: Widen Search Boxes When Necessary - blender - Blender Projects

I think there was some follow up discussion in the chat about refining the look by actually using the width of the strings when the list of results is small, but I don’t remember the details.

For information on how to contribute code through the new site you can check out this wiki page: Tools/Pull Requests - Blender Developer Wiki


Hey @phil.stopford ! I did steal your idea. I figured out how to widen the thing only when needed, but then couldn’t share it with you because the old phab system was read-only and I couldn’t find you on the new gitea. So I posted it, gave you credit, got it approved, and pushed it.

But there is still room for improvement if you want to play in there. I widened it only by the amount that you had proposed, but the Animation Module might decide (later) that they want it even wider. And both Julian and Pablo would love it if in the simplest case (no linking, and a very short list - under 20 items?) we could measure the strings and make it narrower.

You just need to get on the new system. Its a change but not too bad. You can always DM me if you need a hand.


No worries, and thanks for picking this up (we had some winter-related local destruction that I’ve been wrangling for a while and recovering from).

I guess this UI patch was out of scope for 3.5 (I only saw the new behavior under the 3.6 / main code)? That’s a slight shame, but I guess understandable. I hoped it might qualify as a bug fix in terms of the UI and accessibility.

Your version of that fix was nice and simple and would have been safe enough to consider for inclusion in 3.5. My version was more complex and had too many changes for that. There’s not much worse than introducing a new bug near a release. It creates stress, forces a corrective release, and makes all the cool kids laugh at you. LOL


at least 3.6 is going to be an LTS release so it will be in a version that will be around a while.