How to add a font to QT Designer

[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...