• 1) does seem a little risky/error prone & worth avoiding.
• 2) am I right in assuming this impacts all layouts for drawing? (not only while searching), in this case I don't know if this would cause issues but changing panel layout logic only for search could introduce errors.
  
  If it's significantly simpler it might be worth writing a patch to test it out.
• 3) While this seems OK.
  • Do you think the extra pass will be give a noticeable performance loss?
  • Dealing with the previous expansion state seems important to resolve, is this something that can be handled separately?

Dealing with the previous expansion state seems important to resolve, is this something that can be handled separately?

I agree, and it will be important to have regardless of supporting multi-tab search.

Convert the panel layout pass to be depth first so the subpanels would build their layout first.

This confuses me, the panel layout is already done depth first, but it's pre-order traversal. You seem to suggest switching to post-order traversal? Are we talking about the same thing, that is ed_panel_draw() calls?

It seems the issue is how ed_panel_draw() mixes the item definition and the layout phase. Couldn't we separate them, like we've already split out the drawing phase? We could do a much more sane definition → apply search → layout pipeline. Either as entirely separate passes or for a single root panel at a time.
I guess that would be 3).
I'm not sure why you need to run the search during the layout pass, but I think that's not such a big deal.

Regarding "previous expansion state", do you mean keeping the expansion state stored that the search overrides? Can't this just be a different flag from PNL_CLOSED, stored in Panel.runtime_flag? Would be nicer to have a UI_panel_is_closed() query anyway.

Thanks for the response.

Dealing with the previous expansion state seems important to resolve, is this something that can be handled separately?

Yes, I agree that it's quite important.

It turns out even number two doesn't quite work, because the "search only" status of a subpanel depends on whether its parent is open, and that can't be known if we do the layout for the parent panel first.
So I think this needs to be done in two separate passes. I think I've found a much better way to accomplish that than running the whole layout pass twice though-- keeping all the blocks and buttons around
during the layout process and then remove the invisible ones at the end in a separate pass. The only complication is sometimes just panel headers need to be visible but not their contents. I'll work through
this and report back.

This confuses me, the panel layout is already done depth first, but it's pre-order traversal. You seem to suggest switching to post-order traversal? Are we talking about the same thing, that is ed_panel_draw() calls?

Oh yes, I messed up the terminology here. That's what I meant to suggest. Oops! This actually won't work like I thought though, (see my previous comment).

I'm not sure why you need to run the search during the layout pass, but I think that's not such a big deal.

Currently the "button groups" are freed after the layout pass as they're stored in uiLayoutRoot, but I guess that could change. I also agree this isn't a big deal though-- the important change that has to happen is separating the search and panel expansion from search passes.

Can't this just be a different flag from PNL_CLOSED, stored in Panel.runtime_flag? Would be nicer to have a UI_panel_is_closed() query anyway.

That's a good suggestion for my patch that restores the panel expansion after search is closed, but I don't think it actually applies here. The essence of the problem is that all buttons must be added for search, but there needs to be a way to remove / disappear a subset of them at the end. Currently this happens during the ed_panel_draw layout pass, but I'm suggesting moving it to a separate pass at the end in UI_panels_end.