summaryrefslogtreecommitdiffstats
path: root/src/corelib/doc
Commit message (Collapse)AuthorAgeFilesLines
...
* QList docs: remove some QVector->QList leftoversGiuseppe D'Angelo2020-10-191-17/+0
| | | | | Change-Id: I2a7b5ef07ddb07a261110914088b9942801a3c25 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Generalize the winmain/qtmain entry-point libraryTor Arne Vestbø2020-10-171-1/+1
| | | | | | | | | | The use-case is relevant for other platforms as well. Now that Qt has a module system we can also replace a lot of the hand crafted logic for linking with simpler constructs. Change-Id: Ib6853aaf81bfea79c31f2de741d65b4b56f23ef6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Document noteworthy change in QProcessVolker Hilsheimer2020-10-161-0/+31
| | | | | Change-Id: I4d9769901aef8255fc111f33eb141e05398f0ee3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Doc: Migration Guide for QString related changesKarsten Heimrich2020-10-151-0/+84
| | | | | | Task-number: QTBUG-87097 Change-Id: Idcdeaea5a65e91b99a08c2af03c7e76bbe5913bb Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Add porting section for QtConcurrent and related classesSona Kurazyan2020-10-091-0/+70
| | | | | | | | Task-number: QTBUG-87096 Change-Id: Ie143db6c0d1e81f7a089799996d468360c44e2ca Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: Do not use versionless targets in examples (Qt Core)Kai Koehne2020-10-092-6/+6
| | | | | | | | This is confusing, especially because it's not used in the whole snippet. Pick-to: 5.15 Change-Id: Ibd59646da2c77ac19a38441021c5e99f52015c95 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Another round of replacing 0 with nullptrAllan Sandfeld Jensen2020-10-076-7/+7
| | | | | | | | | This time based on grepping to also include documentation, tests and examples previously missed by the automatic tool. Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Add porting section for QVector/QListAndrei Golubev2020-10-071-0/+89
| | | | | | | Fixes: QTBUG-87099 Change-Id: If8ace4f77a4d9fa3dbb24204696e2f7602a76692 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QREMatchIterator: add support for range-based forGiuseppe D'Angelo2020-09-301-0/+9
| | | | | | | | | | | | | Add begin()/end() on QRegularExpressionMatchIterator, making iterators over an iterator (like directory_iterator). [ChangeLog][QtCore][QRegularExpression] The iterator object (QRegularExpressionMatchIterator) returned by a global match is now usable in a range-based for loop. Change-Id: If3d31bd2e84e7d1fb626a0b3d2745914dff03e39 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Fix incorrectly placed closing bracket in Q_PROPERTY codeKai Koehne2020-09-301-2/+2
| | | | | | | | Amends cb3152086c61e7c Pick-to: 5.15 Change-Id: I1615a686a53da7ca5ae454565283c9e83399d947 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* doc: Make QtCore depend on all modulesMartin Smith2020-09-291-1/+3
| | | | | | | | | | | | | | | Class QObject is the most widely used base class in Qt. It is inherited by a great many Qt classes.This update sets the depends variable in qtcore.qdocconf to '*' so that QDoc will load all the index files for all of Qt, when it generates the documentation for QtCore. In particular, this will ensure that the "Inherited By" list for class QObject will show all the Qt classes that inherit QObject. Pick-to: 5.15 Task-number: QTBUG-77126 Change-Id: I5f38400ccc798ec34e2ee80472f1fe9bb7b1877d Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Remove traces of QObject::trUtf8 from documentationVolker Hilsheimer2020-09-252-3/+1
| | | | | | | | ... and from the duplicated Q_DECLARE_TR_FUNCTION macro for QXmlStream. We expect source code to be utf8 encoded in Qt 6, so the function is gone. Change-Id: Ie25329a54e709dc92a22893ad5ab023852300d81 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Doc: Update CMake snippets to Qt 6Kai Koehne2020-09-251-2/+2
| | | | | | | Change-Id: I53021781a25c141db5d5fc6771192cd8d6ed732a Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Fix some qdoc warnings from QByteArrayVolker Hilsheimer2020-09-231-1/+1
| | | | | | | | A snippet bug, and removed overloads. Change-Id: I82aee3627ba1a4e75e392b28d8ec72d470c395db Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Documentation: purge QSet and QHash members that no longer existVolker Hilsheimer2020-09-231-9/+0
| | | | | | | | | | | | QMutableSet/HashIterator can not walk backwards, neither can the STL iterator. When function documentation was shared with other iterator types, move it into separate section to avoid linking to incorrect see-alsos. Remove or fix other member function documentation that had errors, e.g. in parameter types after move to qsizetype. Change-Id: Ic7f97a295eff63ee748998b10f08a160706fa650 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Doc: Correct link errors qtbaseNico Vertriest2020-09-211-1/+1
| | | | | | Task-number: QTBUG-86295 Change-Id: I27f6bbdadffb08a8794520a14dfe0e2334979575 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Q(Any|Utf8)StringView: move array size deduction feature to fromArrayMårten Nordheim2020-09-183-11/+2
| | | | | | | | | | | | | The constructor taking an array literal will now stop at the first null-terminator encountered. And fromArray is introduced which only supports array literals. Constructs a view of the full size. Explicit so it shouldn't be surprising. Change-Id: I1497c33a5c12453a95e87c990abe6335b2817081 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QByteArrayView: move array size deduction feature to fromArrayMårten Nordheim2020-09-181-7/+0
| | | | | | | | | | | | | | | | 1. Make the ctor unable to construct a QByteArrayView from array literals other than 'char'. With the new behavior it would either be (very likely) unintended to pass e.g. a std::byte array to the ctor. And it would be confusing because you would get different sizes based on signed-ness. 2. Introduce fromArray Only supports array literals. Constructs a view of the full size. Explicit so it shouldn't be surprising. Change-Id: Ifdb55eb21057dfe7053b2561bd81e2c9825e9bc6 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Doc: Add porting guide documentsPaul Wicking2020-09-161-0/+2
| | | | | | | | Also add existing such docs to the new document group Task-number: QTBUG-84051 Change-Id: I76f033f0846e09943f249d2beeb1606869eef382 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Make QStringList an alias to QList<QString>Lars Knoll2020-09-121-1/+0
| | | | | | | | | | | | | | | | | | Fix our API, so that QStringList and QList<QString> are the same thing. This required a bit of refactoring in QList and moving the indexOf(), lastIndexOf() and contains() method into QListSpecialMethods. In addition, we need to ensure that the QStringList(const QString&) constructor is still available for compatibility with Qt 5. Once those two are done, all methods in QStringList can be moved into QListSpecialMethods<QString>. Change-Id: Ib8afbf5b6d9df4d0d47051252233506f62335fa3 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Introduce QProcess::startCommand(QString, OpenMode)Joerg Bornemann2020-09-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The removal of the QProcess::start(QString, OpenMode) leads to more porting work than anticipated. A call like QProcess p; p.start(cmdline); must be transformed in the following cumbersome way: QProcess p; QStringList args = QProcess::splitCommand(cmdline); QString program = args.takeFirst(); p.start(program, args); This patch revives QProcess::start(QString, OpenMode) and renames it to QProcess::startCommand. This is still source-incompatible, but the transformation is much simpler: QProcess p; p.startCommand(cmdline); [ChangeLog][QtCore][QProcess] Added QProcess::startCommand(QString, OpenMode) as replacement for the removed QProcess::start(QString, OpenMode). Change-Id: I5499bbb39a025e115042c43a4cc63affddae585c Reviewed-by: hjk <hjk@qt.io>
* Doc: clean up the QProcess::setChildProcessModifier exampleThiago Macieira2020-09-101-3/+3
| | | | | | | | | | - Use nullptr instead of 0 - Pass directory to chroot that is not in /etc - Set umask to a sensible value (0 is insecure) Change-Id: I1dba29bc0f454df09ca1fffd161801257f9ccb3c Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QProcess/Unix: introduce setChildProcessModifier()Thiago Macieira2020-09-081-20/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ChangeLog][Source-Incompatible Changes] QProcess::setupChildProcess() was removed. To execute code in a child process, use QProcess::setChildProcessModifier() [ChangeLog][QtCore][QProcess] Added setChildProcessModifier() function with which one can provide code to be run in the Unix child process between fork() and execve(). With this function, it is no longer necessary to derive from QProcess in order to execute actions in the child process. Another reason is that we can tell whether the std::function carries a valid target much more easily than we can tell whether QProcess was overridden. The setupChildProcess() virtual function does not need to be marked final, since no overrider could ever return an inaccessible private class. This also makes sure the error presented to the user is about the return type, not about attempting to override a final. Clang: error: virtual function 'f' has a different return type ('void') than the function it overrides (which has return type 'QProcess::Use_setChildProcessModifier_Instead') GCC: error: conflicting return type specified for 'virtual void MyProcess::setupChildProcess()' note: overridden function is 'virtual QProcess::Use_setChildProcessModifier_Instead QProcess::setupChildProcess()' ICC: error: return type is neither identical to nor covariant with return type "QProcess::Use_setChildProcessModifier_Instead" of overridden virtual function "QProcess::setupChildProcess" MSVC is not relevant since it doesn't compile to Unix. Change-Id: Ia8b65350cd5d49debca9fffd15f801161363aea7 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Clean up the QByteArray API and implementationLars Knoll2020-09-031-1/+1
| | | | | | | | | | | | | | Add overloads using a QByteArrayView where it makes sense, and call those inline from the other overloads. Remove overloads that are not required anymore (due to implicit conversion of a const char * to a QByteArrayView). Guard all implementations against passing this object to them. Change-Id: I930156f8b05ce72c32cb8201c70513f2e6e19d3e Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Long live QAIM::multiData!Giuseppe D'Angelo2020-09-021-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Views / delegates absolutely *adore* hammering data(). A simple QListView showing a couple of dozens entries can call data() a hundred of times on the first show. Back of the hand calculation, * 2 times per visible item (sizeHint() + paint()), * times 9 roles used by the default delegate, * times 20 visible items = 360 as a bare minimum, assuming the view doesn't redraw twice accidentally. Move the mouse over the view, and that'll cause a full update with certain styles: 360 calls to data() per update. This has an overhead visible in profilers. The model's data() has to re-fetch the index from its data structure and extract the requested field every time. Also, QVariant is used for the data interexchange, meaning anything that won't fit in one is also a memory allocation. This problem will likely be gone in Qt6Variant as that will store sizeof(void*) * 3, meaning QImage/QPixmap and similar polymorphic classes will fit in a QVariant now... So I'm trying to to remove part of that overhead by allowing views to request all the data they need in one go. For now, one index a a time. A view might also store the data returned. The idea is that the same role on different indexes will _very likely_ return variants of the same type. So a model could move-assign the data into the variant, avoiding the memory allocation /deallocation for the variant's private. This patch: 1) Introduces QModelRoleData as a holder for role+data. 2) Introduces QModelRoleDataSpan as a span over QModelRoleData. The idea of a span type is twofold. First and foremost, we are in no position to choose which kind of container a view should use to store the QModelRoleData objects for a multiData() call; a span abstracts any contiguous sequence, leaving the view free to do whatever it wants (statically allocate, use a vector, etc.). It also solves the problem of efficient passing the roles and gathering the returned variants from multiData(). 3) Add multiData(), which populates a span of roles for a given model index. The main advantage here is that a model can fetch all the needed information for a given index just once, then iterate on the span and provide data for each requested role. Cf. this with data(), where every call has to re-fetch the information for the index. A couple of models have been ported to multiData(), as well as QStyledItemDelegate. [ChangeLog][QtCore][QModelRoleData] New class. [ChangeLog][QtCore][QModelRoleDataSpan] New class. [ChangeLog][QtCore][QAbstractItemModel] Added the multiData() function. Change-Id: Icce0d108ad4e156c9fb05c83ce6df5f58f99f118 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Long live Q{Any,Utf8}StringView!Marc Mutz2020-08-312-0/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to add these two classes at the same time, because QAnyStringView makes all QUtf8StringView relational operators moot. We might want to add some later, esp. for UTF-8/UTf-8 comparisons, to avoid the pessimization that we can't early-out on size() mismatch in QAnyStringView equality operators, but that's an optimization, not a correctness issue, and can be fixed in a source-compatible way even after Qt 6 is released. To deal with the char8_t problem in C++20, make QUtf8StringView a class template out of which two UTF-8 views can be instantiated: the Qt 7 version, which depends on C++20 char8_t as value_type, and the Qt 6 version where value_type is a char. Use inline namespaces to map the QUtf8StringView identifier to one or the other, depending on the C++ version used to compile the user code. The inline namespace names must needs be a bit ugly, as their inline'ness depends on __cpp_char8_t. If we simply used q_v1/q_v2 we'd be blocking these names for Qt inline namespaces forever, because it's likely that inline'ness of other users of inline namespaces in Qt depends on things other than __cpp_char8_t. While inline'ness of namespaces is, theoretically speaking, a compile-time-only property, at least Clang warns about mixed use of inline on a given namespace, so we need to bite the bullet here. This is also the reason for the QT_BEGIN_..._NAMESPACE macros: GCC is ok with the first declaration making a namespace inline, while Clang warns upon re-opening an inline namespace as a non-inline one. [ChangeLog][QtCore][QUtf8StringView] New class. [ChangeLog][QtCore][QAnyStringView] New class. Change-Id: Ia7179760fca0e0b67d52f5accb0a62e389b17913 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Move QStateMachine from QtCore to QtScxmlKarsten Heimrich2020-08-2418-1343/+0
| | | | | | Task-number: QTBUG-80316 Change-Id: I2ee74110fd55e94d86321d3b3dc5bb8297424ed4 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
* QLocale: Fix double conversion snippetAndre Hartmann2020-08-241-19/+19
| | | | | | | | | | | | | * QString("1234,56").toDouble(&ok); always operates in the "C" locale and therefore ok is always false * Explicitly state that the return value is zero when ok is set to false * Made snippet compileable by giving str a type Pick-to: 5.15 Change-Id: I403eb39ca78a5f9ceb92ccd8ac3539581294796c Reviewed-by: Sze Howe Koh <szehowe.koh@gmail.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Doc: provide a code example of QDirIterator's nameFilters parameterMitch Curtis2020-08-241-0/+4
| | | | | | Change-Id: I56f9251f17bab0f835979a5feadec1fa896c9d69 Pick-to: 5.15 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Automatically register data/debug stream operations in QMetaTypeLars Knoll2020-08-241-5/+0
| | | | | | | | | | | | | | | | | | | | | | And remove the old manual registration code for those operators. Add some special handling for long/ulong, as these types could be streamed as a QVariant so far, but are not directly streamable through QDataStream. [ChangeLog][QtCore][QMetaType] The QMetaType::registerStreamOperators() and QMetaType::registerDebugStreamOperator() methods have been removed. The streaming operators for a type are now automatically registered together with the type registration. This implies that the operators should be visible wherever the type is visible and being used. [ChangeLog][Behavior Incompatible Changes] Because the QDataStream and QDebug serialization operators are automatically registered with QMetaType, the declarations of those functions must be present at any point where the type is used with QMetaType and QVariant. Change-Id: I4a0732651b20319af4a8397ff90b848ca4580d99 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Doc: Use https in links that don't redirect properlyPaul Wicking2020-08-201-2/+2
| | | | | Change-Id: If9f28851e8df6ed488590d06db8c0791214c4a95 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Move QStringRef and remains to Qt5CompatKarsten Heimrich2020-08-202-29/+1
| | | | | | | | | Export some private functions from QUtf8 to resolve undefined symbols in Qt5Compat after moving QStringRef. Task-number: QTBUG-84437 Change-Id: I9046dcb14ed520d8868a511d79da6e721e26f72b Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Long Live QMap as a refcounted std::map!Giuseppe D'Angelo2020-08-062-0/+393
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and QMultiMap as std::multimap. Just use the implementation from the STL; we can't really claim that our code is much better than STL's, or does things any differently (de facto they're both red-black trees). Decouple QMultiMap from QMap, by making it NOT inherit from QMap any longer. This completes the deprecation started in 5.15: QMap now does not store duplicated keys any more. Something to establish is where to put the QExplictlySharedDataPointer replcement that is in there as an ad-hoc solution. There's a number of patches in-flight by Marc that try to introduce the same (or very similar) functionality. Miscellanea changes to the Q(Multi)Map code itself: * consistently use size_type instead of int; * pass iterators by value; * drop QT_STRICT_ITERATORS; * iterators implictly convert to const_iterators, and APIs take const_iterators; * iterators are just bidirectional and not random access; * added noexcept where it makes sense; * "inline" dropped (churn); * qMapLessThanKey dropped (undocumented, 0 hits in Qt, 1 hit in KDE); * operator== on Q(Multi)Map requires operator== on the key type (we're checking for equality, not equivalence!). Very few breakages occur in qtbase. [ChangeLog][Potentially Source-Incompatible Changes] QMap does not support multiple equivalent keys any more. Any related functionality has been removed from QMap, following the deprecation that happened in Qt 5.15. Use QMultiMap for this use case. [ChangeLog][Potentially Source-Incompatible Changes] QMap and QMultiMap iterators random-access API have been removed. Note that the iterators have always been just bidirectional; moving an iterator by N positions can still be achieved using std::next or std::advance, at the same cost as before (O(N)). [ChangeLog][Potentially Source-Incompatible Changes] QMultiMap does not inherit from QMap any more. Amongst other things, this means that iterators on a QMultiMap now belong to the QMultiMap class (and not to the QMap class); new Java iterators have been added. Change-Id: I5a0fe9b020f92c21b37065a1defff783b5d2b7a9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Document the changed semantics when passing arrays to QByteArray methodsSona Kurazyan2020-08-041-2/+12
| | | | | | | | | | | | | | | | | | | After adding QByteArrayView overloads of QByteArray methods that used to take char*, the way of determining the length of passed fixed-sized array data has changed, due to the QByteArraiyView's optimization to deduce the length at compile time for arrays. Document the behavior and add a changelog item. [ChangeLog][QtCore][QByteArray] When passing fixed size C arrays to QByteArray methods, the length of the data on which the method will operate is determined by array size, and not by scanning for the first '\0' terminator, as it was in Qt 5. Task-number: QTBUG-85815 Change-Id: I11cba17d428791e06c9bd4c7a727b7bd6b6aec3c Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix syntax error in containers documentation codeSander Visser2020-07-161-1/+0
| | | | | Change-Id: Ie15f5a43cb97422b30c8be884ff6b0d2d8647ea5 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Doc: Mark API in Q[Mutable]HashIterator as deprecatedKai Koehne2020-07-141-20/+0
| | | | | | | | | | The reverse iteration API got deprecated in code already in commit dbb54805f63f9e . Now also fix the documentation. Fixes: QTBUG-85482 Pick-to: 5.15 Change-Id: I3b575f60dabfe1005b9744d17c257da3e22817c5 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Move QRegExp and its remaining mentions out of QtCoreSona Kurazyan2020-07-131-243/+0
| | | | | | Task-number: QTBUG-85235 Change-Id: Ibd6c98d952c1bb9916b64715c6430fb0d3fe3843 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Introduce QByteArrayViewSona Kurazyan2020-07-082-2/+69
| | | | | | | | | | | | | | | | | | | | Created a QByteArrayView in symmetry with QStringView. Added the basic tests symmetrical to QStringView tests. Moved the implementations of non-modifying methods of QByteArray to namespace QtPrivate, to be reused inline from both QByteArray and QByteArrayView. Changed QByteArray's counterparts of those methods to take QByteArrayView as argument instead of QByteArray. Removed QByteArray's operator QNoImplicitBoolCast(), because it was causing ambiguity when calling those methods with QByteArray argument (it was there to perevnt if(!ba)/if(ba) from compiling, but currently that would be ambiguous and won't compile anyway). [ChangeLog][QtCore][QByteArrayView] New class. Task-number: QTBUG-84321 Change-Id: I05f92e654cf65c95f2bb31b9c9018746ac110426 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Small fixes to the QList documentationLars Knoll2020-07-061-1/+1
| | | | | Change-Id: Ic839f7859912eb48bb192755d6f10536a0a73f8e Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
* Doc: Fix connect syntax in snippetPaul Wicking2020-07-041-1/+1
| | | | | | | | Pick-to: 5.15 Fixes: QTBUG-85390 Change-Id: I67dbacd977acb6abdafb3b57818f24bf4a2dd302 Reviewed-by: Nico Vertriest <nico.vertriest@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Doc: Update docs with cmake package informationNico Vertriest2020-06-301-0/+1
| | | | | | Task-number: QTBUG-85179 Change-Id: I70dda9b906ecd0b8d8f4d88b0562af8e6c428143 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Use QList instead of QVector in corelib docsJarek Kobus2020-06-2910-554/+209
| | | | | | | Task-number: QTBUG-84469 Task-number: QTBUG-85221 Change-Id: Ieb0ba7d82409e3c053a5788a01e92ea495505643 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Move implementation of QVector/List back to qlist.hLars Knoll2020-06-201-36/+17
| | | | | | | | | | | | | And name the main class QList. That's also the one we document. This gives less porting pain for our users, and a lot less churn in our API, as we use QList in Qt 5 in 95% of our API. In addition, it gives more consistent naming with QStringList and QByteArrayList and disambiguates QList vs QVector(2|3|4)D. Fixes: QTBUG-84468 Change-Id: I3cba9d1d3179969d8bf9320b31be2230d021d1a9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move QTextCodec support out of QtCoreKarsten Heimrich2020-06-202-77/+1
| | | | | | | | | | * Assume UTF-8 on all Unix like systems * Export some functions to be able to compile QTextCodec once moved to Qt5Compat. Task-number: QTBUG-75665 Change-Id: I52ec47a848bc0ba72e9c7689668b1bcc5d736c29 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Document QPromise APIAndrei Golubev2020-06-181-1/+2
| | | | | | | | | Documented QPromise. Added snippets under auto tests to ensure they are compiled and run in CI. Task-number: QTBUG-81586 Change-Id: I20084e38f9d2f6fc8540f95ee03ec3d2827177e8 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Document that Q_INIT_RESOURCE is not necessary for CMake-based projectsJoerg Bornemann2020-06-161-2/+6
| | | | | | | | | | | | | | | | | | Since commit e343affd634 we're creating object libraries for Qt resources in static libraries when building Qt or a Qt-based project with CMake. The purpose of this is to remove the need for calling Q_INIT_RESOURCE in static libraries. Add a note to the documentation and a changelog entry. [ChangeLog][CMake] Calling Q_INIT_RESOURCE in static libraries is not strictly necessary anymore for CMake-based projects. There, for each resource, an object library is created which is linked into consuming projects. This ensures that the linker does not discard the resource's object file, and its initializer is called automatically. Change-Id: I70de439f964dc7257a2255683eda4d434fa451d0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Qt6: remove support for property flags being functionsLars Knoll2020-06-111-4/+2
| | | | | | | | | | | | | | | Property flags should be compile time booleans, not something to be determined at runtime. We've been using this to dynamically disable some properties in QWidget based classes dependent on the state of a different property, but this should better get implemented on top of our widgets. Change-Id: I6296e8761303ecdf24d9e842142e8596304c015d Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Long live std::pair!Giuseppe D'Angelo2020-06-102-77/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make QPair an alias for std::pair, and qMakePair just a forwarder towards std::make_pair. Why? Fundamentally to ditch a bunch of NIH code; gain for free structured bindings, std::tuple and std::reference_wrapper compatibility, and so on. Breakages: * Some that code manually forward declares QPair. We don't care about it (<QContainerFwd> is the proper way). * Some code that overloads on std::pair and QPair. Luckily it's mostly centralized: debug, metatypes, testing macros. Just remove the QPair overload. * Usages of qMakePair forcing the template type parameters. There are a handful of these in qtbase, but only one was actually broken. * std::pair is NOT (and will never likely be) trivially copiable. This is agreed to be a mistake done by practically all implementations in C++11, can can't be fixed without breaking ABI. Some code using QPair assuming it's trivially copiable may break; exactly one occurrence was in qtbase. * QMetaType logic extracts the type names in two different ways, one by looking at the source code string (e.g. extracted by moc) and one via some ad-hoc reflection in C++. We need to make "QPair" (as spelled in the source code) be the same as "std::pair" (gathered via reflection, which will see through the alias) when compared. The way it's already done e.g. for QList is by actually replacing the moc-extracted name with the name of the actual type used in C++; do the same here. On libc++, std::pair is actually in an inline namespace -- i.e. std::__1::pair; the reflection will extract and store "std::__1::pair" so we need an ad-hoc fix to QMetaType. [ChangeLog][QtCore][QPair] QPair is now an alias to std::pair, and does not exist as a class in Qt any more. This may break code such as functions overloaded for both QPair and std::pair. Usually, the overload taking a QPair can be safely discarded, leaving only the one taking a std::pair. QPair API has not changed, and qMakePair is still available for compatibility (although new code is encouraged to use std::pair and std::make_pair directly instead). Change-Id: I7725c751bf23946cde577b1406e86a336c0a3dcf Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Rename snippet files to match the carved up corelib/tools/Edward Welbourne2020-06-049-0/+0
| | | | | | | | | | | This is a folllow-up to commits 548513a4bd050d3df0a85fed6e2d1a00ce06d2ab and a9aa206b7b8ac4e69f8c46233b4080e00e845ff5, renaming the snippets files referenced by the files moved out of corelib/tools/ to match the new locations of the files using them. Change-Id: I59f5d3c217ef835e9244387cc769e7212de9d8f5 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Doc: Document Qt 6 changes for QHash, QMultiHash, QSetKai Koehne2020-05-261-0/+47
| | | | | Change-Id: I9a83d33f05d7c3e5d23399129dfac45a1cb0d6ad Reviewed-by: Lars Knoll <lars.knoll@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-11 22:34:46 +0000