Re: [Development] Moving IRC from Freenode to Libera.Chat, voting thread

[Giuseppe D'Angelo via Development]

On 22/05/2021 03:06, Giuseppe D'Angelo via Development wrote:

== DEADLINE FOR VOTING ==

23.59 CEST of Thursday 27 May 2021.


We have unanimous consent.

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

Re: [Development] QString, QVariant and QSQLite

[Alberto Mardegan]

On 27/05/21 11:50, Giuseppe D'Angelo via Development wrote:
> In the overwhelming majority of cases, utf16() won't make any
> allocation. There's just one exception -- if the QString was built via
> fromRawData(). In that case, in order to ensure NUL termination, utf16()
> does actually "detach" (even if it's a const method).

mmm... The string is created in QML and assigned to a property, like this:

relationshipType: "Aggregates"

so I'm not sure if this uses fromRawData() or something else.

>> And why destroying a const QVariant causes the deallocation of the data
>> created by QString::utf16()??
> 
> QString::utf16 doesn't "create" data: it modifies the string *itself* so
> that it becomes detached and NUL terminated.

Sure, I meant s/created/allocated/

Anyway, I filed this bug:
https://bugreports.qt.io/browse/QTBUG-94070

Ciao,
  Alberto

-- 
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt Multimedia

[Jason H]

> > If it matters: I disclaim any copyright for the attached 
> > files.
>
> Thanks for the snippet. I think this should be perfectly doable. Connect to 
> the signal, then map the QVideoFrame and copy out the Y channel.


One ask that may not be captured anywhere: currently, it is impossible to have 
a QML Camera and not start it.

If I could request,
1. a way to probe hardware without activating it
2. a way to have a QML Camera without getting frames from it, that is to set 
`active: false` is the default. Currently, there is not even active property. 
We have to do a Component.onCompleted: stop() which has already triggered the 
permission dialog. This was ok in the past, but the trend and proper usage is 
to request permission only when it is needed.



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

Re: [Development] [EXTERNAL EMAIL] cmake targets for plugins are still not working (QTBUG-89643)

[Mark De Wit]

Note, I've been informed on that bug that shared and static builds require 
different fixes and therefore created a new bug report QTBUG-94066 for fixing 
the shared / official installs versions.

Thank,
Mark

From: Development  On Behalf Of Mark De Wit
Sent: 27 May 2021 17:50
To: Development@qt-project.org
Subject: [EXTERNAL EMAIL] [Development] cmake targets for plugins are still not 
working (QTBUG-89643)

I'd like to flag up bug report https://bugreports.qt.io/browse/QTBUG-89643 
which is closed as fixed in Qt 6.1.0 but is still (or again) broken in Qt 6.1.1

I added a comment to the Bug, but in my testing, the Qt6 Gui module does not 
load its plugin as part of its cmake processing, and CMake thus tells me:

get_target_property() called with non-existent target
"Qt6::QWindowsIntegrationPlugin".
And...
get_target_property() called with non-existent target
"Qt6::QSvgIconPlugin".
Etc...

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

[Development] cmake targets for plugins are still not working (QTBUG-89643)

[Mark De Wit]

I'd like to flag up bug report https://bugreports.qt.io/browse/QTBUG-89643 
which is closed as fixed in Qt 6.1.0 but is still (or again) broken in Qt 6.1.1

I added a comment to the Bug, but in my testing, the Qt6 Gui module does not 
load its plugin as part of its cmake processing, and CMake thus tells me:

get_target_property() called with non-existent target
"Qt6::QWindowsIntegrationPlugin".
And...
get_target_property() called with non-existent target
"Qt6::QSvgIconPlugin".
Etc...

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

On 27 May 2021, at 16:18, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:
On 27 May 2021, at 15:34, Eike Hein mailto:h...@kde.org>> wrote:

May 27, 2021 2:51 PM, "Samuel Gaist" 
mailto:samuel.ga...@idiap.ch>> wrote:
I think one of the main use case I have seen for custom GStreamer pipelines is 
to be able to get
rtsp or other network streams in Qt applications.

This is my personal use case as well. With the addition that I also have
some pipelines where I need to deal with RTP without the convenience of
an RTSP session setup around it (in https://kirogi.org, which is
currently on gst-qmlsink for Qt Quick integration - drones do all sorts
of funky streaming things).

we accept a url as the source for the media. For gstreamer we use uridecodebin 
to decode that URL. Afaik that automatically gives you rtp and rtsp support (at 
least if the required gstreamer plugins are installed)

Just did a check with the player example and

./player rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov

works just fine. Hope that solves that problem :)

Cheers,
Lars


You can also specify a QIODevice as the source. I’m that case we’re using a 
GstAppSrc together with a decodebin.

Cheers,
Lars


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

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 27 May 2021, at 15:34, Eike Hein  wrote:
> 
> May 27, 2021 2:51 PM, "Samuel Gaist"  wrote:
>> I think one of the main use case I have seen for custom GStreamer pipelines 
>> is to be able to get
>> rtsp or other network streams in Qt applications.
> 
> This is my personal use case as well. With the addition that I also have
> some pipelines where I need to deal with RTP without the convenience of
> an RTSP session setup around it (in https://kirogi.org, which is
> currently on gst-qmlsink for Qt Quick integration - drones do all sorts
> of funky streaming things).
> 
we accept a url as the source for the media. For gstreamer we use uridecodebin 
to decode that URL. Afaik that automatically gives you rtp and rtsp support (at 
least if the required gstreamer plugins are installed)

You can also specify a QIODevice as the source. I’m that case we’re using a 
GstAppSrc together with a decodebin. 

Cheers,
Lars
> 
> 
> Cheers,
> Eike
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt Multimedia

[Lars Knoll]

On 27 May 2021, at 15:25, Rodrigo Gonçalves de Oliveira 
 wrote:


Also, this is how I define and change different audio devices ("gst-pipeline: 
... audio_sink=\"alsasink device=%1\") on demand.
Are there plans to have an easy way to change the output audio device? Think on 
an embedded system, within a media app and multiple audio devices, where the 
user want to change the audio output device at any time.

Have a look at QMediaDevices that lets you discover different inputs/outputs. 
You can also get notifications when a new output becomes available (eg. because 
you connected a headset).

QMediaPlayer and QMediaCaptureSession have an API that let you choose the 
output you want based on the available devices you can get from QMediaDevices.

Cheers,
Lars

On Thu, May 27, 2021 at 9:54 AM Samuel Gaist via Development 
mailto:development@qt-project.org>> wrote:

> On 27 May 2021, at 14:35, Lars Knoll 
> mailto:lars.kn...@qt.io>> wrote:
>
>> On 27 May 2021, at 14:25, Eike Hein mailto:h...@kde.org>> 
>> wrote:
>>
>> May 27, 2021 8:14 AM, "Lars Knoll" 
>> mailto:lars.kn...@qt.io>> wrote:
>>> The one thing I want to avoid is what we had in Qt 5, where you could force 
>>> Qt MM to use a
>>> different/custom gstreamer pipeline based on environment variables. That 
>>> part made maintaining the
>>> code base extremely hard. Other than that I’m of course open for patches 
>>> and improvements. If some
>>> integration points are needed, we can discuss those separately, but unless 
>>> they are trivial, they
>>> will probably need to wait until after 6.2.
>>
>> Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the 
>> `source`
>> prop is getting dropped as well?
>
> That’s correct. It’s has honestly been a huge cludge, and something we didn’t 
> have anywhere else. I’d rather see that we fix issues inside Qt MM instead of 
> working around them with hacks such as this one.
>>
>> If memory serves right, this was possible accidentally at some point and then
>> was raised to the status of Official Footgun in 5.12+:
>>
>> https://doc.qt.io/qt-5/qmediaplayer.html#setMedia
>
> Footgun is probably the right name for it, and a reason I don’t want to 
> continue with it for Qt 6.
>>
>> A potential troublemaker for sure, but also very powerful. With QtGStreamer
>> being deprecated (an old set of Qt bindings to GStreamer API - also something
>> at least one KDE app I'm aware of still carries an internal fork of, sadly),
>> a QtMM w/ custom pipeline support sort of the next best thing.
>
> Lets rather have a look at the use cases that people want to have supported 
> and how we can get those working.
>
> Cheers,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

I think one of the main use case I have seen for custom GStreamer pipelines is 
to be able to get rtsp or other network streams in Qt applications.

Best regards

Samuel

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


--
Rodrigo Oliveira
Florianópolis, Brazil
rodrigo.gol...@gmail.com
+55 48 91605760
http://br.linkedin.com/in/rodrigogoliveira
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt Multimedia

[Eike Hein]

May 27, 2021 2:51 PM, "Samuel Gaist"  wrote:
> I think one of the main use case I have seen for custom GStreamer pipelines 
> is to be able to get
> rtsp or other network streams in Qt applications.

This is my personal use case as well. With the addition that I also have
some pipelines where I need to deal with RTP without the convenience of
an RTSP session setup around it (in https://kirogi.org, which is
currently on gst-qmlsink for Qt Quick integration - drones do all sorts
of funky streaming things).



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

Re: [Development] New Qt Multimedia

[Rodrigo Gonçalves de Oliveira]

Also, this is how I define and change different audio devices
("gst-pipeline: ... audio_sink=\"alsasink device=%1\") on demand.
Are there plans to have an easy way to change the output audio device?
Think on an embedded system, within a media app and multiple audio devices,
where the user want to change the audio output device at any time.

On Thu, May 27, 2021 at 9:54 AM Samuel Gaist via Development <
development@qt-project.org> wrote:

>
> > On 27 May 2021, at 14:35, Lars Knoll  wrote:
> >
> >> On 27 May 2021, at 14:25, Eike Hein  wrote:
> >>
> >> May 27, 2021 8:14 AM, "Lars Knoll"  wrote:
> >>> The one thing I want to avoid is what we had in Qt 5, where you could
> force Qt MM to use a
> >>> different/custom gstreamer pipeline based on environment variables.
> That part made maintaining the
> >>> code base extremely hard. Other than that I’m of course open for
> patches and improvements. If some
> >>> integration points are needed, we can discuss those separately, but
> unless they are trivial, they
> >>> will probably need to wait until after 6.2.
> >>
> >> Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the
> `source`
> >> prop is getting dropped as well?
> >
> > That’s correct. It’s has honestly been a huge cludge, and something we
> didn’t have anywhere else. I’d rather see that we fix issues inside Qt MM
> instead of working around them with hacks such as this one.
> >>
> >> If memory serves right, this was possible accidentally at some point
> and then
> >> was raised to the status of Official Footgun in 5.12+:
> >>
> >> https://doc.qt.io/qt-5/qmediaplayer.html#setMedia
> >
> > Footgun is probably the right name for it, and a reason I don’t want to
> continue with it for Qt 6.
> >>
> >> A potential troublemaker for sure, but also very powerful. With
> QtGStreamer
> >> being deprecated (an old set of Qt bindings to GStreamer API - also
> something
> >> at least one KDE app I'm aware of still carries an internal fork of,
> sadly),
> >> a QtMM w/ custom pipeline support sort of the next best thing.
> >
> > Lets rather have a look at the use cases that people want to have
> supported and how we can get those working.
> >
> > Cheers,
> > Lars
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
> I think one of the main use case I have seen for custom GStreamer
> pipelines is to be able to get rtsp or other network streams in Qt
> applications.
>
> Best regards
>
> Samuel
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


-- 
Rodrigo Oliveira
Florianópolis, Brazil
rodrigo.gol...@gmail.com
+55 48 91605760
http://br.linkedin.com/in/rodrigogoliveira
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QWebEnginePage and Qt 6: protected virtual functions and signals

[Allan Sandfeld Jensen]

On Donnerstag, 27. Mai 2021 14:41:54 CEST you wrote:
> On Thu, 27 May 2021 at 14:17, Allan Sandfeld Jensen 
> 
> But it does not change my point about signal vs protected functions.
> Let's say I have a QWebEnginePage subclass that only allows some SSL errors
> by checking asynchronously a blocked list (using the defer() function of
> the QWebEngineCertificateError)
> External code can connect to the signal and ignore/block the error before
> the async check has completed, breaking the behavior of the subclass.
> 
> IMHO using signals to implement the class behavior breaks encapsulation.
> The behavior that was protected and defined in the class, is now defined
> outside of the class and is publicly available to be overridden.
> Signals are not a replacement for virtual protected functions.
> 
> I have a strong feeling that moving signals, without having the ability to
> block signals by implementing protected functions, will lead to brittle
> code for Qt users.
> The worse part, is that right now it is possible in user code to
> implement a SignalWebEnginePage, that will expose its protected functions
> as signals.
> After moving to signals, it won't be possible to not expose them. With this
> change, as-is, Qt users are losing features, for some convenience that they
> could implement themselves with a few lines of code.

Most of the changes to signal form are not that simple, and requires a lot 
more work. Not even sure we will manage to deal with the mess that is  
acceptNavigationRequest before feature freeze. The rework of createWindow for 
instance meant using a new class (or reusing it from the qml api), but also 
exposes way more information for the developer and could be expanded with more 
information at a later stage without breaking ABI of QWebEnginePage. See 
https://codereview.qt-project.org/c/qt/qtwebengine/+/346723

It was pretty much only certificate-error that was so simple as just calling 
either a signal or virtual method. And the only reason the derived method was 
removed was because a previous refactoring had already changed its signature 
making it less useful for source compatibility. We could easily keep the 
derived method, it just seemed redundant, and the ideal name for both clashed, 
meaning one would have to have an odd name. See first version of https://
codereview.qt-project.org/c/qt/qtwebengine/+/346682/1

Best regards
Allan


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

Re: [Development] New Qt Multimedia

[Samuel Gaist via Development]

> On 27 May 2021, at 14:35, Lars Knoll  wrote:
> 
>> On 27 May 2021, at 14:25, Eike Hein  wrote:
>> 
>> May 27, 2021 8:14 AM, "Lars Knoll"  wrote:
>>> The one thing I want to avoid is what we had in Qt 5, where you could force 
>>> Qt MM to use a
>>> different/custom gstreamer pipeline based on environment variables. That 
>>> part made maintaining the
>>> code base extremely hard. Other than that I’m of course open for patches 
>>> and improvements. If some
>>> integration points are needed, we can discuss those separately, but unless 
>>> they are trivial, they
>>> will probably need to wait until after 6.2.
>> 
>> Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the 
>> `source`
>> prop is getting dropped as well?
> 
> That’s correct. It’s has honestly been a huge cludge, and something we didn’t 
> have anywhere else. I’d rather see that we fix issues inside Qt MM instead of 
> working around them with hacks such as this one.
>> 
>> If memory serves right, this was possible accidentally at some point and then
>> was raised to the status of Official Footgun in 5.12+:
>> 
>> https://doc.qt.io/qt-5/qmediaplayer.html#setMedia
> 
> Footgun is probably the right name for it, and a reason I don’t want to 
> continue with it for Qt 6.
>> 
>> A potential troublemaker for sure, but also very powerful. With QtGStreamer
>> being deprecated (an old set of Qt bindings to GStreamer API - also something
>> at least one KDE app I'm aware of still carries an internal fork of, sadly),
>> a QtMM w/ custom pipeline support sort of the next best thing.
> 
> Lets rather have a look at the use cases that people want to have supported 
> and how we can get those working.
> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

I think one of the main use case I have seen for custom GStreamer pipelines is 
to be able to get rtsp or other network streams in Qt applications.

Best regards

Samuel

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

Re: [Development] QWebEnginePage and Qt 6: protected virtual functions and signals

[Benjamin TERRIER]

On Thu, 27 May 2021 at 14:17, Allan Sandfeld Jensen 
wrote:

> On Donnerstag, 27. Mai 2021 13:55:01 CEST Benjamin TERRIER wrote:
> > On Thu, 27 May 2021 at 11:25, Allan Sandfeld Jensen 
> >
> > But then in my code, each time I see a CrazySSLPage I am never sure that
> it
> > will ignore SSL errors. Maybe someone called QObject::disconnect() on it.
> >
> > CrazySSLPage page;
> > page.disconnect(); // It's just a QWebEnginePage now
>
> If you call disconnect on a QWebEnginePage (or most advanced Qt classes)
> you
> have bigger problems than that, we rely on that for internal stuff too. As
> a
> C++ toolkit we can not protect users from doing bad things, it is always
> in
> their power.
>

Then maybe a warning  should be added to:
https://doc.qt.io/qt-5/qobject.html#disconnect-2

But it does not change my point about signal vs protected functions.
Let's say I have a QWebEnginePage subclass that only allows some SSL errors
by checking asynchronously a blocked list (using the defer() function of
the QWebEngineCertificateError)
External code can connect to the signal and ignore/block the error before
the async check has completed, breaking the behavior of the subclass.

IMHO using signals to implement the class behavior breaks encapsulation.
The behavior that was protected and defined in the class, is now defined
outside of the class and is publicly available to be overridden.
Signals are not a replacement for virtual protected functions.

I have a strong feeling that moving signals, without having the ability to
block signals by implementing protected functions, will lead to brittle
code for Qt users.
The worse part, is that right now it is possible in user code to
implement a SignalWebEnginePage, that will expose its protected functions
as signals.
After moving to signals, it won't be possible to not expose them. With this
change, as-is, Qt users are losing features, for some convenience that they
could implement themselves with a few lines of code.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 27 May 2021, at 14:25, Eike Hein  wrote:
> 
> May 27, 2021 8:14 AM, "Lars Knoll"  wrote:
>> The one thing I want to avoid is what we had in Qt 5, where you could force 
>> Qt MM to use a
>> different/custom gstreamer pipeline based on environment variables. That 
>> part made maintaining the
>> code base extremely hard. Other than that I’m of course open for patches and 
>> improvements. If some
>> integration points are needed, we can discuss those separately, but unless 
>> they are trivial, they
>> will probably need to wait until after 6.2.
> 
> Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the 
> `source`
> prop is getting dropped as well?

That’s correct. It’s has honestly been a huge cludge, and something we didn’t 
have anywhere else. I’d rather see that we fix issues inside Qt MM instead of 
working around them with hacks such as this one.
> 
> If memory serves right, this was possible accidentally at some point and then
> was raised to the status of Official Footgun in 5.12+:
> 
> https://doc.qt.io/qt-5/qmediaplayer.html#setMedia

Footgun is probably the right name for it, and a reason I don’t want to 
continue with it for Qt 6.
> 
> A potential troublemaker for sure, but also very powerful. With QtGStreamer
> being deprecated (an old set of Qt bindings to GStreamer API - also something
> at least one KDE app I'm aware of still carries an internal fork of, sadly),
> a QtMM w/ custom pipeline support sort of the next best thing.

Lets rather have a look at the use cases that people want to have supported and 
how we can get those working.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Eike Hein]

May 27, 2021 8:14 AM, "Lars Knoll"  wrote:
> The one thing I want to avoid is what we had in Qt 5, where you could force 
> Qt MM to use a
> different/custom gstreamer pipeline based on environment variables. That part 
> made maintaining the
> code base extremely hard. Other than that I’m of course open for patches and 
> improvements. If some
> integration points are needed, we can discuss those separately, but unless 
> they are trivial, they
> will probably need to wait until after 6.2.

Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the `source`
prop is getting dropped as well?

If memory serves right, this was possible accidentally at some point and then
was raised to the status of Official Footgun in 5.12+:

https://doc.qt.io/qt-5/qmediaplayer.html#setMedia

A potential troublemaker for sure, but also very powerful. With QtGStreamer
being deprecated (an old set of Qt bindings to GStreamer API - also something
at least one KDE app I'm aware of still carries an internal fork of, sadly),
a QtMM w/ custom pipeline support sort of the next best thing.



Best regards,
Eike Hein
-
KDE e.V. vice president, treasurer
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QWebEnginePage and Qt 6: protected virtual functions and signals

[Allan Sandfeld Jensen]

On Donnerstag, 27. Mai 2021 13:55:01 CEST Benjamin TERRIER wrote:
> On Thu, 27 May 2021 at 11:25, Allan Sandfeld Jensen 
> 
> But then in my code, each time I see a CrazySSLPage I am never sure that it
> will ignore SSL errors. Maybe someone called QObject::disconnect() on it.
> 
> CrazySSLPage page;
> page.disconnect(); // It's just a QWebEnginePage now

If you call disconnect on a QWebEnginePage (or most advanced Qt classes) you 
have bigger problems than that, we rely on that for internal stuff too. As a 
C++ toolkit we can not protect users from doing bad things, it is always in 
their power.


'Allan


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

Re: [Development] QWebEnginePage and Qt 6: protected virtual functions and signals

[Benjamin TERRIER]

On Thu, 27 May 2021 at 11:25, Allan Sandfeld Jensen 
wrote:

>
> I am not sure I see a significant difference. They are both compile-time.
> A
> "user" of your widget could also derive it and override the virtual
> function
> just as well as they could override your the signals?
>
>
>
No, they are not both compile-time.

With virtual functions, only subclasses that are defined at compile-time
are allowed to override.
Also, it is possible to prevent overriding using the final keyword.

With signals, the behavior can be changed at any time, including run-time,
by any part of the code.

Let's say I want a page that always ignores SSL errors.
I could do:

class CrazySSLPage final : public QWebEnginePage {
protected:
bool certificateError(const QWebEngineCertificateError &) { return
true; }
};

Then in my code, each time I see a CrazySSLPage I am sure that it will
ignore SSL errors.

With signals I could have to do:

class CrazySSLPage final : public QWebEnginePage {
public:
CrazySSLPage() {
connect(this, ::certificateErrorOccured,
[this](const QWebEngineCertificateError ) {
error.ignoreCertificateError(); });
}
};

But then in my code, each time I see a CrazySSLPage I am never sure that it
will ignore SSL errors. Maybe someone called QObject::disconnect() on it.

CrazySSLPage page;
page.disconnect(); // It's just a QWebEnginePage now
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QWebEnginePage and Qt 6: protected virtual functions and signals

[Allan Sandfeld Jensen]

On Wednesday, 26 May 2021 18:39:56 CEST Benjamin TERRIER wrote:
> Hi,
> 
> I just saw this ticket: https://bugreports.qt.io/browse/QTBUG-74587
> and this related gerrit change:
> https://codereview.qt-project.org/c/qt/qtwebengine/+/346723
> 
> I am not sure what to think about it.
> Sure it is nice to be able to customize a QWebEnginePage without deriving
> from it, but turning all protected functions
> to signal seems a bit overkill and I would think it is exposing too much.
> And it is replacing compile-time behavior with run-time behavior.
> 
> In particular, I like the ability to have my own class "MyWebEnginePage"
> with customized behavior.
> With protected functions, I can be sure that an instance of MyWebEnginePage
> will behave as expected,
> as defined at compile-time in the overridden functions. With the new API,
> it will always be possible to connect/disconnect signals
> at run-time, meaning that I have no guarantee on the behavior of a
> MyWebEnginePage.
> 
I am not sure I see a significant difference. They are both compile-time. A 
"user" of your widget could also derive it and override the virtual function 
just as well as they could override your the signals?

Best regards
'Allan


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

Re: [Development] QString, QVariant and QSQLite

[Giuseppe D'Angelo via Development]

On 26/05/2021 21:39, Alberto Mardegan wrote:


Now, I haven't dug very deep in QString and QVariant, I preferred to let
the experts talk first :-) Does the code in the QSQLite plugin look
correct to you?


That depends: when does SQLite exactly stop using the string data passed 
to it exactly?




Is it expected that QString::utf16() makes a memory allocation? And is
it correct that this happens even when the QString is const?


In the overwhelming majority of cases, utf16() won't make any 
allocation. There's just one exception -- if the QString was built via 
fromRawData(). In that case, in order to ensure NUL termination, utf16() 
does actually "detach" (even if it's a const method).


(Fun fact: utf16() is one of the few const methods in Qt value classes 
which isn't thread safe.)


It's a bit interesting that SQLite takes pointer+size, so does not seem 
to require NUL termination -- for that use case, there's 
unicode()/constData() + size(), that never reallocates (unlike utf16()).





And why destroying a const QVariant causes the deallocation of the data
created by QString::utf16()??


QString::utf16 doesn't "create" data: it modifies the string *itself* so 
that it becomes detached and NUL terminated. When you destroy that 
QString, you'll be deallocating the data (provided there are no more 
shallow copies around).


Similarly, when you destroy a QVariant, you destroy the object it's 
holding (provided there are no further shallow copies around).


So yes, in the general case, destroy QVariant -> destroy the QString 
contained -> deallocate memory.



HTH,
--
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: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt website showing template

[Tino Pyssysalo]

Hello,

The problem was a human error related to A/B testing. It was fixed yesterday 
and should not occur anymore. 
--
Tino Pyssysalo
 


On 27.5.2021, 10.23, "Development on behalf of Eike Ziller" 
 wrote:



> On May 27, 2021, at 08:28, Nibedit Dey  wrote:
> 
> Hi Qt Team,
> 
> I think the issue occurs when there is a script blocker like AdBlockPlus 
is running on the browser.
> I guess the content is loaded through a script that replaces the 
template. When the script is blocked the template appears. You need to add a 
message to disable the script blocker or add default contents on the homepage.
> 
> I don't know whether it is the right mail thread to discuss this topic. 
Can someone at Qt's website maintenance team look at the issue?

I suppose the best way of reporting the problem would be to open an issue at
https://bugreports.qt.io/projects/QTWEBSITE
with component “qt.io”

Br, Eike

> Thanks & Regards,
> Nibedit
> 
> On Thu, May 27, 2021 at 12:43 AM Nibedit Dey  
wrote:
> Hi Qt Team,
> 
> qt.io shows a template. Can you fix the link or restore the home page?
> Refer to the screenshot below:
> 
> 
> 
> Thanks & Regards,
> Nibedit
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

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

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

Re: [Development] Qt website showing template

[Eike Ziller]

> On May 27, 2021, at 08:28, Nibedit Dey  wrote:
> 
> Hi Qt Team,
> 
> I think the issue occurs when there is a script blocker like AdBlockPlus is 
> running on the browser.
> I guess the content is loaded through a script that replaces the template. 
> When the script is blocked the template appears. You need to add a message to 
> disable the script blocker or add default contents on the homepage.
> 
> I don't know whether it is the right mail thread to discuss this topic. Can 
> someone at Qt's website maintenance team look at the issue?

I suppose the best way of reporting the problem would be to open an issue at
https://bugreports.qt.io/projects/QTWEBSITE
with component “qt.io”

Br, Eike

> Thanks & Regards,
> Nibedit
> 
> On Thu, May 27, 2021 at 12:43 AM Nibedit Dey  wrote:
> Hi Qt Team,
> 
> qt.io shows a template. Can you fix the link or restore the home page?
> Refer to the screenshot below:
> 
> 
> 
> Thanks & Regards,
> Nibedit
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 26 May 2021, at 17:30, Eike Hein  wrote:
> 
> Exciting!
> 
> Are there any plans to officially support the GStreamer backend on Android 
> down the line (with building GStreamer as an acceptable exercise left to the 
> user) or would work in that direction be appreciated by the module maintainer?

I don’t think I want to officially support it right now, but build fixes to 
make it work and selectable on Android are welcome.
> 
> At KDE, we have a couple of apps that use GStreamer API directly in 
> conjunction with gst-qmlsink, as GStreamer enables some advanced pipelines 
> not functionally supported by Android's native media framework (e.g. RTP 
> without RTSP). Naturally, using Qt Multimedia is far more ergonomic than 
> mixing GStreamer's C API into the code, however.

The one thing I want to avoid is what we had in Qt 5, where you could force Qt 
MM to use a different/custom gstreamer pipeline based on environment variables. 
That part made maintaining the code base extremely hard. Other than that I’m of 
course open for patches and improvements. If some integration points are 
needed, we can discuss those separately, but unless they are trivial, they will 
probably need to wait until after 6.2.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

On 26 May 2021, at 21:00, Arnaud Vrac 
mailto:raw...@gmail.com>> wrote:

Le mer. 26 mai 2021 à 14:11, Lars Knoll 
mailto:lars.kn...@qt.io>> a écrit :
[snip]

Hi Lars,

Thanks for the updates. One feature that I've always waited for is the
possibility to list and select audio/subtitle tracks from qml. Now
that the feature is implemented in C++, it seems not much would be
missing to also support this officially in QML. Is this planned ?

The plan is to support everything we have on the C++ side for QML as well. All 
that’s missing right to get this working is actually a test case written in QML 
and adding a couple of Q_PROPERTY declarations in QMediaPlayer.

Cheers,
Lars

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

Re: [Development] New Qt Multimedia

[Lars Knoll]

> On 26 May 2021, at 18:14, Jason H  wrote:
> 
>>> 4. On the removal of QAbstractVideoFilter AND QVideoProbe: Disappointed to 
>>> hear this. I previously used this for read-only frames for analysis, i.e. 
>>> Barcode reading and object detection. How do we do that now?
>> 
>> You can get full access to the video data from a QVideoSink through the 
>> newVideoFrame() signal and mapping the video frame (or converting it to a 
>> QImage). With that you should have the access to the data that you need. (A 
>> small detail that’s still missing right now but that I hope to have in place 
>> for 6.2 is the ability to connect several sinks to a media player or capture 
>> session, but it’s not really required as you can connect several slots to 
>> the signal). If you feel like to need more than that, let me know what it is.
> 
> So the most common case I need supported is getting the video frame for 
> processing while maintaining the full-speed live preview. Is this the 
> multi-sink scenario?

You can work with one sink by connecting to it’s newVideoFrame() signal. The 
only thing that’s a bit more cumbersome in that case it how to get to the video 
sink, but neither that should be  large problem.

Multiple sinks are mainly required to be able to support multiple video output 
surfaces in a generic way on the framework level.

> Typically, With Camera connected o a VideoOutput, I use QVideoProbe to throw 
> the frame (pixel data as QByteArray, because the library doesn't care) to a 
> thread for multicore async processing. A typical 1 megapixel image on 
> RaspberryPi4 takes ~150ms using ZBar or ZXing (I find ZXing is more like 
> 100ms), so this gets about 6 processed frames a second, which seems 
> responsive enough to the user because they are looking at the live display.
> 
> Since you asked for actual code, attached is the code I use to do this. It 
> may not be perfect code (long story made short, I just rewrote this from 
> memory) but it is what I whipped up, and works reasonably well for now.  I've 
> used this approach for barcodes and OpenCV.
> 
> If it matters: I disclaim any copyright for the attached 
> files.

Thanks for the snippet. I think this should be perfectly doable. Connect to the 
signal, then map the QVideoFrame and copy out the Y channel.

Cheers,
Lars

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