Commit Graph

6 Commits

Author SHA1 Message Date
Lucie Gérard
05fc3aef53 Use SPDX license identifiers
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.

Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-16 16:37:38 +02:00
Jani Heikkinen
f776595cc1 Updated license headers
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/

Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)

Change-Id: I42a473ddc97101492a60b9287d90979d9eb35ae1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
2016-01-21 18:55:18 +00:00
Jani Heikkinen
83a5694dc2 Update copyright headers
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.

Outdated header.LGPL removed (use header.LGPL21 instead)

Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)

Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination

Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
2015-02-11 06:49:51 +00:00
Matti Paaso
974c210835 Update license headers and add new license files
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL

Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
2014-09-24 12:26:19 +02:00
Jędrzej Nowacki
71d265f592 Add missing header guards
Change-Id: I515313289c0a4af0f675131760ad4ccd0c6e6149
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2014-01-20 17:08:24 +01:00
Simon Hausmann
54f0733e7d Fix erroneous exclusion of classes from related meta objects in moc
Assume an unrelated class that declares an enum and uses Q_ENUMS. Consider
then a class that uses UnrelatedClass::Enum as a Q_PROPERTY. We used to
include UnrelatedClass in the primary class's related meta objects, in order
to support use-cases like
    obj->setProperty("enumProperty", "ValueOfEnumAsString");

If however moc happens to see Q_DECLARE_METATYPE(UnrelatedClass::Enum), then it
would exclude it from the related meta objects, which would silently break the
string based enum value conversion. This was meant as an optimization, but it
isn't apparent to the developer why sometimes the string conversion would
work and sometimes not (depending on whether somebody declares that macro).
This also becomes visible in QML, which relies on the same embedded type
information for enum assignments.

This patch removes that check in moc's code generator and cleans up the code a
little. However always including the prefix of Q_PROPERTY(SomePrefix::Enum ...)
is not correct either, because it may be that SomePrefix is a namespace, which
would cause compilation issues. Therefore we limit the inclusion of related
meta objects only to Q_OBJECT decorated classes the moc has seen, and for these
we save the fully qualified name in the related meta objects array (for QTBUG-2151).

While this patch makes the previous workaround for namespace issues by using a
Q_DECLARE_METATYPE not workable anymore, by saving the fully qualified name we
are making a hopefully sufficient effort to not require a workaround in the
first place. There's always the new workaround of fully qualifying the type in
Q_PROPERTY.

One side-effect of this change is that in the autoPropertyMetaTypeRegistration
test of tst_moc, the CustomQObject for Q_PROPERTY(CustomQObject::Number
enumValue ...) is now a related meta object, and therefore when querying for
the type of this property via QMetaProperty::userType(), we are now aware of
this being an enum and try to resolve CustomQObject::Number via
QMetaType::type(qualfiedName). As there is no guarantee for this to succeed, we
must now also do what is done in the non-enum code path in ::userType(), which
is to call the moc generated type registration function.

Task-number: QTBUG-33577
Task-number: QTBUG-2151
Change-Id: Ibf20e7421cba464c558a25c76a7e1eef002c6cff
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2013-12-12 22:57:19 +01:00