summaryrefslogtreecommitdiffstats
path: root/src/corelib/doc
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Add 'Qt Core Changes in Qt 6'Kai Koehne2020-05-262-0/+46
| | | | | | | | | Skeleton to document changes to Qt Core in Qt 6. Task-number: QTBUG-71036 Task-number: QTBUG-84051 Change-Id: I2720beffb934121258331efd9eeb91c07d40a5bf Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Licenses: Remove reference to change in Qt 5.4Kai Koehne2020-05-221-3/+2
| | | | | | | Qt 5.4 is not documented anymore since quite some time. Change-Id: I6811ead502178f7acbed8cf450e42d7fd33ae29b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Add support of cancellation handler callbacks to QFutureSona Kurazyan2020-05-151-0/+32
| | | | | | | | | Added QFuture::onCanceled() method, for attaching handlers to be called when the QFuture gets canceled. Change-Id: I1f01647d6173ba0c1db6641e14140108b33ac7c4 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Add support of connecting signals to QFutureSona Kurazyan2020-05-151-0/+45
| | | | | | | | | | | Introduced QtFuture::connect(sender, signal) function returning a QFuture object, which is resolved when the signal is emitted. Task-number: QTBUG-81589 Change-Id: Idbe301eb247b468b9b34f3470c3359d6a7af2f3a Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove QRegExp support from QString and StringListLars Knoll2020-05-142-75/+0
| | | | | | | | | | Replacement methods do now exist in QRegExp, or for QRegularExpression when porting to it. Remove all autotests associated with the old methods. Change-Id: I3ff1e0da4b53adb64d5a48a30aecd8b960f5e633 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Document the string converter classesLars Knoll2020-05-141-0/+83
| | | | | | | | | | Document QStringConverter, QStringDecoder and QStringEncoder. In addition, do some touches to the API, renaming one enum value, add a flags argument to one constructor and make some members private. Change-Id: I8f99dc3d98fb8860cf6fa46301e34b7eb400511b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Start porting QTextStream away from QTextCodecLars Knoll2020-05-141-1/+1
| | | | | | | | | | | | As a first step add setEncoding/encoding() methods that use the QStringConverter::Encoding enum, and port all uses of setCodec()/ codec() over to the new API. Internally QTextStream still uses QTextCodec, this will be ported over to QStringConverter in a follow-up change. Change-Id: Icd764cf47b449b57f4ebd010c2dad89e6717d6c0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Document Qt for Python usage of the resource systemFriedemann Kleint2020-05-131-0/+15
| | | | | | | | Pick-to: 5.15 Change-Id: I77576d0e6464099a7595a74f4bf8ef18ec515ec2 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io> Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
* Doc: fix QRandomGenerator code snippetsTasuku Suzuki2020-05-121-4/+4
| | | | | | | | Use the static global instance to call bounded() and fillRange(). Pick-To: 5.15 Change-Id: I91678b7c985ab9d0dcdf09aadad6cb8f495c02cd Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long live qHashMulti(Commutative)Giuseppe D'Angelo2020-05-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Add a helper function so that we have a shortcut. Instead of writing: QHashCombine hash; seed = hash(seed, fieldA); seed = hash(seed, fieldB); // etc. return seed; one can now simply write: return qHashMulti(seed, fieldA, fieldB, fieldC); Port a few usages inside qtbase as a demonstration. [ChangeLog][QtCore][QHash] Added the qHashMulti and qHashMultiCommutative functions as convenience helpers to calculate a hash from multiple variables (typically, data members of a class). Change-Id: I881a9ad41168df20ceecc6588a94abe7ddc6a532 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* CMake: Document versionless commandsKai Koehne2020-05-068-79/+522
| | | | | | Pick-to: 5.15 Change-Id: I249c10bf3338b08477ce04f7c2d5098390a6f9a0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devQt Forward Merge Bot2020-05-051-3/+3
|\ | | | | | | Change-Id: I003c0d6271c6444748bf30b4331eca3fb2410f44
| * Improve QTranslator documentation code snippetKai Koehne2020-05-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use :/i18n/, because this is the place where translations are stored by default if using qmake's CONFIG += lrelease embed_translations. Also revert change of app.exec() done in 16da0b2cf8b6b. First of all, both QGuiApplication and QApplication feature overloads of exec(), so using QCoreApplication::exec() might miss functionality. Anyhow, while it's true that all of them are static member functions, the vast majority of our examples and templates call them with class member access syntax, so let's try to be consistent. Finally, the example since a while uses QCoreApplication::translate, not tr(), so let's not mention it in the description. Change-Id: Ic6e5d91cf04d3f0d1a4296c5c09e790773e6fc62 Reviewed-by: Miłosz Kosobucki <milosz@kosobucki.pl> Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* | Doc: Small fixes in qt5_wrap_cpp documentationKai Koehne2020-05-031-2/+2
| | | | | | | | | | | | Pick-to: 5.15 Change-Id: I0cc066eb5b53c7efb94a9f94cf574b2507f90cf8 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* | QStringIterator: port from uint to char32_tMarc Mutz2020-04-261-5/+3
| | | | | | | | | | | | Change-Id: I0ca47b87216478b28e29b0fa1a118ef13b6d7c84 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 10:17:08 +0000