Thanks for the PR!

I'm a bit undecided on this. I don't think we have an official policy concerning the GUIs. Neither how far we want to go, nor if we aim at feature parity throughout the GUI frameworks (#13195).

I'm wondering where we want to draw the line. One the one hand, adding this bit of code is not too difficult. On the other hand, next would immediately be font settings for axes labels. This is cluttering up the dialog. Also, we certainly cannot add GUI elements for every parameter. That would be too much of an effort and maintenance burden.

A solution to part of the issues could be to define a StyledTextWidget and use that instead of the simple QLineEdit for texts. This widget would contain the QLineEdit for the text and a font-settings button to the right that would either open a separate font settings dialog or fold/unfold a font settings panel below the QLineEdit.

But before going down this road, I think the dev team should make some fundamental decisions on the scope of the GUI. - In the end we have to maintain it all.

Pushing to 3.3.

My old-school view is that the GUIs should be kept pretty simple. If there is demand for a high degree of configurability via a GUI, perhaps that should be a separate project.

Thank you for your work on this (and the extreme delay on getting this reviewed!), however I don't think we are going to take this. In addition to the concerns about this being something we want to support as a library, this is implemented as text box that does not do any validation on the font names.

I hope we hear from you again.