Yes, native interfaces have been considered as an option.
One reason for having gstreamer classes is qml demand for the case  (80-90%), 
native interfaces require extra job on the user-side, and we're providing a 
solution easy-to-use in qml (public qml API) and C++ (semi-public).
Another reason is that these gstreamer things are not necessary "native 
interface" for existing components. E.g. QGStreamerVideoSource is rather a new 
component than a QCamera extension.

BR
Artem

Confidential
________________________________
From: Tor Arne Vestbø <[email protected]>
Sent: Thursday, May 21, 2026 12:03 PM
To: Artem Dyomin <[email protected]>
Cc: Qt development mailing list <[email protected]>
Subject: Re: [Development] Semi-private headers in Qt

Have you considered whether the GStreamer functionality can be exposed as 
native interface extension to existing classes?

https://doc.qt.io/qt-6/native-interfaces.html

Or are you building a completely non-cross-platform and distinct API surface 
for GStramer only in Qt?

Tor Arne

On 21 May 2026, at 11:07, Artem Dyomin via Development 
<[email protected]> wrote:

In Qt, we have semi-private functionality for rhi, qpa, ssg, that contain a 
disclaimer in headers and docs limiting SC and BC guarantees, and requiring to 
link the private part of the module. The headers are deployed as 
<QtGui/rhi/qrhi.h> etc.
We want to add similar headers for Multimedia with GStreamer functionality. A 
good idea is having a good name for this kind of API (e.g. experimental) and 
deploy the headers as <QtModule/experimental/qheader.h>.
The current plan is deploying new gstreamer-related headers under the new name, 
and then consider transferring existing headers to the new approach (with 
keeping old ones).

In my view, the term "experimental" is the best as the term "experimental" in 
C++ highly correlates with how Qt declares it in terms of SC and BC.
A discussion has been started in the CR adding "experimental".
https://codereview.qt-project.org/c/qt/qtbase/+/736307

Other proposals are "semiprivate", "nocompat", "unstable" or similar.

Are you agreed that <QtModule/experimental/qheader.h> works fine for these 
semi-private headers?


Confidential
--
Development mailing list
[email protected]<mailto:[email protected]>
https://lists.qt-project.org/listinfo/development

-- 
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development

Reply via email to