Hi,
There are many add-ons that work perfectly well on mobile. Essentials should be
such that are as the name suggest essential for the Qt based applications (or
devices). Furthermore, the essentials need to work on all platforms. This means
also the embedded and RTOS platforms, not only desktop and mobile.
Yours,
Tuukka
On 22.5.2020, 17.20, "Development on behalf of Jason H"
<[email protected] on behalf of [email protected]> wrote:
Will this have repercussions in the Maintenance tool?
I don't really think that calling Multimedia an "add on" is a reflection of
reality, post 1994.
For mobile kits (iOS, Android) these are essential features. Sorry, Qt just
can't get away with drawing rectangles and text in 2020. I fear this is more
maligning of mobile by Lars. I think this will result in providing a lower tier
of service than compared to the "essentials".
I object, and wish multimedia to remain an essential part of Qt.
> Sent: Friday, May 22, 2020 at 3:47 AM
> From: "Lars Knoll" <[email protected]>
> To: "Giuseppe D'Angelo" <[email protected]>
> Cc: "Qt development mailing list" <[email protected]>
> Subject: Re: [Development] Qt Multimedia as Add-on in Qt 6
>
> Hi,
>
> > On 21 May 2020, at 18:08, Giuseppe D'Angelo via Development
<[email protected]> wrote:
> >
> > Hi,
> >
> > Il 21/05/20 11:38, Val Doroshchuk ha scritto:
> >> The license is not changed, plans just to not ship QtMultimedia with
Qt essentials,
> >> can be installed separately. Possibly we also support only a limited
set of platforms.
> >> Qt Essentials must work on every platform, according to the definition
of essentials.
> >
> > While of course it's up to each module maintainer to decide on its
status (and thus, if QtMM doesn't qualify for "Essentials" any more, can become
an "Addon"), I'm left wondering why does this imply being moved to the
Marketplace, out of Qt itself?
> >
> >
> > * Is this part of a broader plan, aiming at streamlining the Qt offer
to just mean Essentials, while the Addons get moved to the marketplace?
>
> This is something I’ve been at least mentioning at the Contributor Summit
already. Distributing it through the market place is mainly a different means
of packaging it and decoupling the release schedules. A user should still be
able to discover and install Qt MM (or other add-ons delivered through the
market place) in the installer, just as today.
>
> But yes, this goes then towards streamlining Qt 6 a bit. Reducing the set
of things that you have to install, and making more modules optional.
> >
> > ("Qt offer" is of course inaccurate, given the many offers available,
but you get my drift...).
> >
> >
> > * If so, are all the practical issues for such addons sorted out? First
few things that come to mind:
> >
> > 1) Version numbering scheme, release schedule
>
> This needs some sorting out, I agree.
>
> > 2) CI testing / platform coverage
>
> That should be ok for now, although if an add-on targets several Qt
versions at once, we don’t yet have a good mechanism to deal with that in CI.
>
> > 3) Compatibility promise (own API/ABI stability, which Qt versions it
works with, etc.)
>
> I think it will be good to give add-ons a bit more flexibility there how
to handle it. This is because different add-ons have rather different
requirements, that we’ve so long all tried to shoehorn into the Qt release
process. Compare for example WebEngine that needs frequent updates due to new
Chromium releases with e.g. Qt SVG that only receives a very limited amount of
bug fixes.
>
> > 4) Where to put the docs, release notes, etc.
>
> Into the package and on the web site as usual.
> >
> >
> > * What about the KDE/Qt agreement? Are the list of Essential and Addon
modules being re-evaluated there as well? QtMM is not really at liberty of
changing license because it's an "Essential" (in the agreement).
>
> There’s the agreements legal term, and the status in terms of the
agreement is something we can’t change without agreement from the board of the
KDE Free Qt Foundation.
>
> When the new agreement was done some years ago, we tried to align terms
with what we had in Qt Project at that time. But things do change and I believe
we can change what we see as essential and add-on in terms of the project (and
in the commercial packages) independently of the agreement.
>
> This is confusing to some extent as the legal agreement uses the same
terms as we’re using, but the terms are defined in the agreement itself, and
limited to the scope of the agreement. They don’t dictate how we package or
name things in our releases (as long as the conditions set forth in the
agreement are fulfilled).
>
> The main thing the agreement mandates is the licensing of add-on and
essential modules. But the only real difference between add-ons and essentials
(as defined in the agreement) are that essentials have to be LGPLv3, while
*new* add-ons can be GPLv3. We can’t change licensing of currently supported
modules without agreement from the foundation in neither case. We also can’t
reduce the scope of the agreement, so Qt Multimedia will be part of that
agreement no matter how we package and deliver it to our users.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> [email protected]
> https://lists.qt-project.org/listinfo/development
>
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
