ApplicationWindow font not changed by QGuiApplication::setFont

MaxL

Hi all,

I am trying to change the default font for my app on macOS.

From the ApplicationWindow documentation, it says that the "font" property can be changed by setting the QGuiApplication font prior to loading the QML.

Here is what I did ( and obviously it did not work seems I am here ;) ):

QFontDatabase::addApplicationFont( ":/fonts/myfont.otf" )

QFont font( "MyFontFamily" );
QGuiApplication::setFont( font );

QQmlApplicationEngine engine;
engine.load( QUrl( QLatin1String( "qrc:/main.qml" ) ) );

If I print QGuiApplication::font(), it is the one I added using setFont.
However if I print font property of ApplicationWindow once completed it is: QFont(.SF NS Text,13,-1,5,50,0,0,0,0,0)

If anyone as an idea. Otherwise I will set it right in the QML but I'd like not to.

SGaist

Hi,

Did you check that the font was successfully added to the font database ?
Is it really "MyFontFamily" ?

MaxL

Hi,

Yes I checked and it is well added, font family is not really MyFontFamily ( this name was just used for the post ).
What I did to check the actual name was:

int fontId = QFontDatabase::addApplicationFont( ":/fonts/myfont.otf" )

if( fontId != -1 )
{
     qWarning() << "Failed to add font";
}

const QStringList familyNames = QFontDatabase::applicationFontFamilies( fontId );
for( auto familyName :  familyNames )
{
    qDebug() << familyName;
}

I never got the warning, and it did print the family name. The one I used to in setFont.

Moreover, if I use this family name and set it to the ApplicationWindow, it does work.

SGaist

Strange, can you test with a QApplication in place of a QGuiApplication ?

MaxL

Hi,

Unfortunately I did not receive any notification that you answered me so here it:

I tried with QApplication but it did not changed anything so I switched back to QGuiApplication.

I went further and tried this ( keeping the setFont in my main.cpp ):

ApplicationWindow {
    visible: true
    width: 800
    height: 600
    minimumHeight: 600
    minimumWidth: 800
    maximumHeight: 600
    maximumWidth: 800
    title: qsTr("Hello World")

    Column {
        anchors.fill: parent
        Text {
            text: "MyText"
        }
        Button {
            text: "MyButton"
        }
    }
}

The Text component has the right font ( family and default pixelSize ) however the Button has an other font.
If now I add the following code to the ApplicationWindow:

font.family: "MyFontFamily"
font.pixelSize: 20

Then everything has the right font, the Text AND the Button are by default display the way I set it in setFont.

Now if I remove the setFont in main.cpp then the Text component is back to a default font that is not mine.

It's either a bug from Qt that does not propagate the setFont to all components that have some text..or..something I did not understand well on how the setFont works. ( I am working with Qt5.7 )

SGaist

Looks indeed like there's something fishy. Can you test that against Qt 5.8 ?

kmatheussen

Hi,

I can't get QApplication::setFont() to work either. This is only a problem when using macos 10.12 (sierra). It's not a problem in Linux, Windows, or macos 10.8 or 10.10 (haven't tried macos 10.11). I'm using Qt 5.7 too, from macports.

Edit: Sorry, I'm using Qt 5.6.2. Unfortunately macports doesn't provide newer version.

MaxL

Hi,

Will try against Qt5.8.
Indeed I am on macOS 10.12.2

kmatheussen

Here's my workaround:

void updateAllFonts(QWidget *widget, QFont font){
  if(widget!=NULL){
    widget->setFont(font);

    const QList<QObject*> list = widget->children();
    for (int i = 0; i < list.size(); ++i) {
      QWidget *widget = dynamic_cast<QWidget*>(list.at(i));
      updateAllFonts(widget, font);
    }
  }
}

int main(){
  ...

  QApplication::setFont(myFont);

  initializeGUI();

#if FOR_MACOSX
  foreach (QWidget *widget, QApplication::allWidgets()) {
    updateAllFonts(widget, QApplication::font());
    widget->update();
  }
#endif

  application->exec();

  ...
}

By the way, is there any way to check if you are running macOS 10.12?

MaxL

It works if you have a static UI but if you load dynamically some Widgets then they won't have the right font unless you set it each time you create a new one.

You should use #ifdef Q_OS_OSX .
For macOS version you can take a look at NSProcessInfo's operatingSystemVersion

MaxL

Well unfortunately same issue with Qt5.8

MaxL

Better workaround right now is to set the font of the QApplication and set it also to the ApplicationWindow.
This way you have all qml elements using the same font. ( Set the font as a contextProperty so if you change it in cpp you won't have to change it in your ApplicationWindow )

kmatheussen

It works if you have a static UI but if you load dynamically some Widgets then they won't have the right font unless you set it each time you create a new one.

Are you sure? It looks like the font set by using QApplication::setFont() is working after QApplication::exec() has started running.

You should use #ifdef Q_OS_OSX .

Yeah, but "FOR_MACOSX" is just a macro in my program. Not all source files are using Qt.

For macOS version you can take a look at NSProcessInfo's operatingSystemVersion

Unfortunately, I think, that function is only available in 10.10 and later.

Better workaround right now is to set the font of the QApplication and set it also to the ApplicationWindow.

Oh, so in addition to calling QApplication::setFont(), you can call qmainwindow->setFont(), and that's enough? Thanks, I'll try that.

MaxL

Are you sure? It looks like the font set by using QApplication::setFont() is working after QApplication::exec() has started running.

Well yes it still work for components that do respect the setFont such as Text. But components like Button, they will not be with the right font and therefore you will have to set it.

Unfortunately, I think, that function is only available in 10.10 and later.

I forgot about QSysInfo. You should have everything you need in there.

Oh, so in addition to calling QApplication::setFont(), you can call qmainwindow->setFont(), and that's enough? Thanks, I'll try that.

Well in QML if I set the font to the ApplicationWindow then yes all elements that were not well handling the setFont are now using the right one.

I found out what is the issue or at least pin pointed it.
If I use QQuick.Controls 1.x, Button does have the font set by setFont however if I switch to QQuickView.Controls 2.0 then it is not using the right font.

My guess is that I have to define a style that uses the font I want instead of using setFont ?

veryqtperson

I don't remember the case exactly, but just setFont() didn't work for me as well. So I ended up with this crutch (which works fine):

int id = QFontDatabase::addApplicationFont(":/fonts/TitilliumWeb-Regular.ttf");
app.setFont(QFont(QFontDatabase::applicationFontFamilies(id).at(0)));

kmatheussen

Just for the record, I don't use QQuick, so this is a broader problem.

SGaist

Sounds there's indeed something fishy going on.

Can you create a minimal compilable example that shows the behaviour ?

MaxL

@SGaist, will do, do you want me to send it to the bug report page ?
@veryqtperson , it is what I have done, my font is registered.

kmatheussen

@MaxL said in ApplicationWindow font not changed by QGuiApplication::setFont:

@SGaist, will do, do you want me to send it to the bug report page ?
@veryqtperson , it is what I have done, my font is registered.

Yes, I don't think QFontDatabase has anything to do with it. I don't have a Sierra computer in front of me right now, but I think this simple program could be enought to demonstrate the problem:

int main(int argc, char **argv){
    QApplication app(argc,argv);
    QString fontstring("Lato,10,-1,5,87,0,0,0,0,0"); // Change this string if you don't have this font on your computer.
    QApplication::setFont(fontstring); 
    QMessageBox msgBox;
    msgBox.setText("This text is not printed using "+fontstring);
    msgBox.exec();
    return 0;
}

kmatheussen

Sorry, the program I posted in the previous message didn't trigger the bug. I also tried to copy various things from the initialization of the program (the one that did trigger the bug) into 'main' above, but without any luck.