Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Christian Gagneraud 
On 31 July 2018 at 21:43, Allan Sandfeld Jensen  wrote:
> On Sonntag, 29. Juli 2018 22:58:41 CEST Christian Gagneraud wrote:
>> Hi,
>>
>> We used to build Qt-5.6.3 on and for Linux-i386.
>> I recently had to downgrade to Qt-5.6.0 (see below), but now the build
>> fails with:
>>
>> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:
>> In function 'ssl3_ChaCha20Poly1305':
>> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2118:15:
>> error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no member
>> named 'pIv'
>>  aeadParams.pIv = (unsigned char *) additionalData;
>>^
>> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2119:15:
>> error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no member
>> named 'ulIvLen'
>>  aeadParams.ulIvLen = 8;
>>^
>>
>> Are there any special requirements,or actually is there a difference
>> in the requirements, to build Qt5.6.0 vs Qt-5.6.3?
>>
> Yes. It is most likely NSS, it could in 5.6.0 be used for both encryption and
> certicate checking but in 5.6.3 is only used for certificate checking. You can
> try using NSS 3.21, but note it will report most Google certificates as
> broken. You can also try removing libnss-dev in which case OpenSSL will be
> used for both, but that also means most Google certicates are reported as
> broken (because they objectively are signed by a too weak root).
>
> See https://codereview.qt-project.org/#/c/153890/ perhaps you can cherry pick
> it, though it might not be easy QtWebEngine also upgraded from Chromium 45 to
> 49 in the 5.6 series.

I have uninstalled libnss-dev, and now it builds. The breaking change
seemed to have been introduced with 5.6.1, 5.6.0 is the only patch
version that requires libnss headers to not be present for chromium to
build.

Thanks a lot!

Chris
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Christian Gagneraud 
On 31 July 2018 at 18:59, André Pönitz  wrote:
>> And building Qt for Linux 32 is a real pain.
>
> Can you remind me of an actual problem with that?
>
> The machine I am using to write this mail here has a Qt base at
> cc03bad229 (last September) and Qt Creator at 99e3635ef3c (last week).
>
> Linux 32 bit.

Well, me too i build lot of stuff manually on my personal PC, with lot
of dependencies. Doing a one shot build of a tool on a developer PC is
different from doing a repeatable build from scratch.
I'm building a bunch of stuff (inc. Qt) in docker containers, and I
can tell you that the Dockerfile looks a bit scary. Lot of juggling
around to get the right set of '-dev' packages and the right version
of them.

Anyway, I was not trying to blame Qt for that, it's just that the
build process is not straight forward when you start from a bare
Ubuntu docker image (Or RedHat, SuSe, ...).
And i'm not talking about 32 bits build on 64 bits hosts, i quickly gave up.

For the last example, look at Allan's answer, it seems that i need to
uninstall libnss3-dev package, so that Qt and/or it's de3pendencies
will instead use an internal copy...
Maybe i can use a configure flag to force ignoring the presence of
libnss headers, ... experiment on going right now...

Chris
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Christian Gagneraud 
On 1 August 2018 at 00:51, Kai Koehne  wrote:
>> -Original Message-
>> From: Christian Gagneraud 
>> [...]
>> > And building Qt for Linux 32 is a real pain.
>> > Why don't you provide QQuickCompiler for Linux32 to your paid customers?
>>
>> Just to be clear: I cannot build QQuickCompiler for Linux32-qt5.6 myself, b/c
>> AFAIK, source code is not available to us, although we're a paid customer.
>
> No idea. Have you contacted Qt Support about this?

One of my colleague did, and that the answer we got.

>> Going a bit further, correct me if i'm wrong, but QuickCompiler is no secret
>> anymore, hasn't it be source-released with Qt 5.9 or 5.12?
>
> The original Qt Quick Compiler hasn't been open sourced. There were other 
> optimizations though that might arguably made it less beneficial. See e.g. 
> http://blog.qt.io/blog/2017/03/08/qt-qml-performance-improvements-qt-5-8-0/ .

I don't know what's the difference b/w the 'original' and the
'current' one, all that i remember is reading some blog post stating
that it is now 'integrated' with QtQuick something. Hence me thinking
that the 'quick compiler' feature is now open source, i might be
completely wrong.

Chris
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread André Pönitz 
On Wed, Aug 01, 2018 at 12:09:03AM +1200, Christian Gagneraud wrote:
> On 31 July 2018 at 23:55, Kai Koehne  wrote:
> >> -Original Message-
> >> From: Interest  On Behalf
> >> Of Christian Gagneraud
> >> [...]
> >> >> We used to build Qt-5.6.3 on and for Linux-i386.
> >> >> I recently had to downgrade to Qt-5.6.0 [...]
> >
> >> I don't want to be mean or rude, but honestly i have notice a degradation 
> >> of
> >> patch release management in the recent years...
> >> To the point that now the "Qt Maintenance Tool" offers you to install 
> >> different
> >> patch release, like nobody trust they are actually equivalent and ABI 
> >> backward
> >> compatible as they used to be...
> >
> > Criticizing the MaintenanceTool to (again) provide non-latest patch level 
> > releases in a thread you started with "I recently had to downgrade to Qt 
> > 5.6.0' is ... interesting 
> 
> It is indeed! ;)
> The core problem, is that you have dropped Linux32 for both open
> source and commercial users.
> 
> Unfortunately the code base i'm dealing with cannot run on 64 bits
> machine (both runtime and build time).
> We need to run Qt 5.6 on:
> - Windows/intel 32 bits
> - Linux/intel 32 bits
> - Linux/arm 32 bits
> 
> We need to build Qt and Qt apps on:
> - Windows/intel 32 bits
> - Linux/intel 32 bits
> 
> And building Qt for Linux 32 is a real pain.

Can you remind me of an actual problem with that? 

The machine I am using to write this mail here has a Qt base at
cc03bad229 (last September) and Qt Creator at 99e3635ef3c (last week).

Linux 32 bit.

Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qt 5.11 upgrade results in could not queue DRM page flip error on IMX6 etna

2018-07-31 Thread Dexter Travis 
That worked.

Thank you, for the quick reply.


Dexter

On Tue, Jul 31, 2018 at 10:30 AM Johannes Pointner 
wrote:

> Hello Dexter,
>
> try to set the QT_QPA_EGLFS_ALWAYS_SET_MODE variable.
>
>
>
> On Tue, Jul 31, 2018 at 3:14 PM, Dexter Travis
>  wrote:
> > (apologies for previous message without subject line.)
> >
> > I am attempting to update a working yocto build system with imx6 dual
> plus
> > CPU running the following
> > kernel 4.14 with etnaviv
> > libmesa 17.3.0
> > libdrm 2.4.85
> > qt 5.9.2.  (qt 5.10.x also works)
> >
> > I would like to update to sumo yocto with
> > kernel 4.16 with etnaviv
> > libmesa 17.3.8
> > libdrm 2.4.91
> > qt 5.11
> >
> > This is an embedded device without X11 installed.
> >
> > When I run Qt5_CinematicExperience -platform eglfs I get an error "Could
> not
> > queue DRM page flip on screen LVDS1 (Invalid argument)"  I get the same
> > error with my custom application.
> >
> > If I run with -platform linuxfb the application runs correctly.
> >
> > I have swapped out libdrm, the kernel and libmesa version and find that
> the
> > problem seems to follow my upgrade to qt 5.11.  Said another way,
> swapping
> > the components listed above leads me to believe the problem is with the
> qt
> > upgrade.  Running qt 5.11 with the other originally working components
> does
> > not work.
> >
> > Looking at the configure log for qtbase (5.11) it looks like all the same
> > opengl options are configured as were configured in 5.9 and 5.10. See
> below.
> >
> > qt 5.11 configure log details. This qt does not work.
> > QPA backends:
> > 1185   DirectFB ... no
> > 1186   EGLFS .. yes
> > 1187   EGLFS details:
> > 1188 EGLFS OpenWFD  no
> > 1189 EGLFS i.Mx6 .. no
> > 1190 EGLFS i.Mx6 Wayland .. no
> > 1191 EGLFS RCAR ... no
> > 1192 EGLFS EGLDevice .. yes
> > 1193 EGLFS GBM  yes
> > 1194 EGLFS VSP2 ... no
> > 1195 EGLFS Mali ... no
> > 1196 EGLFS Raspberry Pi ... no
> > 1197 EGL on X11 ... no
> > 1198   LinuxFB  yes
> > 1199   VNC  yes
> > 1200   Mir client . no
> >
> > qt 5.10.1 working configure section
> >  QPA backends:
> > 1173   DirectFB ... no
> > 1174   EGLFS .. yes
> > 1175   EGLFS details:
> > 1176 EGLFS OpenWFD  no
> > 1177 EGLFS i.Mx6 .. no
> > 1178 EGLFS i.Mx6 Wayland .. no
> > 1179 EGLFS RCAR ... no
> > 1180 EGLFS EGLDevice .. yes
> > 1181 EGLFS GBM  yes
> > 1182 EGLFS Mali ... no
> > 1183 EGLFS Raspberry Pi ... no
> > 1184 EGL on X11 ... no
> > 1185   LinuxFB  yes
> > 1186   VNC  yes
> > 1187   Mir client . no
> >
> >
> > I would appreciate any help with this issue.
> >
> >
> >
> > Thank you,
> >
> >
> > Dexter
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qt 5.11 upgrade results in could not queue DRM page flip error on IMX6 etna

2018-07-31 Thread Johannes Pointner 
Hello Dexter,

try to set the QT_QPA_EGLFS_ALWAYS_SET_MODE variable.



On Tue, Jul 31, 2018 at 3:14 PM, Dexter Travis
 wrote:
> (apologies for previous message without subject line.)
>
> I am attempting to update a working yocto build system with imx6 dual plus
> CPU running the following
> kernel 4.14 with etnaviv
> libmesa 17.3.0
> libdrm 2.4.85
> qt 5.9.2.  (qt 5.10.x also works)
>
> I would like to update to sumo yocto with
> kernel 4.16 with etnaviv
> libmesa 17.3.8
> libdrm 2.4.91
> qt 5.11
>
> This is an embedded device without X11 installed.
>
> When I run Qt5_CinematicExperience -platform eglfs I get an error "Could not
> queue DRM page flip on screen LVDS1 (Invalid argument)"  I get the same
> error with my custom application.
>
> If I run with -platform linuxfb the application runs correctly.
>
> I have swapped out libdrm, the kernel and libmesa version and find that the
> problem seems to follow my upgrade to qt 5.11.  Said another way, swapping
> the components listed above leads me to believe the problem is with the qt
> upgrade.  Running qt 5.11 with the other originally working components does
> not work.
>
> Looking at the configure log for qtbase (5.11) it looks like all the same
> opengl options are configured as were configured in 5.9 and 5.10. See below.
>
> qt 5.11 configure log details. This qt does not work.
> QPA backends:
> 1185   DirectFB ... no
> 1186   EGLFS .. yes
> 1187   EGLFS details:
> 1188 EGLFS OpenWFD  no
> 1189 EGLFS i.Mx6 .. no
> 1190 EGLFS i.Mx6 Wayland .. no
> 1191 EGLFS RCAR ... no
> 1192 EGLFS EGLDevice .. yes
> 1193 EGLFS GBM  yes
> 1194 EGLFS VSP2 ... no
> 1195 EGLFS Mali ... no
> 1196 EGLFS Raspberry Pi ... no
> 1197 EGL on X11 ... no
> 1198   LinuxFB  yes
> 1199   VNC  yes
> 1200   Mir client . no
>
> qt 5.10.1 working configure section
>  QPA backends:
> 1173   DirectFB ... no
> 1174   EGLFS .. yes
> 1175   EGLFS details:
> 1176 EGLFS OpenWFD  no
> 1177 EGLFS i.Mx6 .. no
> 1178 EGLFS i.Mx6 Wayland .. no
> 1179 EGLFS RCAR ... no
> 1180 EGLFS EGLDevice .. yes
> 1181 EGLFS GBM  yes
> 1182 EGLFS Mali ... no
> 1183 EGLFS Raspberry Pi ... no
> 1184 EGL on X11 ... no
> 1185   LinuxFB  yes
> 1186   VNC  yes
> 1187   Mir client . no
>
>
> I would appreciate any help with this issue.
>
>
>
> Thank you,
>
>
> Dexter
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Problems with QCamera/QML Camera when trying to porting a desktop application to android tablet

2018-07-31 Thread Roman Wüger 
Hello guys,
 
I try to port a desktop application to an android tablet. At the moment 
everthing seems to work smoothly except the camera stuff.
Previously QCamera with QCamerViewfinder was used but does not work on android, 
because I read that Qt Multimedia isn’t available on android and so I rewrote 
the entire camera stuff with QML.
 
A smaller application with only one dialog for demonstration works well. But 
since the desktop application is multi hierarchical with dialogs,
I whether does not see a video or in the second case the dialog in which the 
camera stuff is implemented is not shown.
This depends on whether I use QQuickView in combination with 
QWidget::createWindowContainer or QQuickWidget.
 
I saw the following entries, but the solutions are not working for me:
https://bugreports.qt.io/browse/QTBUG-49328
https://bugreports.qt.io/browse/QTBUG-41467
https://bugreports.qt.io/browse/QTBUG-39454
 
I tried Qt 5.9.5 to Qt 5.11.1 on an Samsung Galaxy Tab A (2016) with Android 7.0
 
I hope someone can help me with the problem.
 
Thanks in advance
 
Best Regards
Roman
 ___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Thiago Macieira 
On Tuesday, 31 July 2018 05:51:23 PDT Kai Koehne wrote:
> The original Qt Quick Compiler hasn't been open sourced. There were other
> optimizations though that might arguably made it less beneficial. See e.g.
> http://blog.qt.io/blog/2017/03/08/qt-qml-performance-improvements-qt-5-8-0/
> .

The qmlcachegen tool is not equivalent of the compiler. The cachegen parses 
the QML structure and stores a platform-independent bytecode. It does not 
store the JIT.

I spoke to Simon about this and he said that the JIT gain would be nice, but 
it's not necessary right now. It would add a lot of complication while we 
still have more to be gained from elsewhere.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Thiago Macieira 
On Tuesday, 31 July 2018 05:48:29 PDT Allan Sandfeld Jensen wrote:
> On Dienstag, 31. Juli 2018 14:02:23 CEST Christian Gagneraud wrote:
> > On 31 July 2018 at 23:45, Allan Sandfeld Jensen  wrote:
> > > The question was: Do you want security fixes or not? The reason it was
> > > done is because we have upped our game on security fixes in webengine.
> > 
> > Can't you just backport security fixes, eg like Debian and OpenBSD do?
> 
> Debian does not do that. They update ALL of chromium for every single
> update, even on the stable branch, because they don't have the manpower to
> backport security patches, and because backporting patches has severe
> limitations, especially for a full chromium browser as opposed to our
> subset of it. In fact no Linux distro does backports of security patches
> for Chromium, they have all given up.

You also have to remember there are lots of fixes that apply to security but 
aren't marked "security patches" and have no CVE associated with them. This 
applies to other big chunks of code too, like the Linux kernel.

If you want security, I recommend being on the latest latest. Not even the 
latest LTS. But at least for some projects, there's an effort to keep good 
LTSes that are secure (Linux, for example). Chromium doesn't.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Thiago Macieira 
On Tuesday, 31 July 2018 04:32:38 PDT Christian Gagneraud wrote:
> Should this (Chromium 45 -> 49) be part of "patch" release?

Yes. We should even go further. Web engines are really big attack vectors and 
need to be kept up to date.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Interest Digest, Vol 82, Issue 15

2018-07-31 Thread Roland Hughes 



On 07/31/2018 07:10 AM, interest-requ...@qt-project.org wrote:

Um, besides being a bit on the slow side (java?.), what was wrong with Eclipse 
for C++ dev? Back when it was around the choices were pretty limited. It still 
has a killer feature that even QtCreator does not have and that is the ability 
to hover over a macro and have the complete (including multiply levels) code 
generation show up. For code basis that heavily use macros this was a really 
great feature to have. And I could just have it use my premade makefiles or use 
my cmake generated makefiles without any complaints or regeneration.
It was really nasty with a lot of bugs. At the time it was created both 
KATE and KDevelop were better, but, Eclipse was the "teaser app" for Java.


The C plug-in was and still is rather horrible. I just used Eclipse 
earlier this year editing some OpenVMS C files. When you get past a few 
thousand lines Eclipse loses all ability to enforce your chosen style 
format so when you hit return after something you cannot be certain 
where the cursor will land. When a source file gets past 5,000 lines the 
editor becomes useless. Keep in mind I was just editing, then sending 
back to OpenVMS for compile and test.


I actually tested quite a few editors for that project because it ran 
longer than it should and Eclipse failed me. I chose Eclipse initially 
because the original C source files had ever coding style known to man 
and at least 3 which weren't. When I got done merging things together 
along with coding a whole bunch new I wanted it to look at least the 
tiniest bit coherent. I knew the style plugins for Eclipse would let me 
force a style on every file. What I didn't know was it had a severe size 
limitation. Java is a pig. This desktop has 24Gig of RAM but the JVM has 
always been worthless at resource allocation. Yes, I could have spent 
however long it took to find the place one needed to tweak for JVM 
memory allocation (it keeps moving), but, nobody should have to. The JVM 
should realize it's about out of RAM and go get more if it is available.


Atom failed pretty horribly editing for that project. So did UltraEdit. 
It failed bad enough I ended my subscription to the product. 
Code::Blocks and Codelight also had significant disappointments, I just 
don't remember what they were. Pluma didn't have quite enough uumph. I 
did purchase a Sublime license, but, it came up short too. Notepadqq 
served well as a scratch pad editor but had something . . . probably 
with style enforcement, which made it unusable for anything else.


Ultimately, during the last month of coding and debugging I did 
everything with KDevelop. The only annoying thing with KDevelop was I 
couldn't find out how to make it stop being helpful. When typing 
"standard" C functions it tried to be helpful using the version of C on 
the desktop prefilling values and popping up little syntax hints. The 
version of the C compiler on the target machine was pre-C99. Most of its 
help wasn't any use.


I did think about using Emacs, but I remembered my last experience with 
Emacs.


If it had an editor it would be a great operating system!

I was more focused on getting the project done than an exhaustive editor 
test. Ordinarily I, and most of us, don't need an editor which will let 
us toggle a very large source file between standard C source code 
formats. Usually I'm writing new and it is already set to my style. 
Because there were so many pieces coming from so many places I needed to 
continually do this.


Just my 0.0002 cents

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] qt 5.11 upgrade results in could not queue DRM page flip error on IMX6 etna

2018-07-31 Thread Dexter Travis 
(apologies for previous message without subject line.)

I am attempting to update a working yocto build system with imx6 dual plus
CPU running the following
kernel 4.14 with etnaviv
libmesa 17.3.0
libdrm 2.4.85
qt 5.9.2.  (qt 5.10.x also works)

I would like to update to sumo yocto with
kernel 4.16 with etnaviv
libmesa 17.3.8
libdrm 2.4.91
qt 5.11

This is an embedded device without X11 installed.

When I run Qt5_CinematicExperience -platform eglfs I get an error
"Could not queue DRM page flip on screen LVDS1 (Invalid argument)"  I get
the same error with my custom application.

If I run with -platform linuxfb the application runs correctly.

I have swapped out libdrm, the kernel and libmesa version and find that the
problem seems to follow my upgrade to qt 5.11.  Said another way, swapping
the components listed above leads me to believe the problem is with the qt
upgrade.  Running qt 5.11 with the other originally working components does
not work.

Looking at the configure log for qtbase (5.11) it looks like all the same
opengl options are configured as were configured in 5.9 and 5.10. See below.

qt 5.11 configure log details. This qt does not work.
QPA backends:
1185   DirectFB ... no
1186   EGLFS .. yes
1187   EGLFS details:
1188 EGLFS OpenWFD  no
1189 EGLFS i.Mx6 .. no
1190 EGLFS i.Mx6 Wayland .. no
1191 EGLFS RCAR ... no
1192 EGLFS EGLDevice .. yes
1193 EGLFS GBM  yes
1194 EGLFS VSP2 ... no
1195 EGLFS Mali ... no
1196 EGLFS Raspberry Pi ... no
1197 EGL on X11 ... no
1198   LinuxFB  yes
1199   VNC  yes
1200   Mir client . no

qt 5.10.1 working configure section
 QPA backends:
1173   DirectFB ... no
1174   EGLFS .. yes
1175   EGLFS details:
1176 EGLFS OpenWFD  no
1177 EGLFS i.Mx6 .. no
1178 EGLFS i.Mx6 Wayland .. no
1179 EGLFS RCAR ... no
1180 EGLFS EGLDevice .. yes
1181 EGLFS GBM  yes
1182 EGLFS Mali ... no
1183 EGLFS Raspberry Pi ... no
1184 EGL on X11 ... no
1185   LinuxFB  yes
1186   VNC  yes
1187   Mir client . no


I would appreciate any help with this issue.



Thank you,


Dexter
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] (no subject)

2018-07-31 Thread Dexter Travis 
I am attempting to update a working yocto build system with imx6 dual plus
CPU running the following
kernel 4.14 with etnaviv
libmesa 17.3.0
libdrm 2.4.85
qt 5.9.2.  (qt 5.10.x also works)

I would like to update to sumo yocto with
kernel 4.16 with etnaviv
libmesa 17.3.8
libdrm 2.4.91
qt 5.11

This is an embedded device without X11 installed.

When I run Qt5_CinematicExperience -platform eglfs I get an error
"Could not queue DRM page flip on screen LVDS1 (Invalid argument)"  I get
the same error with my custom application.

If I run with -platform linuxfb the application runs correctly.

I have swapped out libdrm, the kernel and libmesa version and find that the
problem seems to follow my upgrade to qt 5.11.  Said another way, swapping
the components listed above leads me to believe the problem is with the qt
upgrade.  Running qt 5.11 with the other originally working components does
not work.

Looking at the configure log for qtbase (5.11) it looks like all the same
opengl options are configured as were configured in 5.9 and 5.10. See below.

qt 5.11 configure log details. This qt does not work.
QPA backends:
1185   DirectFB ... no
1186   EGLFS .. yes
1187   EGLFS details:
1188 EGLFS OpenWFD  no
1189 EGLFS i.Mx6 .. no
1190 EGLFS i.Mx6 Wayland .. no
1191 EGLFS RCAR ... no
1192 EGLFS EGLDevice .. yes
1193 EGLFS GBM  yes
1194 EGLFS VSP2 ... no
1195 EGLFS Mali ... no
1196 EGLFS Raspberry Pi ... no
1197 EGL on X11 ... no
1198   LinuxFB  yes
1199   VNC  yes
1200   Mir client . no

qt 5.10.1 working configure section
 QPA backends:
1173   DirectFB ... no
1174   EGLFS .. yes
1175   EGLFS details:
1176 EGLFS OpenWFD  no
1177 EGLFS i.Mx6 .. no
1178 EGLFS i.Mx6 Wayland .. no
1179 EGLFS RCAR ... no
1180 EGLFS EGLDevice .. yes
1181 EGLFS GBM  yes
1182 EGLFS Mali ... no
1183 EGLFS Raspberry Pi ... no
1184 EGL on X11 ... no
1185   LinuxFB  yes
1186   VNC  yes
1187   Mir client . no


I would appreciate any help with this issue.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Kai Koehne 
> -Original Message-
> From: Christian Gagneraud 
> [...]
> > And building Qt for Linux 32 is a real pain.
> > Why don't you provide QQuickCompiler for Linux32 to your paid customers?
>
> Just to be clear: I cannot build QQuickCompiler for Linux32-qt5.6 myself, b/c
> AFAIK, source code is not available to us, although we're a paid customer.

No idea. Have you contacted Qt Support about this?

> Going a bit further, correct me if i'm wrong, but QuickCompiler is no secret
> anymore, hasn't it be source-released with Qt 5.9 or 5.12?

The original Qt Quick Compiler hasn't been open sourced. There were other 
optimizations though that might arguably made it less beneficial. See e.g. 
http://blog.qt.io/blog/2017/03/08/qt-qml-performance-improvements-qt-5-8-0/ .

Regards

Kai



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Allan Sandfeld Jensen 
On Dienstag, 31. Juli 2018 14:02:23 CEST Christian Gagneraud wrote:
> On 31 July 2018 at 23:45, Allan Sandfeld Jensen  wrote:
> >
> > The question was: Do you want security fixes or not? The reason it was
> > done is because we have upped our game on security fixes in webengine.
> 
> Can't you just backport security fixes, eg like Debian and OpenBSD do?

Debian does not do that. They update ALL of chromium for every single update, 
even on the stable branch, because they don't have the manpower to backport 
security patches, and because backporting patches has severe limitations, 
especially for a full chromium browser as opposed to our subset of it. In fact 
no Linux distro does backports of security patches for Chromium, they have all 
given up.

`Allan




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] qmlscene install problems (was: Interest, , Digest, Vol 82, , Issue 5)

2018-07-31 Thread Roland Hughes 



On 07/31/2018 07:10 AM, Michael Jackson wrote:

Maybe you should have tried another Linux distribution? I've never had a 
problem loading any of the QtCreators on our Ubuntu boxes (starting with 14.04 
up and through 18.04).
Well you should have since everybody else did and the Ubuntu forums were 
awash with requests for work arounds. I'm guessing it's because you 
really use Windows for development and cross compile elsewhere.


While the jury is still out if QML is a success or not I think that attempting to give 
developers quicker ways to build applications is something that should be pursued. What 
is wrong with wanting a more efficient way to create our applications. What is wrong with 
wanting to make our applications appeal to the "younger crowd" by using newer 
technologies. Just because something failed back then does not mean that iterating on 
that idea (RAD) is bound to failure again. As a community of developers we should always 
be pushing ahead with technologies to make our lives easier. Sometimes those technologies 
work and sometimes they don't. As long as we learn from the mistakes and keep forging 
ahead is what matters.

https://www.brainyquote.com/quotes/unknown_133991

Insanity: doing the same thing over and over again and expecting 
different results.


Nobody learns from the mistakes. They just hear "faster application 
development" and follow all the other leemings off the cliff.


Faster, Better, Cheaper - pick any two.

RAD didn't just fail "back then." RAD has failed EACH AND EVER TIME it 
has been re-introduced. The latest excuse for hacking on the fly without 
a plan is AGILE. The latest "tool" for it is QML.


Making horribly bad choices appears to be genetically fundamental to 
management.

Don't believe me?

Read up on INTEL's SEGMENT:OFFSET memory addressing in the original x86 
chips. Fine fine decision there, despite all of the other chips on the 
market which didn't do it because it was a stupid idea.


After IBM made a poor decision choosing x86, they made an idiotic 
decision to reserve the 384K above 640K for add-in cards/adapters rather 
than just skipping the first 384K at boot. Adding this insult to the 
injury of SEGMENT:OFFSET forced us to have C/C++ compilers which 
utilized Compact/Small/Medium/Large memory models. Linking object 
modules compiled under different memory models was a catastrophe not all 
compilers stopped.


Read up on all of the different DOS memory extenders
https://en.wikipedia.org/wiki/DOS_extender

If you are too young to have used them, also read up on overlay linkers 
trying to page stuff in and out.

https://www.pcorner.com/list/DBASE/BLIDEM.ZIP/BLINKER.DOC/

The fault with RAD, the fault with AGILE and even the fault with X-treme 
programming along with every other term for that throughout the decade, 
is that they are all marketing fraud for hacking on the fly. The RAD 
type tool sets attempt to bring non-programmers into the programming 
universe to force down labor costs. This also forces down the quality of 
delivered systems.


For any tiny system which doesn't really matter, one where a single 
person really can see each and every aspect of it in their head ALL AT 
ONCE, you can hack on the fly. The real trouble is, nobody is willing to 
admit just how small a system that really is. That's why I get multiple 
phone calls and emails each day from pimps pitching contracts to come in 
and salvage a project which was QML and AGILE and now in an absolute 
destitute state. They've no learned the hard way a 50% solution can't be 
stretched to 100%


Guess what? They'll try the exact same thing on the next project.

Insanity: doing the same thing over and over again and expecting 
different results.




--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Christian Gagneraud 
On 1 August 2018 at 00:09, Christian Gagneraud  wrote:
> On 31 July 2018 at 23:55, Kai Koehne  wrote:
>>> -Original Message-
>>> From: Interest  On Behalf
>>> Of Christian Gagneraud
>>> [...]
>>> >> We used to build Qt-5.6.3 on and for Linux-i386.
>>> >> I recently had to downgrade to Qt-5.6.0 [...]
>>
>>> I don't want to be mean or rude, but honestly i have notice a degradation of
>>> patch release management in the recent years...
>>> To the point that now the "Qt Maintenance Tool" offers you to install 
>>> different
>>> patch release, like nobody trust they are actually equivalent and ABI 
>>> backward
>>> compatible as they used to be...
>>
>> Criticizing the MaintenanceTool to (again) provide non-latest patch level 
>> releases in a thread you started with "I recently had to downgrade to Qt 
>> 5.6.0' is ... interesting 
>
> It is indeed! ;)
> The core problem, is that you have dropped Linux32 for both open
> source and commercial users.
>
> Unfortunately the code base i'm dealing with cannot run on 64 bits
> machine (both runtime and build time).
> We need to run Qt 5.6 on:
> - Windows/intel 32 bits
> - Linux/intel 32 bits
> - Linux/arm 32 bits
>
> We need to build Qt and Qt apps on:
> - Windows/intel 32 bits
> - Linux/intel 32 bits
>
> And building Qt for Linux 32 is a real pain.
> Why don't you provide QQuickCompiler for Linux32 to your paid customers?

Just to be clear: I cannot build QQuickCompiler for Linux32-qt5.6
myself, b/c AFAIK, source code is not available to us, although we're
a paid customer.

Going a bit further, correct me if i'm wrong, but QuickCompiler is no
secret anymore, hasn't it be source-released with Qt 5.9 or 5.12?

Chris
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Christian Gagneraud 
On 31 July 2018 at 23:55, Kai Koehne  wrote:
>> -Original Message-
>> From: Interest  On Behalf
>> Of Christian Gagneraud
>> [...]
>> >> We used to build Qt-5.6.3 on and for Linux-i386.
>> >> I recently had to downgrade to Qt-5.6.0 [...]
>
>> I don't want to be mean or rude, but honestly i have notice a degradation of
>> patch release management in the recent years...
>> To the point that now the "Qt Maintenance Tool" offers you to install 
>> different
>> patch release, like nobody trust they are actually equivalent and ABI 
>> backward
>> compatible as they used to be...
>
> Criticizing the MaintenanceTool to (again) provide non-latest patch level 
> releases in a thread you started with "I recently had to downgrade to Qt 
> 5.6.0' is ... interesting 

It is indeed! ;)
The core problem, is that you have dropped Linux32 for both open
source and commercial users.

Unfortunately the code base i'm dealing with cannot run on 64 bits
machine (both runtime and build time).
We need to run Qt 5.6 on:
- Windows/intel 32 bits
- Linux/intel 32 bits
- Linux/arm 32 bits

We need to build Qt and Qt apps on:
- Windows/intel 32 bits
- Linux/intel 32 bits

And building Qt for Linux 32 is a real pain.
Why don't you provide QQuickCompiler for Linux32 to your paid customers?

Chris
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Christian Gagneraud 
On 31 July 2018 at 23:45, Allan Sandfeld Jensen  wrote:
> On Dienstag, 31. Juli 2018 13:32:38 CEST Christian Gagneraud wrote:
>> On 31 July 2018 at 21:43, Allan Sandfeld Jensen  wrote:
>> > On Sonntag, 29. Juli 2018 22:58:41 CEST Christian Gagneraud wrote:
>> >> Hi,
>> >>
>> >> We used to build Qt-5.6.3 on and for Linux-i386.
>> >> I recently had to downgrade to Qt-5.6.0 (see below), but now the build
>> >> fails with:
>> >>
>> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:
>> >> In function 'ssl3_ChaCha20Poly1305':
>> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2118:
>> >> 15: error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no
>> >> member named 'pIv'
>> >>
>> >>  aeadParams.pIv = (unsigned char *) additionalData;
>> >>
>> >>^
>> >>
>> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2119:
>> >> 15: error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no
>> >> member named 'ulIvLen'
>> >>
>> >>  aeadParams.ulIvLen = 8;
>> >>
>> >>^
>> >>
>> >> Are there any special requirements,or actually is there a difference
>> >> in the requirements, to build Qt5.6.0 vs Qt-5.6.3?
>> >
>> > Yes. It is most likely NSS, it could in 5.6.0 be used for both encryption
>> > and certicate checking but in 5.6.3 is only used for certificate
>> > checking. You can try using NSS 3.21, but note it will report most Google
>> > certificates as broken. You can also try removing libnss-dev in which
>> > case OpenSSL will be used for both, but that also means most Google
>> > certicates are reported as broken (because they objectively are signed by
>> > a too weak root).
>>
>> Thanks for all the details, greatly appreciated. I'll have to dig that
>> further, will report.
>>
>> > See https://codereview.qt-project.org/#/c/153890/ perhaps you can cherry
>> > pick it, though it might not be easy QtWebEngine also upgraded from
>> > Chromium 45 to 49 in the 5.6 series.
>>
>> What can I say other than:
>> Should this (Chromium 45 -> 49) be part of "patch" release?
>
> The question was: Do you want security fixes or not? The reason it was done is
> because we have upped our game on security fixes in webengine.

Can't you just backport security fixes, eg like Debian and OpenBSD do?
Adopting a new upstream MAJOR release b/c it contains security fixes is futile.
Every new MAJOR release brings up security fixes AND security regressions.
So while you fix something you introduce new, unknown security issues.

OK, I don't want to start a war, that's my basic understanding of
strict fixes vs blind upgrade.
I'm pretty sure that you've considered this problem 200 times before
coming with a decision.

I want security fixes, and ONLY security fixes.
To be honest my boss don't give a #&%%^#^* about security fixes, so i
just want a successful build, but that is another story

> Note 5.6.2 was the first and so far only time we have done this in a patch
> release, and I don't think it was worth the trouble. Since then I have
> prefered to recommend people using a more modern qtwebenigne with older
> qtbase. Note for instance, you can use up to QtWebEngine 5.9.x with the rest
> of Qt being 5.6. In fact if you use QtWebEngine on potentially hostile
> content, I would strongly recommend it as Qt 5.6.x is not updated as
> regularly.
>
> In fact using a newer QtWebEngine even if just the last one from 5.6.x with
> qtdeclarive being 5.6.0, might solve your problems.
>
>> To the point that now the "Qt Maintenance Tool" offers you to install
>> different patch release, like nobody trust they are actually
>> equivalent and ABI backward compatible as they used to be...
>
> I don't think that is fair. I know there has been a few mistakes, but they
> have usually been corner cases. When every other C++ project broke ABI due to
> C++11 Qt was able to maintain it due to how serious we have always taken it.
> But yes, you should always check if things still work when upgrading.

Maybe, there is a difference b/w runtime compatibility and build time
compatibility.
Because i have to build Qt myself (b/c Linux 32 is not supported any
more, even for commercial users), i'm hitting this build time
issues...

What drives me nuts in this story is that you still happily support WIN32...

Chris
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Kai Koehne 
> -Original Message-
> From: Interest  On Behalf
> Of Christian Gagneraud
> [...]
> >> We used to build Qt-5.6.3 on and for Linux-i386.
> >> I recently had to downgrade to Qt-5.6.0 [...]

> I don't want to be mean or rude, but honestly i have notice a degradation of
> patch release management in the recent years...
> To the point that now the "Qt Maintenance Tool" offers you to install 
> different
> patch release, like nobody trust they are actually equivalent and ABI backward
> compatible as they used to be...

Criticizing the MaintenanceTool to (again) provide non-latest patch level 
releases in a thread you started with "I recently had to downgrade to Qt 5.6.0' 
is ... interesting 

Kai
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Allan Sandfeld Jensen 
On Dienstag, 31. Juli 2018 13:32:38 CEST Christian Gagneraud wrote:
> On 31 July 2018 at 21:43, Allan Sandfeld Jensen  wrote:
> > On Sonntag, 29. Juli 2018 22:58:41 CEST Christian Gagneraud wrote:
> >> Hi,
> >> 
> >> We used to build Qt-5.6.3 on and for Linux-i386.
> >> I recently had to downgrade to Qt-5.6.0 (see below), but now the build
> >> fails with:
> >> 
> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:
> >> In function 'ssl3_ChaCha20Poly1305':
> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2118:
> >> 15: error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no
> >> member named 'pIv'
> >> 
> >>  aeadParams.pIv = (unsigned char *) additionalData;
> >>  
> >>^
> >> 
> >> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2119:
> >> 15: error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no
> >> member named 'ulIvLen'
> >> 
> >>  aeadParams.ulIvLen = 8;
> >>  
> >>^
> >> 
> >> Are there any special requirements,or actually is there a difference
> >> in the requirements, to build Qt5.6.0 vs Qt-5.6.3?
> > 
> > Yes. It is most likely NSS, it could in 5.6.0 be used for both encryption
> > and certicate checking but in 5.6.3 is only used for certificate
> > checking. You can try using NSS 3.21, but note it will report most Google
> > certificates as broken. You can also try removing libnss-dev in which
> > case OpenSSL will be used for both, but that also means most Google
> > certicates are reported as broken (because they objectively are signed by
> > a too weak root).
> 
> Thanks for all the details, greatly appreciated. I'll have to dig that
> further, will report.
> 
> > See https://codereview.qt-project.org/#/c/153890/ perhaps you can cherry
> > pick it, though it might not be easy QtWebEngine also upgraded from
> > Chromium 45 to 49 in the 5.6 series.
> 
> What can I say other than:
> Should this (Chromium 45 -> 49) be part of "patch" release?

The question was: Do you want security fixes or not? The reason it was done is 
because we have upped our game on security fixes in webengine.

Note 5.6.2 was the first and so far only time we have done this in a patch 
release, and I don't think it was worth the trouble. Since then I have 
prefered to recommend people using a more modern qtwebenigne with older 
qtbase. Note for instance, you can use up to QtWebEngine 5.9.x with the rest 
of Qt being 5.6. In fact if you use QtWebEngine on potentially hostile 
content, I would strongly recommend it as Qt 5.6.x is not updated as 
regularly.

In fact using a newer QtWebEngine even if just the last one from 5.6.x with 
qtdeclarive being 5.6.0, might solve your problems.

> To the point that now the "Qt Maintenance Tool" offers you to install
> different patch release, like nobody trust they are actually
> equivalent and ABI backward compatible as they used to be...

I don't think that is fair. I know there has been a few mistakes, but they 
have usually been corner cases. When every other C++ project broke ABI due to 
C++11 Qt was able to maintain it due to how serious we have always taken it. 
But yes, you should always check if things still work when upgrading.

Best Regards
'Allan


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Christian Gagneraud 
On 31 July 2018 at 21:43, Allan Sandfeld Jensen  wrote:
> On Sonntag, 29. Juli 2018 22:58:41 CEST Christian Gagneraud wrote:
>> Hi,
>>
>> We used to build Qt-5.6.3 on and for Linux-i386.
>> I recently had to downgrade to Qt-5.6.0 (see below), but now the build
>> fails with:
>>
>> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:
>> In function 'ssl3_ChaCha20Poly1305':
>> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2118:15:
>> error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no member
>> named 'pIv'
>>  aeadParams.pIv = (unsigned char *) additionalData;
>>^
>> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2119:15:
>> error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no member
>> named 'ulIvLen'
>>  aeadParams.ulIvLen = 8;
>>^
>>
>> Are there any special requirements,or actually is there a difference
>> in the requirements, to build Qt5.6.0 vs Qt-5.6.3?
>>
> Yes. It is most likely NSS, it could in 5.6.0 be used for both encryption and
> certicate checking but in 5.6.3 is only used for certificate checking. You can
> try using NSS 3.21, but note it will report most Google certificates as
> broken. You can also try removing libnss-dev in which case OpenSSL will be
> used for both, but that also means most Google certicates are reported as
> broken (because they objectively are signed by a too weak root).

Thanks for all the details, greatly appreciated. I'll have to dig that
further, will report.

> See https://codereview.qt-project.org/#/c/153890/ perhaps you can cherry pick
> it, though it might not be easy QtWebEngine also upgraded from Chromium 45 to
> 49 in the 5.6 series.

What can I say other than:
Should this (Chromium 45 -> 49) be part of "patch" release?
I don't want to be mean or rude, but honestly i have notice a
degradation of patch release management in the recent years...
To the point that now the "Qt Maintenance Tool" offers you to install
different patch release, like nobody trust they are actually
equivalent and ABI backward compatible as they used to be...

Thanks for the heads up and sorry for the complain, i know everyone is
doing their best but having to deal with Qt and Linux 32 bits in 2018
is like trying to fit a square in a circle. No matter how big is your
hammer, you'll hit a titanium wall

Chris
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Chromium build failure, SSL and Qt 5.6.3 vs 5.6.0,

2018-07-31 Thread Allan Sandfeld Jensen 
On Sonntag, 29. Juli 2018 22:58:41 CEST Christian Gagneraud wrote:
> Hi,
> 
> We used to build Qt-5.6.3 on and for Linux-i386.
> I recently had to downgrade to Qt-5.6.0 (see below), but now the build
> fails with:
> 
> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:
> In function 'ssl3_ChaCha20Poly1305':
> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2118:15:
> error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no member
> named 'pIv'
>  aeadParams.pIv = (unsigned char *) additionalData;
>^
> qtwebengine/src/3rdparty/chromium/net/third_party/nss/ssl/ssl3con.c:2119:15:
> error: 'CK_NSS_AEAD_PARAMS {aka struct CK_NSS_AEAD_PARAMS}' has no member
> named 'ulIvLen'
>  aeadParams.ulIvLen = 8;
>^
> 
> Are there any special requirements,or actually is there a difference
> in the requirements, to build Qt5.6.0 vs Qt-5.6.3?
> 
Yes. It is most likely NSS, it could in 5.6.0 be used for both encryption and 
certicate checking but in 5.6.3 is only used for certificate checking. You can 
try using NSS 3.21, but note it will report most Google certificates as 
broken. You can also try removing libnss-dev in which case OpenSSL will be 
used for both, but that also means most Google certicates are reported as 
broken (because they objectively are signed by a too weak root).

See https://codereview.qt-project.org/#/c/153890/ perhaps you can cherry pick 
it, though it might not be easy QtWebEngine also upgraded from Chromium 45 to 
49 in the 5.6 series.

'Allan




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QListView with delegate: support drag outside of QApplication

2018-07-31 Thread Frank Rueter | OHUfx 

Anybody?
Been trying to play with the view's dragMoveEvent to take over the 
default drag event's mime data and create a custom QDrag instance with 
it, but that crashes. I also tried just adding test to the event's mime 
data, but that  has no effect.

Maybe I do need to just re-implement the drag from scratch?

It feels like there should be a more elegant solution, right?!

Cheers,
frank

On 30/07/18 3:24 PM, Frank Rueter | OHUfx wrote:


Hi all,

I have an app that uses two QListViews with delegates.
The user can drag ad drop items from one view into the other to create 
something like a shopping list.

So far so good.
Now I need to enable the user to also drag an item out of the 
application entirely.
Is it possible to access the drag event data that the list view 
produces by default, so I don’t have to re-invent the wheel for the 
already functioning internal drag?


Here is a simplified example that just needs support for dragging an 
item outside of the QApplication.


Any tips would be much appreciated.

Cheers,
frank

|import sys from PySide import QtGui, QtCore app = 
QtGui.QApplication(sys.argv) class MyList(QtGui.QListView): def 
__init__(self, parent=None): super(MyList, self).__init__(parent) 
self.setDragEnabled(True) self.setAcceptDrops(True) list1 = MyList() 
list2 = MyList() model1 = QtGui.QStandardItemModel(list1) model2 = 
QtGui.QStandardItemModel(list1) 
model2.setItemPrototype(QtGui.QStandardItem()) foods = [ 'Cookie 
dough', 'Hummus', 'Spaghetti', 'Dal makhani', 'Chocolate whipped 
cream' ] for food in foods: item = QtGui.QStandardItem(food) 
model1.appendRow(item) list1.setModel(model1) list2.setModel(model2) w 
= QtGui.QSplitter() w.addWidget(list1) w.addWidget(list2) w.show() 
w.raise_() app.exec_() |

​
--

ohufxLogo 50x50 
	*vfx compositing  | *workflow 
customisation and consulting * *

**
   


Your gateway to over 1,000 free tools... right inside of Nuke 





___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest