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

[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] New Qt Multimedia

[Eike Hein]

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?

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.


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

Re: [Development] Commercial LTS Qt 5.15.4 released

[Eike Hein]

May 13, 2021 10:29 PM, "Lorn Potter"  wrote:

> On 13/5/21 8:00 PM, Kevin Kofler via Development wrote:
> 
>> KDE is maintaining their own 5.15 branches, e.g.:
>> https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15
> 
> I'm not kde developer, but I am sure kde has almost always had their own
> fork of Qt.

Nope.

We used to have a tree of Qt known as 'qt-copy' in the pre-Nokia days, as it 
was very difficult to submit patches into Qt at the time. This was often the 
version of Qt you got from Linux distros back then.

We dropped qt-copy quickly when Qt started having public repositories, a 
working contribution path and Qt Open Governance. In fact, we loved this so 
much that we also started upstreaming tens of thousands of kdelibs sloc or 
equivalent features and API concepts into Qt 4/5 (e.g. QStandardPaths, lots of 
things in QLocale and QAction, ...). Since then there's no KApplication anymore 
- just a plain old QApplication.

I'm also not sure the patch collection against 5.15.2 really qualifies as a 
_fork_ in the traditional sense. It's not diverging from a public branch we 
could contribute to instead. At least it's not more of a fork than the (hidden) 
LTS branch is.


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

Re: [Development] Commercial LTS Qt 5.15.4 released

[Eike Hein]

May 13, 2021 9:59 PM, "Oswald Buddenhagen"  wrote:
> what would interest me is why you chose to host this on your own
> infrastructure instead of publicly demanding that tqtc plays by the
> rules and hosts the fork on qt project infra, where it belongs, and the
> possibility of which is explicitly codified in
> https://wiki.qt.io/Branch_Guidelines (note the historical example
> given).


Actually, we did not.

We suggested that it would be preferential to host this on Qt Project 
infrastructure. In fact, our leading suggestion was to re-open the branches as 
per usual and simply don't do the tags/releases.

We could not agree on it.


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

Re: [Development] Commercial LTS Qt 5.15.4 released

[Eike Hein]

May 13, 2021 4:42 PM, "NIkolai Marchenko"  wrote:

> The problem with kde maintaining this is that people who are switching to 
> newer qt versions can no
> longer expect fixes done to this branch to exist in the newer qt. So bugs 
> that have been closed by
> the community may reappear again in actual Qt as TQTC deems them irrelevant.

No, this is not the case.

The policy for our Qt tree is to only merge patches that have been reviewed and 
approved upstream first. It's a collection of backports of relevant patches 
that can demonstrate they affect an open source product (KDE or otherwise). 
We're not interested in promoting further divergence, compromising the upstream 
open source Qt project or, for that matter, driving the CLA/non-CLA issue as a 
wedge between the two codebases.

The main awkward gap there is hypothetical patches that are relevant for 5.15.x 
but, for technical reasons, cannot be approved and merged into Qt 6.x. We would 
still only add them after they've gotten a review and approval on Gerrit, 
whether they're merged to the tree we cannot see or not.

To make this work in general we were in a conversation with the Qt Company 
before announcing the tree, to let them know that this is happening and why, 
and so the Qt Company could confirm it would be doing the patch reviews to make 
this work.

Once Qt releases the commercial-only 5.15.x releases as open source (the KDE 
FreeQt Foundation agreement gives up to 12 months to do this) the patches in 
the KDE tree will be rebased onto them.

To be clear, purely in terms of convenience, we would prefer if the 5.15.x LTS 
releases were not commercial-only and this additional effort was not necessary, 
as it's a distraction from producing value for our end-users. Obviously it's 
not ideal that an open source developer caring for their end-users cannot 
produce a Qt bugfix and bring it all the way to them via an official Qt release 
and the standard distribution channels at the moment. So we're not going to do 
anything that will make it more difficult to return to source code parity 
between the editions, either, as that would be in conflict with this view.

I think it's everyone's collective expectation that this will all calm down a 
bit in practice once the ecosystem moves onto 6.x, as the next 6.x+1 release 
should generally be available before 6.x.y point releases flip into a 
commercial-only mode (keep in mind the initial 6.x.y is still open source, not 
_all_ point releases are implicitly LTS). Provided the QA is up to snuff and 
extra-patch-necessary is rare that will likely be an acceptable rhythm, as 
distros have always balanced the scale on "do we bump or backport this one key 
patch" situationally.



Best regards,
Eike Hein
-
KDE, Plasma hacker
KDE e.V. Vice President
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting a repository for Lottie-Qt implementation

[Eike Hein]

Hi,

we've written one of those at KDE recently:

https://github.com/kbroulik/lottie-qml

We also submitted some patches to both Qt and Lottie to make it work
better.

Ours is LGPLv2+ as usual, FWIW.



Cheers,
Eike

On 1/9/19 11:23 PM, Tuukka Turunen wrote:
>  
> 
> Hi,
> 
>  
> 
> I would like to request for a new repository:
> 
>  
> 
> Name of the repository: qt/qtlottie.git
> 
> Description: Lottie-Qt, a renderer for Bodymovin animations
> 
> Responsible person: Eirik Aavitsland
> 
> Gerrit user/email: eirik.aavitsl...@qt.io 
> 
>  
> 
> Lottie is a family of player software for a certain json-based  file
> format for describing 2d vector graphics animations. These files are
> created/exported directly from After Effects by a plugin called Bodymovin.
> 
>  
> 
> About Lottie: https://airbnb.design/lottie/
> 
>  
> 
> Intention is to create a Qt based player for these animations and
> license it under GLPv3 and commercial licenses.
> 
>  
> 
> Yours,
> 
>  
> 
>     Tuukka
> 
> 
> ___
> 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] Deprecation of Qt Quick Controls 1

[Eike Hein]

Hi,

in addition, kde.org ships a qqc2-desktop-style for Controls 2 that
implements QStyle theming (it's an improved derivative of the code
used in qqc1) and has no other KDE dependencies. It's viable to ship
with an app, and available in most distributions as a system package
as well as inside KDE's Flatpak runtime. It's not been tested much
outside of X11, Wayland and win32, though.

We've mostly transitioned to qqc2 even for desktoppy things on the
back of this style, modulo some remaining gripes with the qqc2
combobox, IIRC.

(We've had a talk about upstreaming this work but it stalled a while
back.)


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

Re: [Development] QtQuickControls for desktop: what's the plan?

[Eike Hein]

On 11/11/2016 05:02 PM, Alberto Mardegan wrote:
> If QStyle is used by QWidgets, which have been used in apps since well
> before QML existed, it's reasonable to expect that its performance is
> more than acceptable for modern desktop machines.

Not necessarily. This isn't about native QStyle painting, it's about
QStyle going through Qt Quick's rendering stack, which involves
additional indirection.


> Maybe we might have to give up on the idea of a single implementation,
> and instead have a different style for each toolkit? At least with Gtk,
> it might be possible to use native Gtk widgets, as we are already using
> the glib mainloop in Linux, and GtkWidgets allow for offscreen drawing...
> That sounds like a lot of work :-)

That's more or less what QGtkStyle does.


> Ciao,
>   Alberto

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

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

[Eike Hein]

On 07/16/2015 03:02 PM, Helio Chissini de Castro wrote:
 Hello Takao
 
 You're talking over Qt 4 only or Qt 5 is affected as well ?
 This is a full replacement of the plugin ?

The Qt 4 plugin was never in the Qt source tree (afaik).

The Qt 5 plugin is, and this is upstream asking for it to
be factored out and handed over to ibus.

As a contributor to the plugin (and ibus itself with a
minor patch at some point) I'd be fine with either. I'm
guessing it needs to sync to ibus changes more often than
to Qt changes, so ibus hosting might make sense.


 Regards, Helio

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

Re: [Development] Qt preference font

[Eike Hein]

On 05/13/2015 07:57 PM, Alex Vazquez wrote:
 Is there any way to make a list of preferences font in Qt.

Yes, QFont:insertSubstitution  co allow you to assemble a QFont
with a particular substitution chain for glyphs. This is basically
what e.g. a browser engine built on Qt maps a CSS font families
listing to.

On the fontconfig level, it can be done similarly via alias+prefer
blocks in fonts.conf. Unfortunately, current Linux desktops don't
expose this capability in UI (because it's quite tough to build a
user-digestible and goals-focused interface around it without
leaking the corner cases); that's an area of active research in
KDE Plasma. Distros however make heavy use of this in their system
level default config to mix in the highest-quality non-Latin fonts
into whatever they map the generic family names like serif and
sans-serif to.


 Thanks!
 Regards!

Cheers,
Eike Hein, KDE.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development