QFontDialog::getFont() doesn't use correct font style





  • @kshegunov, could you please open https://forum.qt.io/topic/69348/qfontdialog-getfont-doesn-t-use-correct-font-style-when-font-of-the-font-parameter-use-tostring-and-fromstring again, since it has the more valid test to reproduce the problem. We can mark this topic as duplicate instead, if that's ok with you. It wasn't my intention to cause any harm, the two cases could be related and I wasn't sure if I it's good to post the whole topic text as reply here.



  • On 2nd glance, maybe it's really better to reply here.
    So here comes by better example:

    QFontDialog::getFont() doesn't use the correct font style when the font of the font parameter uses toString() and fromString().
    It always uses the first font style in the list instead of the style (normal) and weight (regular) of the QFont parameter.
    I made an example:

    bool ok;
    
    // select a font where `Regular` is not the first item in the `Font
    // style` selector (e.g. `Noto Sans`) and select `Regular`
    QFont font = QFontDialog::getFont(&ok);
    if (ok) {
        // looks like `QFont( "Noto Sans,11,-1,5,50,0,0,0,0,0" )`
        qDebug() << "'font': " << font;
    
        QFont font2;
        // I originally store the font to the settings and load it again, but
        // that's not even needed to reproduce this problem
        font2.fromString(font.toString());
        // still looks like `QFont( "Noto Sans,11,-1,5,50,0,0,0,0,0" )`
        qDebug() << "'font2': " << font2;
    
        // now `Bold Italic` is selected, because it's the first item
        QFont font3 = QFontDialog::getFont(&ok, font2, this);
    
        if (ok) {
            // would now look like `QFont( "Noto Sans,11,-1,5,75,1,0,0,0,0" )`
            qDebug() << "'font3': " << font3;
        }
    }
    

    I was testing under:

    Platform: linux
    Operating System: KDE neon User Edition 5.7
    Build architecture: x86_64
    Current architecture: x86_64
    Qt Version (build): 5.7.0
    Qt Version (runtime): 5.7.0

    (The problem was initially reported by a user of QOwnNotes at https://github.com/pbek/QOwnNotes/issues/239.)

    Am I doing something wrong?
    Thanks a lot for your help!


  • Qt Champions 2016

    @pbe said:

    On 2nd glance, maybe it's really better to reply here.

    It is, indeed, for several reasons.

    • The whole problem history is at a glance
    • The people who responded will get a notification there's activity on the topic.
    • The additional information may attract more or better answers

    and so on.

    Kind regards.


  • Qt Champions 2016

    @pbe
    Hi,
    There's a bug - QTBUG-52741 that appears to be what you're describing. I also run your example through the debugger after I was able to reproduce (Qt 5.7) and the problem is indeed in the dialog, here.

    The dialog matches the family only, and when it calls setCurrentItem it selects the very first item in the model (which has the default style), which in turn will overwrite the member that holds the style and you get what you described. If you use the font object directly you won't get the bug, i.e.:

    QFont font = QFontDialog::getFont(&ok);
    if (ok)  {
        // ...
        QFont font2 = QFontDialog::getFont(&ok, font, this); //< Works correctly, no bug
        // ...
    }
    

    Kind regards.



  • @kshegunov, I already found that bug and was wondering if that's what's affecting QOwnNotes. Thank you for making that clear!

    Yes, you are right. If you use the font directly it works, but it doesn't work with font2.fromString(font.toString()); that is needed to store and load it to/from the settings. Do you have any ideas to get around this?


  • Qt Champions 2016

    @pbe said:

    Do you have any ideas to get around this?

    Sadly, no. The bug seems inherent to the QFontDialog class when the QFont's internal identifier isn't set (i.e. when the dialog needs to go and query about the font by its attributes). If I get some more time in the coming days, I'll try to run it again and hopefully will have something better.

    Kind regards.



  • @kshegunov, thank you very much! You are my hero!


  • Qt Champions 2016

    @pbe
    I have a bug fix and I'll try to submit it this evening (I've been working in the dev branch, so some git magic is needed).

    Kind regards.



  • @kshegunov, really? That's wonderful! I can't wait to see it!


  • Qt Champions 2016

    @pbe
    https://codereview.qt-project.org/#/c/165958/

    We'll see if it gets approved.



  • Thanks a lot, I will watch that request!


  • Qt Champions 2016

    @pbe
    There's something else, while investigating your bug I stumbled upon this one ... which you may actually encounter, although it's somewhat unrelated to your problem with the dialog.



  • @kshegunov, that really is what I'm encountering... So actually two bugs are triggered here...



  • Really thanks a lot for your help!


  • Qt Champions 2016

    @pbe
    QTBUG-54936's been merged and the patch will be incorporated in Qt 5.8

    Kind regards.



  • @kshegunov, great news! Thanks a lot!


  • Qt Champions 2016

    @pbe
    My pleasure. The dialog bug is low(er) priority and it may take some time for the proposed patch to get reviewed.

    Kind regards.



  • @kshegunov I wonder if it will get fixed at all...


  • Qt Champions 2016

    @pbe
    It's going to, it'ill just take some time. Now things a bit slow because most people are on vacation.



  • @kshegunov, humans... :)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.