Hi @Harleya as you did some recent improvements with the ui I would like to give my feedback. Since you added an area close operator that is awesome I try to make a pie with scripts to handle better the area managing.
I encouter some very boring limitations:
First when we use the split area function it would be great if we can choose a fixed size in px instead of a factor (a factor can be cool in some case). But in other case it can be better to choose a fixed size in px to ensure it always pops at the prefered size.
When we change the ui type it can be better to remember the last state of view (by state I mean side panels opened or not and which tab is focused in the sidebar)
I’m assuming that your script can get the pixel width of the active area, and therefore convert a desired size in pixels into a factor using a division?
With users having differing sizes of monitors and areas, high dpi displays, etc, it is probably best to also consider minimums and maximums. As in you might prefer a size of 400 pixels, but not if it is more than 50% of the area, etc
When you split (or duplicate an area into a new window) then all of this runtime view state data is also duplicated. So split an area that has a sidebar open and the new area will also have it open.
But when you remove an editor (close it, change it to something else, etc) all of its runtime state data is lost with it. Imagine having two editors of the same type open with differing options. If you then open a third of the same type which options would you prefer? There would be weeds there, while it is at least predictable now.
