Page MenuHome

[WIP] UI: Change icon buttons width to be even with layout->align
Needs ReviewPublic

Authored by Alessio Monti di Sopra (a.monti) on Dec 5 2021, 11:12 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

Early and messy try to make "only icon" buttons the correct size (20x20 pixels for the default interface scale) so that icons are correctly aligned inside.
This is needed when the buttons are aligned together, since at the moment this is done by extending the button one pixel to the left. The patch basically tries to compensate this, extending the logic currently in use for expanded enums.

Diff Detail

Repository
rB Blender

Event Timeline

Alessio Monti di Sopra (a.monti) requested review of this revision.Dec 5 2021, 11:12 PM
Alessio Monti di Sopra (a.monti) created this revision.
Alessio Monti di Sopra (a.monti) edited the summary of this revision. (Show Details)
  • cleanup
  • comments

Currently the size is changing in widget_roundbox_set() which already looks wrong.
Changing the size also in another place will be even worse.
It seems logical that we should change buttons coordinates somewhere in one place. The question is where.
Maybe in ui_block_align_calc, there are already similar changes, see ui_block_align_but_to_region.
But I don't know how these button offsets will work with other groups of neighboring buttons,
and alignment on the right edge of the block.


That's kind of what I meant: P2650
but I'm afraid it's going to be a giant logic to handle all cases,
right/left block alignment, start of a new row...

Maybe it's not worth it.

@Yevgeny Makarov (jenkm) It seems logical that we should change buttons coordinates somewhere in one place. The question is where.

One place could be just after ui_block_align_calc() in interface.c. If we could do it there, a simple function that moves all the buttons to the left and then the block half way to the right might work, but I don't know if it's possible to check for the layout flags there.

In general I'm not sure how much less of a hack it would feel, a bit more contained maybe.

Maybe in ui_block_align_calc, there are already similar changes, see ui_block_align_but_to_region.

ui_block_align_but_to_region it's a not a good example I'm afraid, even if it's in interface_align.c, tabs skip the core alignment code there.

Simplifed and moved the logic away from ui_text_icon_width_ex()

Bring back the new UI_BUT_ALIGN_IS_FIRST flag.

This fixes a problem related to sub-layouts: since those can be inserted in the middle of the main row, excluding the first item of the list from the shrinking wouldn't work.
Instead the first item get flagged in ui_layout_litem_row() in order to be expanded by the hack in widget_roundbox_set().

At the same time though this creates some 1px slides or contraptions between different button blocks; unnoticeable without comparing with master, but still...