How to add a font to QT Designer

[Chris2oph]

Good Day,

I am trying to use a specified font (customer specifically wants Helvetica) in QT Designer, however it is not one of the options that I can choose.

I am using QT4 on a Linux system.

Can anybody help me to understand how I can add this font (or any font for that matter!) to the list that I can use in QT Designer?

Any help would be greatly appreciated :-)

Thanks

Chris2oph

[d_stranz]

If you programmatically use this font (e.g. create a QFont with Helvetica font family) and set it on a widget from C++, does that work? If so, then you should be able to manually edit the .ui file (it's just XML) to change the font family. Look for code like this:

<widget class="QLabel" name="label">
     <property name="font">
      <font>
       <family>Tahoma</family>
       <pointsize>10</pointsize>
      </font>
     </property>
  </widget>

<widget class="QLabel" name="label">
     <property name="font">
      <font>
       <family>Tahoma</family>
       <pointsize>10</pointsize>
      </font>
     </property>
  </widget>

To copy to clipboard, switch view to plain text mode 

And change Tahoma to Helvetica. That's probably easier than figuring out how to add it to Qt Designer.

Alternatively, you can set the default application font to Helvetica. See QApplication::setFont().

As an afterthought, if the font is not a standard Qt Designer font, how can your customer be sure that the Helvetica font will be present on systems where the app is deployed? You may have to make provisions for that in your installer.

[Chris2oph]

Many thanks to d_stranz for an excellent response.

the .ui file did have the widget tags for the QLabels I wanted to change fonts for, however it had no actual font tags. I have since added this in, and have tested it and it appears to be working nicely. It's a bit of a shame that this cannot be done from the QT Designer UI, if truth be told I'm regretting using QT Designer - wish I'd just stuck with using QT straight up in code!

Thanks again :-)

[Lesiok]

First of all editing UI files is pointless because these files are generated anew after each change in QT Designer.
Second if You want to change font in all of QLabels (in example) just use style sheet or create custom class derived of QLabel and promote in QDesigner all QLabels to this class.

[d_stranz]

First of all editing UI files is pointless because these files are generated anew after each change in QT Designer.

Not exactly true. Any properties that exist at the time the file is read in, and which are unchanged during the editing should be written back out that way. So, even if Qt Designer doesn't support the Helvetica font internally, if it can read in the QLabel definition and accept / ignore the hand-edited change, then editing other parts of the ui won't affect the font value. I have edited .ui files to change widgets from one type (like QLabel) to a custom type used by my app and those changes are preserved through editing cycles even though Designer doesn't know anything about those widgets. It's really MOC and the runtime that need to resolve such things so they can be created.

I don't know if Qt Designer will respect the font value or whether it will say "What's this? I'll change that to the default font". My gut feeling is that it won't care and will leave it as-is. Needs to be tested, I guess.

In any event, I was suggesting the hand-editing as a last step before deployment, after all of the UI definitions had been solidified.

[Chris2oph]

Lesiok raised a valid concern, and I thought it best for me to check that any changes made in QT Designer to the modified-by-hand file did not overwrite the font changes I had added.

Thankfully, this was not the case. I simply added in another widget to my UI using QT Designer, recompiled my program and then checked the UI file to see if the fonts had been removed/amended at all. They all remained exactly as I had set them :-)

I agree that it would be better to make these changes using QT Designer, however since it wasn't quite as simple as I believe it should have been I am happy to make these changes directly in the UI file.

Truth be told, I prefer using code to create my UI rather than a tool like QT Designer, although this may just be down to my lack of experience with QT Designer. Would anybody have strong reccomendations over using QT Designer over writing the code by hand?

Many thanks to both Lesiok and d_stranz for contributing to this thread - you have both helped me solve my problem and increase my knowledge and skills with using QT.

[Lesiok]

Truth be told, I prefer using code to create my UI rather than a tool like QT Designer, although this may just be down to my lack of experience with QT Designer. Would anybody have strong reccomendations over using QT Designer over writing the code by hand?

I think that there is no simple answer to this question

[d_stranz]

I think that there is no simple answer to this question

I agree. My typical practice is to do this:

- For custom compound widgets (either QDialog-based, or to be used as forms), I use Qt Designer because it's just simpler to lay everything out, assign names, fonts, text, colors, or whatever to the Qt widgets inside and then preview it using this tool; however...

- I tend to layout signal and slot connections within my custom widgets using C++ code. I find the Qt Designer tool for defining signals and slots and connecting them to be awkward and hard to use. Furthermore, it "hides" these details inside the UI file. I prefer to have the UI action logic where I can see (and remember) it.

- I always use C++ code to connect the external signals from my custom widgets to app-level slot code. I almost never let my app "know" about any of the sub-widgets within the dialog or form (encapsulation, basically). If the app needs to know about a selection made from a combo box inside a form, then I handle that signal inside the form, and emit a dialog-level signal with whatever information I want the app to know. This way, if I decide to replace that combo box with something else, the app won't know the difference.

- All of the app-level layout is done in C++ code, such as the QMainWindow-based main application widget. I prefer to define menus, actions, and all the rest in code rather than use Qt Designer, again because I like to have those details right in my face.

- Core app logic (non-UI, computational stuff) is done in pure C++, using boost and STL instead of Qt versions of vectors, lists, etc. to allow core logic to be used in either Qt or MFC apps. Where a piece of computational code needs to talk to a Qt-based UI part, I write virtual classes that act like "glue". Typically, the base class is pure virtual and defines a callback as a pure virtual method. From this, I derive a QObject-based class that implements the virtual callback method for the computational side to use, and a signal / slot counterpart for the Qt side to use. So for example, a long computation might require the ability to interrupt it before it finishes. The callback might simply ask, "Should I keep going?" with a Boolean return value. The Qt part of it has a slot that can be connected to a QPushButton somewhere that sets the Boolean to false when clicked. Of course, inside the callback method, the callback class needs to call QCoreApplication::processEvents() to ensure the push button click is seen.

So I'm probably not using Qt Designer for all it can do. Part of the issue is that I use Visual Studio as my development tool, so the integration between Designer and VS is not as tight as it is between Designer and Qt Creator. I've been using VS since the earliest versions, so I'm used to it, and all of the library code used in my company is VS solution / project-based - we develop in both Qt and MFC and it's easier to just use one tool chain for everything. I've used Qt Creator for some simple projects, and while I find it useful, there are things I do in VS that I haven't figured out how to do in Qt Creator (stupid, simple things like put two code files side-by-side so I can make changes in both of them without having to flip back and forth between tabs).

And of course, your mileage may vary...