Open airstruck opened 8 years ago
I have a suggestion only relevant due to this having icon in the name but can you add support for font icons if you haven't
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):
local ui = Layout {
{ type = 'button', { style = 'fontIconEdit' }, { text = 'Edit' } },
{ type = 'button', { style = 'fontIconSave' }, { text = 'Save' } },
}
ui:setStyle {
fontIcon = {
font = 'fontawesome-webfont.ttf',
size = 32,
width = 36,
},
fontIconEdit = {
style = 'fontIcon',
text = string.char(0xF0, 0x44),
},
fontIconSave = {
style = 'fontIcon',
text = string.char(0xF0, 0xC7),
},
}
ui:show()
Of course that's not as nice as being able to write:
local ui = Layout {
{ type = 'button', icon = 'edit.png', text = 'Edit' },
{ type = 'button', icon = 'save.png', text = 'Save' },
}
ui:show()
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: