[Development] Provisioning error on Ubuntu 18.04 image

[Konstantin Tokarev]

Trying to provision Ubuntu 18.04 image with older commits of qt5 repo on 5.13.2 
branch (so that image is not just taken from cache) results in the following 
reproducible error:

+ sudo apt-get install docker-ce -y
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 docker-ce : Depends: containerd.io (>= 1.2.2-3) but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages.


It seems like there were no recent docker-related changes in provisioning, so 
I'm afraid that it affects head of 5.13.2 as well (and maybe other branches), 
and will break things if cache of VM images is cleared

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] qtwebglplugin fails to build in Coin on Windows (5.13.2 branch)

[Konstantin Tokarev]

Following error had reproduced several times for me:

qwebglintegration_p.h:43:10: fatal error: 
QtFontDatabaseSupport/private/qwindowsfontdatabase_p.h: No such file or 
directory

Both MinGW and MSVC seem to be affected.
Example build logs:

https://testresults.qt.io/logs/qt/qtwebglplugin/87539f0467ac06174008e7eacaf2ba824b68351e/WindowsWindows_7x86WindowsWindows_7x86Mingw73qtci-windows-7-x86-3-b142bdDisableTests/58cdeff5cfc2360d3d8f7d496a8c2f08d3c92441/build_1571837037/log.txt.gz

https://testresults.qt.io/logs/qt/qtwebglplugin/87539f0467ac06174008e7eacaf2ba824b68351e/WindowsWindows_10x86_64WindowsWindows_10x86_64MSVC2015qtci-windows-10-x86_64-14-61643fDisableTests/e8e1bb3c60e19e1ce500d948d1bcf0d385710421/build_1571867849/log.txt.gz

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QWidget font settings propagation parent to child

[Henry Skoglund]

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

[Elvis Stansvik]

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

[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.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QWidget font settings propagation parent to child

[Elvis Stansvik]

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

[Henry Skoglund]

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

[Development] Coin maintenance notification

[Aapo Keskimölö]

Hi Qt Developers,


The Linux server running Coin instance has received security updates 
this morning and in the meantime, I jumped on the opportunity to enable 
running Coin as service automatically after boot up. This might surprise 
some people that might have thought that was already the case, but no, 
we have been starting up the service manually every time when necessary. :o)


With CI automation regards,

Aapo Keskimölö - Coin Maintainer

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Dominik Holland for approver status

[Alex Blasche]

Congratulations to Dominik. Approver permissions have been set.
--
Alex


From: Development  on behalf of Simon 
Hausmann 
Sent: Wednesday, 2 October 2019 10:18
To: development@qt-project.org
Subject: [Development] Nominating Dominik Holland for approver status

Hi,

I would like to nominate Dominik for approver status. He started contributing 
to Qt back in 2013 and has been working primarily on the Qt automotive and 
embedded related bits. After such a long time of steady contributions and code 
peer-review in the automotive "corner", I do trust him to be project-wide 
approver.


Simon
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Fabian Kosmale as approver

[Alex Blasche]

Congratulations to Fabian. Approver permissions have been set.

--
Alex


From: Development  on behalf of Simon 
Hausmann 
Sent: Wednesday, 2 October 2019 15:21
To: development@qt-project.org
Subject: [Development] Nominating Fabian Kosmale as approver

Hi,

I'd like to nominate Fabian as approver as well. He started about four months 
ago digging deep into pretty much all aspects of the Qml engine - from grammar 
fixes, public C++ API, ES promise implementation, new language features 
(required properties) all the way to a brand new linter. As a consequence I'm 
very impressed. He has also reviewed pretty much every patch by Ulf and some of 
mine since then and thankfully found countless issues ;). I trust him to be a 
good reviewer.



Simon
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Vitaly Fanaskov as Approver

[Alex Blasche]

Congratulations to Vitaly. Approver permissions have been set.

--
Alex


From: Development  on behalf of Shawn 
Rutledge 
Sent: Wednesday, 2 October 2019 13:22
To: Qt development mailing list
Subject: [Development] Nominating Vitaly Fanaskov as Approver

Hi all,

I would like to nominate Vitaly Fanaskov as approver for the Qt Project.
Vitaly joined the Qt Quick and Widgets team about a year ago.  He has been 
fixing bugs in widgets and Qt Quick, making it easier to use and customize 
color palettes in Qt Quick, working on the speech module, working on 
KUserFeedback (which we will use for telemetry in Creator), teaching us how to 
use some modern C++ features that some of us didn’t know about before, etc.
I trust that he will follow Qt guidelines and will use the approver rights 
responsibly.

Here is his list of changes:
https://codereview.qt-project.org/q/owner: 
 
vitaly.fanaskov%2540qt.io

and reviews:
https://codereview.qt-project.org/q/reviewer:vitaly.fanaskov%2540qt.io

Disclaimer: we are working in the same company, same team and same room.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Security patches and Firmware update on the Coin host

[Tony Sarajärvi]

Good morning.

We are running security patches and firmware upgrades on the Coin host, just in 
case you are wondering why Coin isn’t responding.

The work should be finished about now, but nothing goes fast when you work with 
upgrading firmware on Dell hardware or update ESXi, so hold onto your horses 
just a bit longer 

-Tony



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Maintainers, your action needed: 3rd party component updates for Qt 5.14.0

[Jani Heikkinen]

Hi,

It is time to make sure all 3rd party modules are up to date for Qt 5.14.0 
release. So please do the check now, do needed updates & record the results in 
https://bugreports.qt.io/browse/QTBUG-79416 . There should be subtasks for all 
needed but if something is missing just add it.

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development