Page MenuHome

Button Width When Name is Empty

Authored by Harley Acheson (harley) on Thu, Dec 27, 2:35 AM.



This patch makes no real current changes. It merely allows us to do something new without affecting any existing features.

The first part of this is a correction of an error when we determine the width of an interface item. In "ui_text_icon_width" (interface_layout.c 283), there is a test to see if the item has an icon but no name. If that is the case it returns our minimum button width (unit_x). If that test is not passed then we measure the width of the name text and add some padding.

However, this does not handle the case where there is no icon and there is no name. In that case we measure empty string and add padding, etc. When the name is blank we should also be returning unit_x, rather than allow for a blank space that is wider than necessary.

The second part of this fixes the position of the down arrow for menus that have such blank names. If the button/menu has blank name text then the down arrow should be centered, rather than aligned to the right.

As mentioned, this patch does not make a difference for anything that we do currently.

But imagine that we change "" so that some elements on the header have blank text. We might want to do so if there are other nearby icons that make the text redundant. Or we might want to conditionally blank out the text as the width of the editor decreases, freeing space and decreasing the need for horizontal scrolling.

The image below illustrates this. The top part show how it looks now if we were to set the Overlays and Shading popovers to have blank text. The blank part is wider than required and the down arrow is aligned badly. The bottom shows what it looks like if we do the same thing after the patch is applied, showing the nicer button width and down arrow alignment.

But to reiterate, this patch merely makes the interface look nicer if someone were to choose to have an interface item with no icon and no name.

Diff Detail

rB Blender

Event Timeline

I'll commit with some tweaks.

Automatically switching to more compact buttons would be good, but is rather complicated. The Python layout code can't predict this (particularly if there are addons or UI translation). It would need to be a feature of the UI layout code.

So in practice it would just need to be one or the other. I'm fine with always using the down array only for shading and overlays. @William Reynish (billreynish) and @Pablo Vazquez (pablovazquez), what do you think?

This revision is now accepted and ready to land.Thu, Dec 27, 2:25 PM
This revision was automatically updated to reflect the committed changes.

We could replace the 'Overlays' and 'Shading' text with just arrows like this. We are running out of space in the 3D View header especially. It pays the penalty of clarity though.

Other things we could do is combine the two visibility popovers, and also commit @Harley Acheson (harley)'s other patch to make popover buttons a bit more compact.

@Pablo Vazquez (pablovazquez), what do you think?

Not 100% sold on this, it's such as vital piece of information. But so is pivot point or snapping, so I guess we can give it a try and see how confusing it is.

Off-topic, but we could also hide the X-ray button while in LookDev/Rendered mode to gain some space.

Yes that’s why I’m more keen on the other things first, as with those there is not really a penalty in clarity. As for X-Ray, it still does apply for Edit Mode and selections I think, even in Rendered view.

My two cents:

As mentioned, I only wanted to improve how it looked if ever wanted to make the name blank, so this wasn't really meant to advocate for rendering Overlays and Shading like this.

But, I personally do like them rendered this way (sub.popover(panel="VIEW3D_PT_overlay", text=""). I find them, that way, as more descriptive and obvious than most of the other UI on the header. It might not seem like it in theory, but it is quite nice in practice: it feels like easily-accessible option(s) followed by a "more..." button.

However, before even trying it this way we'd have to make it so that popovers show Tooltip hints.

One cool thing that I tried was to show the "Overlays" and "Shading" popovers with text only when the editor was was wide enough, and then remove it under a breakpoint value. That works well, but it seemed a bit weird to hardcode breakpoint values in there which we would have to constantly change if new things are added after them. Although that works okay for these, since they are at the end of the header, it would get complex for something similar near the middle, especially as things change between modes, etc.

Reverted the change in interface_layout.c because it causes T59910: Material Editor UI Issue.

This revision is now accepted and ready to land.Fri, Dec 28, 11:37 AM
Brecht Van Lommel (brecht) requested changes to this revision.Fri, Dec 28, 11:37 AM
This revision now requires changes to proceed.Fri, Dec 28, 11:37 AM


First, although this ticket shows that my initial patch was reverted, it was only half-reverted. The part that horizontally centered the down arrow when the area is narrow was left in, although nicely refactored to be much easier to read. Thanks for that.

What was reverted, and what caused the reported error, was the width calculation changes in interface_layout ui_text_icon_width. My logic was too broad in that it caught items that use non-variable layout which are supposed to return a width of unit_x * 10.

This attached diff is much simpler and does not cause the reported error. It now checks within the area applicable for variable layout, specifically tests for !icon and !name before returning unit_x as width. So basically if we are about to measure the length of the name text to determine the width of the enclosing block, we short-circuit out with this minimum length if the string is blank.

There could be an auto-hide thingy that shows the button text when it has enough space, and shrinks down to a simple arrow when the viewport is resized ?

Yes that is certainly possible. This patch just make that sort of thing look nice if that is ever done. The “auto” would need to be thought through though...

Could it be handled by the new adaptive layout engine (the one from preferences editor) ?

AFAICT the properties editor just checks the current width of the editor and changes at a certain breakpoint. Not too complicated in that case.

But it is more complicated for header items. Making up numbers, you could make it so Shading simplifies when header width is less than 1000, then do the same for Overlays at 900. Works well. But if we add a new element after those then you have to redo those breakpoints. Now imagine having something like this in the middle of the 3D Editor header with the width and number of elements changing as you change modes. I’m sure it can done, but I can’t think of a way off the top of my head that is not hacky and hard to maintain.

Perhaps based on the difference between the header width and the totals of all the items’ current widths, so the current amount of empty space on the header.

Perhaps based on the difference between the header width and the totals of all the items’ current widths, so the current amount of empty space on the header.

It has to be relative to empty space, sure. I was thinking something like this. Monitor empty space and collapse buttons when it's zero. Of course we'd have to keep track of empty space considering buttons at full width. I'd be tempted to give it a go if I were more familiar with the code. I guess that's my incentive to start looking into it.

Yes, if you want to play here are some pointers to get there quicker:, about line 428, has "_layout_generator_detect_from_region"
which shows an example of getting the width of the current editor. It ends with a "width_scale"
that contains the width in a way that is independent of the user zoom scale., about line 37, is where the 3D header stuff is put together. At about
line 269 you should see:
just change that to:
sub.popover(panel="VIEW3D_PT_overlay", text="")
and the Overlays popover will just show the down arrow without text

So together this gets to a way to make it collapse when the editor gets narrow. But, as mentioned,
this is a bit hacky so doing it based on available space would be nicer.
But I have no idea how to get there. LOL

This revision is now accepted and ready to land.Fri, Jan 4, 3:20 PM
This revision was automatically updated to reflect the committed changes.