[Development] Qt Multimedia as Add-on in Qt 6
ekke at ekkes-corner.org
Fri May 22 16:59:23 CEST 2020
esp Camera is essential for mobile apps
but if it's integrated smooth into the Installer and I have only to
check one additional checkbox then it would be ok for me to get it from
Am 22.05.20 um 16:16 schrieb Jason H:
> 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" <lars.knoll at qt.io>
>> To: "Giuseppe D'Angelo" <giuseppe.dangelo at kdab.com>
>> Cc: "Qt development mailing list" <development at qt-project.org>
>> Subject: Re: [Development] Qt Multimedia as Add-on in Qt 6
>>> On 21 May 2020, at 18:08, Giuseppe D'Angelo via Development <development at qt-project.org> wrote:
>>> 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.
>> Development mailing list
>> Development at qt-project.org
> Development mailing list
> Development at qt-project.org
More information about the Development