You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a widget has both text and icon, positioning everything properly is complicated. The Text object is currently created by Painter when rendering, but this causes problems when we need to get the text object before rendering (for example when determining a widget's "internal height"). If icon didn't have to be taken into account when creating the Text object, a Widget:getText method would be much easier to manage.
The current system is nice because we can do this:
{ type = 'button', icon = 'save.png', text = 'Save' }
The new system could simply draw the text in front of the icon (so icon and text aren't really meant to be used on the same widget). Creating the same button might look like this now:
{ type = 'button',
{ icon = 'save.png' },
{ text = 'Save' }
}
Of course, button type widgets could do what menu items do, and create their own children based on their attributes (so the current syntax would still work). This adds complexity for individual widget types, but removes complexity from Widget and Painter.
Or, we can go the other direction, bite the bullet and move all the positioning stuff from Painter into Widget.
Another possibility would be changing the icon and text attributes to always create new children, and have dedicated types for those widgets. So the button could be written either way:
{ type = 'button', icon = 'save.png', text = 'Save' }
-- or
{ type = 'button', { image = 'save.png' }, 'Save' }
The text was updated successfully, but these errors were encountered:
Do you mean something like Font Awesome? You can do this already by giving your widget a subtree with a generic widget containing a font icon; say if you want buttons that use font icons you can do something like this (untested):
I do like the idea of having icon fonts be more accessible somehow, but I don't want baked-in support for any one icon set, because the codepoints they use are reserved for private use and not related to the icons themselves, so there's no standardization across different icon fonts. If you have any ideas on how to ease the pain of using icon fonts, please open a new ticket or pull request.
If a widget has both
text
andicon
, positioning everything properly is complicated. TheText
object is currently created byPainter
when rendering, but this causes problems when we need to get the text object before rendering (for example when determining a widget's "internal height"). Ificon
didn't have to be taken into account when creating theText
object, aWidget:getText
method would be much easier to manage.The current system is nice because we can do this:
The new system could simply draw the text in front of the icon (so
icon
andtext
aren't really meant to be used on the same widget). Creating the same button might look like this now:Of course, button type widgets could do what menu items do, and create their own children based on their attributes (so the current syntax would still work). This adds complexity for individual widget types, but removes complexity from
Widget
andPainter
.Or, we can go the other direction, bite the bullet and move all the positioning stuff from
Painter
intoWidget
.Another possibility would be changing the
icon
andtext
attributes to always create new children, and have dedicated types for those widgets. So the button could be written either way:The text was updated successfully, but these errors were encountered: