The font settings dialog presents a list of fonts and a list of attributes for the selected font. Selecting a font with a given attribute will however be remembered as a reference to the font file. This is fine except in a UI where you're configuring attributes of elements, and not purely elements. For example, "new/unread", "important" and "action item" are not independent UI elements, they're message attributes. Reproducible: Always Steps to Reproduce: Select a font for the message list, and then apply to following font attributes: 1. unread messages in Bold 2. important messages in Italic 3. action item messages in Italic Actual Results: Important, unread messages are displayed in Italic Unread action items are displayed in Bold Expected Results: Both important and action items that are unread should be displayed in Bold Italic I know that the underlying code will at some point have to work with a reference to a font file that represents the font with the selected attributes. I also realise that semantically speaking the font selection dialog presents settings for elements that are either new or important or action items. It would just be nice if the particular font file could be selected not at the moment the user picks the font+attributes for a given UI element. Or, when underneath the font selection dialog the implementation takes the various combinations of element attributes into account. (I.e. internally cache font references for the 8 various possible combinations of {r,unread}{i,important}{a,action item}) NB: remembering choises as font+attribute(s)+size may actually address a related, global issue on OS X where e.g. the SemiBold attribute tends to get "promoted" to Bold (or even Negrita or Black). A font like Segoe UI is a prime example of this: picking a SemiBold version of this font for UI elements usually becomes the Negrita (Black) version. I'm not sure if this is an actual bug nor where/how to report it so mention it here.
Still valid for 5.4.1
FWIW, the possibly-related problem with SemiBold is due to a font weight handling issue in Qt5 itself.