rjvbb added a comment.

  > On the other hand, calling setBold(true) on a font called 
"HandwriteCursive" _should_ select "HandwriteBoldCursive", even if the 
styleName was intended to enforce a specific face. If Qt cannot fix this issue, 
then we have to clear the styleName() at least for those fonts, where a perfect 
match is possible using the attributes alone (by comparing with the database 
again).
  
  Indeed - and I think there are limits to what any automated system can do 
here. There's a point where you have to accept that fonts may have a design 
issue in how they're named and what additional information is available in the 
font file (fortunately the font name isn't the only metadata). And at that 
point you indeed have to fall back to using databases (maybe FontConfig could 
help here)?
  
  > The patch also addresses the bug only for default fonts, but not 
per-application fonts that write their settings to the appnamerc file.
  
  True. Yet I only got bold syntax highlighting again after I applied this 
patch in addition to removing the stylename extension from kateschemarc. I 
don't yet have an explanation for that ...
  
  > All of those will also have a StyleName, so this here doesn't apply either.
  
  Hah, that depends with what Qt version they were generated, and on whether or 
not the user removed the parameter. I didn't invent that move myself, reading 
comments from others who did that to restore issues is what got me to write 
this patch in the end.
  
  > Nothing gets overridden here. It's just that the user didn't specify it.
  
  Which probably means he didn't want it, in this case... What if that short 
name is one of the fonts from Christoph's example (and thus includes an 
explicit weight specification), are you going to do heuristics on it?
  
  This kind of changing the default is fine for users who never use the 
configuration utilities and thus may not even have a kdeglobals file.
  It can get a bit tricky if s/he has a spec in the file that corresponds to an 
old default, but when in doubt I always assume the user is right in this sort 
of thing.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck
Cc: cfeck, fvogt, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Reply via email to