Re: [Development] QWidget font settings propagation parent to child
On 2019-10-24 08:13, Giuseppe D'Angelo via Development wrote:
Il 23/10/19 16:28, Henry Skoglund ha scritto:
Question: is this hit or miss font propagation on Windows and Mac a
bug or a feature? If it's a feature, could it be documented?
Please do some extra investigation: who's setting those fonts?
* Is it the style, e.g. in QStyle::polish(QWidget*)?
* Is it coming from QApplication::font? Or maybe QStyle::polish(QApp*)?
* Do the widgets have WA_SetFont enabled?
etc.
It certainly sounds surprising at first that some widgets don't
inherit the font, but there could be a good explanation. Lacking such
explanation, then we're talking about a quite serious bug.
First the easy questions:
* Do the widgets have WA_SETFont enabled? No, none of the kids, just the
parent (because I called setFont() on it).
(The WA_SetFont() flag is pretty easy to understand (even for me :-)
i.e. widgets with that flag=true says: leave me alone, don't do the font
propagation on me, got my own font setting figured out.)
* Is it coming from QApplication::font()? No, because I do that
setFont("Courier") on my top window. But if I comment that line out, my
top widget would get that application default font instead (on my
Windows PC it's "MS Shell Dlg 2", 8.25 point size).
Off topic: those 8.25 point sizes as default was an excellent choice 20
years ago when the common display size was 1024x768 or so. Nowadays the
display sizes are bigger, why not change those prewired
QApplication::font point sizes to say 12 or even 14?
This is a pretty complicated subject, for example, for a QTableWidget,
the font propagation works for the vertical and horizontal header rows,
but not for the text inside the cells. And it's platform dependent, i.e.
on Linux everything just *works*.
Anyway, the reason I started this thread was that I couldn't understand
how the font propagation really worked. I would be perfectly happy with
the current state of affairs, if it could be documented somehow. Right
now QWidget's font documentation says that the font propagation should
occur, except when the QWidget's isWindow() is true, but all of the
widgets in my example: isWindow() == false.
I'll look into the QStyle stuff, and I'm pretty sure as you say, that
the behavior I'm observing is a result of many years hard work with the
QWidgets.
Rgrds Henry
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QWidget font settings propagation parent to child
Il 23/10/19 16:28, Henry Skoglund ha scritto: Question: is this hit or miss font propagation on Windows and Mac a bug or a feature? If it's a feature, could it be documented? Please do some extra investigation: who's setting those fonts? * Is it the style, e.g. in QStyle::polish(QWidget*)? * Is it coming from QApplication::font? Or maybe QStyle::polish(QApp*)? * Do the widgets have WA_SetFont enabled? etc. It certainly sounds surprising at first that some widgets don't inherit the font, but there could be a good explanation. Lacking such explanation, then we're talking about a quite serious bug. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QWidget font settings propagation parent to child
On 2019-10-23 20:49, Elvis Stansvik wrote: Den ons 23 okt. 2019 kl 20:18 skrev Ville Voutilainen : On Wed, 23 Oct 2019 at 18:49, Elvis Stansvik wrote: Den ons 23 okt. 2019 16:29Henry Skoglund skrev: Hi, I use Qt Creator's excellent Form Editor, however sometimes I've noticed an inconsistency in the font settings, because I'm lazy I usually only set the font property for the top MainWindow and relying on it to "trickle down" and affect the widgets as well. Except sometimes it doesn't trickle down :-( So I wrote a test app, just a main.cpp: I don't want to be that person who always asks "why are you even doing this", but.. Why are you even doing this? :p Changing the font is normally not recommended. I think the best practice is to let the font remain as the platform plugin decided, so that the user's choice of font is respected. And if the user changes their choice, should it be possible to reflect that dynamically on a running application? I have no trouble coming up with dozens of use cases where you want to change the font of an application, or a part of its widget hierarchy. I believe you get that for free if you leave the font alone. At least my Qt applications change when I change my system font choice under KDE. Elvis In my case, I apply the font setting as a "look and feel" or signature telling the user that it's an app from me. Granted, a big/complicated application you'll be doing all of the widget settings more or less explicitly anyway. This is more of a concern for me for short-lived apps (say 500 lines in mainwindow.cpp) that I want to churn out quickly for a specific reason, but nevertheless convey my signature "look and feel". Note that the point size of the font is lost as well when the propagation parent to child widget fails. For example, I use a 16-point sized font (because many of my users are old doctors) but the default vanilla font that appears (in my example for Windows it's in QListWidget and QTableWidget ) is Tahoma 8.25-point size. So even if I can live with Tahoma the point size of the font needs to be almost doubled. Also. I think this is a philosophical question, because if you look at the "Before w.show():" debug output in my example, all the widgets answers: "Yes sir, we have got your order, we'll be showing the Courier font when the party starts". Except that some of them don't (unless you're on Linux). I mean, I could live with this if the widgets that cannot deliver would tell me so, i.e. if they would answer "Tahoma" instead of "Courier" when I ask them in the "Before w.show():" section. And the fact that I have to pull that grapefruit trick indicates that the widget has received the font change, but not completely :-( Rgrds Henry ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QWidget font settings propagation parent to child
Den ons 23 okt. 2019 kl 20:18 skrev Ville Voutilainen : > > On Wed, 23 Oct 2019 at 18:49, Elvis Stansvik wrote: > > > > Den ons 23 okt. 2019 16:29Henry Skoglund skrev: > >> > >> Hi, > >> > >> I use Qt Creator's excellent Form Editor, however sometimes I've noticed > >> an inconsistency in the font settings, because I'm lazy I usually only set > >> the font property for the top MainWindow and relying on it to "trickle > >> down" and affect the widgets as well. Except sometimes it doesn't trickle > >> down :-( So I wrote a test app, just a main.cpp: > > > > > > I don't want to be that person who always asks "why are you even doing > > this", but.. Why are you even doing this? :p > > > > Changing the font is normally not recommended. I think the best practice is > > to let the font remain as the platform plugin decided, so that the user's > > choice of font is respected. > > And if the user changes their choice, should it be possible to reflect > that dynamically on a running application? I have no trouble coming up > with dozens of use cases where you want to change the font of an > application, or a part of its widget hierarchy. I believe you get that for free if you leave the font alone. At least my Qt applications change when I change my system font choice under KDE. Elvis ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QWidget font settings propagation parent to child
On Wed, 23 Oct 2019 at 18:49, Elvis Stansvik wrote: > > Den ons 23 okt. 2019 16:29Henry Skoglund skrev: >> >> Hi, >> >> I use Qt Creator's excellent Form Editor, however sometimes I've noticed an >> inconsistency in the font settings, because I'm lazy I usually only set the >> font property for the top MainWindow and relying on it to "trickle down" and >> affect the widgets as well. Except sometimes it doesn't trickle down :-( So >> I wrote a test app, just a main.cpp: > > > I don't want to be that person who always asks "why are you even doing this", > but.. Why are you even doing this? :p > > Changing the font is normally not recommended. I think the best practice is > to let the font remain as the platform plugin decided, so that the user's > choice of font is respected. And if the user changes their choice, should it be possible to reflect that dynamically on a running application? I have no trouble coming up with dozens of use cases where you want to change the font of an application, or a part of its widget hierarchy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QWidget font settings propagation parent to child
Den ons 23 okt. 2019 16:29Henry Skoglund skrev:
> Hi,
>
> I use Qt Creator's excellent Form Editor, however sometimes I've noticed
> an inconsistency in the font settings, because I'm lazy I usually only set
> the font property for the top MainWindow and relying on it to "trickle
> down" and affect the widgets as well. Except sometimes it doesn't trickle
> down :-( So I wrote a test app, just a main.cpp:
>
I don't want to be that person who always asks "why are you even doing
this", but.. Why are you even doing this? :p
Changing the font is normally not recommended. I think the best practice is
to let the font remain as the platform plugin decided, so that the user's
choice of font is respected.
I guess there are exceptions, like wanting fixed-width in some place, or
changing the font size, but changing the font family for the entire
application seems very invasive.
You may of course have valid reasons, and of so I'm afraid I can't help.
What you describe sounds like a bug/oversight to me.
Elvis
>
> #include "QtWidgets"
>
> int main(int argc, char** argv)
> {
> QApplication a(argc,argv);
> QMainWindow w;
>
> auto listFonts = []
> {
> for (auto pKid :
> w.findChildren("",Qt::FindDirectChildrenOnly))
> qDebug() << pKid->metaObject()->className() <<
> pKid->font().family();
> };
>
> w.setFont(QFont("Courier"));
> new QTextEdit();
> new QLabel();
> new QPushButton();
> new QCalendarWidget();
> new QListWidget();
> new QTableWidget();
>
> qDebug() << "Before w.show();"; listFonts();
>
> w.show(); // start the party
>
> qDebug() << "\nAfter w.show();"; listFonts();
> }
>
> The above app simulates what Qt Creator's Form Editor does (or, rather
> what the generated code in ui_mainwindow.h does), i.e. it sets the font
> prop for the MainWindow and then adds the children. If you run this program
> on Linux, the debug output is as expected:
>
> Before w.show();
> QTextEdit "Courier"
> QLabel "Courier"
> QPushButton "Courier"
> QCalendarWidget "Courier"
> QListWidget "Courier"
> QTableWidget "Courier"
>
> After w.show();
> QTextEdit "Courier"
> QLabel "Courier"
> QPushButton "Courier"
> QCalendarWidget "Courier"
> QListWidget "Courier"
> QTableWidget "Courier"
>
> Everything is nice and dandy. However, running the same program on Windows
> gives this output (the Before part is the same)
>
> ...
> After w.show();
> QTextEdit "Courier"
> QLabel "Courier"
> QPushButton "Courier"
> QCalendarWidget "Courier"
> QListWidget "Tahoma"
> QTableWidget "Tahoma"
>
> Lost 2 font propagations there. And on the Mac it's even worse (the Before
> part is the same here, but):
>
> ...
> After w.show();
> QTextEdit "Courier"
> QLabel ".AppleSystemUIFont"
> QPushButton ".AppleSystemUIFont"
> QCalendarWidget "Courier"
> QListWidget ".AppleSystemUIFont"
> QTableWidget ".AppleSystemUIFont"
>
> Lost another 2, i.e. only 33% hit rate.
>
> Now. the obvious solution is of course to always set the font properties
> explicitly for all widgets on my MainWindow. But it's so convenient to be
> able to change only the topmost font prop. Also the documentation for
> QWidget says "font propagation" should always occur. And sure, on Linux the
> docs are correct. But what about us running Windows or Macs?
>
> Well, the first thing I tried was to reshuffle the lines in my test app:
> ...
> // w.setFont(QFont("Courier"));
> new QTextEdit();
> new QLabel();
> new QPushButton();
> new QCalendarWidget();
> new QListWidget();
> new QTableWidget();
> w.setFont(QFont("Courier"));
> ...
>
> Setting the font *after* adding the children does the trick, the hit rate
> is now 100% also on Windows and Mac. But, the problem is that this isn't
> the way the Form Editor (ui_mainwindow.h) works, it is hardwired to
> always set the properties for the MainWindow before adding any children.
>
>
> So as a workaround, I've resorted to adding one line of code in the
> MainWindow constructor in my Qt widget-flavored programs:
> ...
> {
> ui->setupUi(this);
>
> auto f = font(); setFont(QFont("Grapefruit")); setFont(f);
> ...
>
> Why the grapefruit? It's needed to "shake the tree", because when setting
> the same font as the code in ui_mainwindow.h does. it's ignored. You need
> to change to another font first, then the setFont(f) call will register
> properly (and propagate 100% to the kids). This can be illustrated if we
> change the test program to:
> ...
> w.setFont(QFont("Courier"));
> new QTextEdit();
> new QLabel();
> new QPushButton();
> new QCalendarWidget();
> new QListWidget();
> new QTableWidget();
> w.setFont(QFont("Courier"));
> ...
>
> That version behaves exactly like the first version above (with the
> misses), i.e. like the 2nd setFont() call does not exist. But adding the
> dummy font call:
> ...
> w.setFont(QFont("Courier"));
> new QTextEdit();
> new QLabel();
> new QPushButton();
>
[Development] QWidget font settings propagation parent to child
Hi,
I use Qt Creator's excellent Form Editor, however sometimes I've noticed
an inconsistency in the font settings, because I'm lazy I usually only
set the font property for the top MainWindow and relying on it to
"trickle down" and affect the widgets as well. Except sometimes it
doesn't trickle down :-( So I wrote a test app, just a main.cpp:
#include "QtWidgets"
int main(int argc, char** argv)
{
QApplication a(argc,argv);
QMainWindow w;
auto listFonts = []
{
for (auto pKid :
w.findChildren("",Qt::FindDirectChildrenOnly))
qDebug() << pKid->metaObject()->className() <<
pKid->font().family();
};
w.setFont(QFont("Courier"));
new QTextEdit();
new QLabel();
new QPushButton();
new QCalendarWidget();
new QListWidget();
new QTableWidget();
qDebug() << "Before w.show();"; listFonts();
w.show(); // start the party
qDebug() << "\nAfter w.show();"; listFonts();
}
The above app simulates what Qt Creator's Form Editor does (or, rather
what the generated code in ui_mainwindow.h does), i.e. it sets the font
prop for the MainWindow and then adds the children. If you run this
program on Linux, the debug output is as expected:
Before w.show();
QTextEdit "Courier"
QLabel "Courier"
QPushButton "Courier"
QCalendarWidget "Courier"
QListWidget "Courier"
QTableWidget "Courier"
After w.show();
QTextEdit "Courier"
QLabel "Courier"
QPushButton "Courier"
QCalendarWidget "Courier"
QListWidget "Courier"
QTableWidget "Courier"
Everything is nice and dandy. However, running the same program on
Windows gives this output (the Before part is the same)
...
After w.show();
QTextEdit "Courier"
QLabel "Courier"
QPushButton "Courier"
QCalendarWidget "Courier"
QListWidget "Tahoma"
QTableWidget "Tahoma"
Lost 2 font propagations there. And on the Mac it's even worse (the
Before part is the same here, but):
...
After w.show();
QTextEdit "Courier"
QLabel ".AppleSystemUIFont"
QPushButton ".AppleSystemUIFont"
QCalendarWidget "Courier"
QListWidget ".AppleSystemUIFont"
QTableWidget ".AppleSystemUIFont"
Lost another 2, i.e. only 33% hit rate.
Now. the obvious solution is of course to always set the font properties
explicitly for all widgets on my MainWindow. But it's so convenient to
be able to change only the topmost font prop. Also the documentation for
QWidget says "font propagation" should always occur. And sure, on Linux
the docs are correct. But what about us running Windows or Macs?
Well, the first thing I tried was to reshuffle the lines in my test app:
...
// w.setFont(QFont("Courier"));
new QTextEdit();
new QLabel();
new QPushButton();
new QCalendarWidget();
new QListWidget();
new QTableWidget();
w.setFont(QFont("Courier"));
...
Setting the font *after* adding the children does the trick, the hit
rate is now 100% also on Windows and Mac. But, the problem is that this
isn't the way the Form Editor (ui_mainwindow.h) works, it is hardwired
to always set the properties for the MainWindow before adding any children.
So as a workaround, I've resorted to adding one line of code in the
MainWindow constructor in my Qt widget-flavored programs:
...
{
ui->setupUi(this);
auto f = font(); setFont(QFont("Grapefruit")); setFont(f);
...
Why the grapefruit? It's needed to "shake the tree", because when
setting the same font as the code in ui_mainwindow.h does. it's ignored.
You need to change to another font first, then the setFont(f) call will
register properly (and propagate 100% to the kids). This can be
illustrated if we change the test program to:
...
w.setFont(QFont("Courier"));
new QTextEdit();
new QLabel();
new QPushButton();
new QCalendarWidget();
new QListWidget();
new QTableWidget();
w.setFont(QFont("Courier"));
...
That version behaves exactly like the first version above (with the
misses), i.e. like the 2nd setFont() call does not exist. But adding the
dummy font call:
...
w.setFont(QFont("Courier"));
new QTextEdit();
new QLabel();
new QPushButton();
new QCalendarWidget();
new QListWidget();
new QTableWidget();
w.setFont(QFont("Grapefruit"));
w.setFont(QFont("Courier"));
...
works, 100$ font prop propagation on all systems :-)
Question: is this hit or miss font propagation on Windows and Mac a bug
or a feature? If it's a feature, could it be documented?
Rgrds Henry
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
