summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Correct license for examples filesLucie Gérard2024-04-041-1/+1
| | | | | | | | | | | | | According to QUIP-18 [1], all examples and snippets files should be LicenseRef-Qt-Commercial OR BSD-3-Clause [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I9a8fdb5308396e63785486291c4dc41cd59c1fe4 Reviewed-by: Kai Köhne <kai.koehne@qt.io>
* Correct license for tools fileLucie Gérard2024-04-041-1/+1
| | | | | | | | | | | | According to QUIP-18 [1], all tools file should be LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0 [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I42358fbbb1c9dafdce023d69616e47546e434769 Reviewed-by: Kai Köhne <kai.koehne@qt.io>
* iOS: Fix error signalLars Schmertmann2024-03-252-11/+8
| | | | | | | | | | | | | | Currently targetLost is used before reportError. So the QNearFieldTarget will be deleted by the user and the slot connected to the error signal will never be called. In addition reportError use a QueuedConnection so we need to do that for targetLost too and change the order. Because targetLost is always used after invalidate we can add emitting the signal to invalidate. Pick-to: 6.7 Change-Id: I070f6bb705ccff0feacac7f58264ff6ea238bc89 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Unregister Bluetooth profile UUID after connectionTed Feng2024-03-141-13/+40
| | | | | | | | | | | | | | | | | | | | The Bluetooth profile UUID is registered on DBus the whole time while the device is connected, this prevent new connection from happening, which also need to register to the same UUID on DBus. The change is to unregister Bluetooth profile UUID after connection, as it's no longer needed for the current connected device. This will allow new devices that trying to connect to register the same Bluetooth profile UUID On DBus. [ChangeLog][QtBluetooth][Linux/BlueZ] Unregister Bluetooth profile UUID after connection, so it can be registered for connecting to new devices. Fixes: QTBUG-82413 Change-Id: I0e0b4cd303b32213725638efb323e6d00cb7b9e5 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* neard: Don't attempt to send ndefMessagesWritten() signalIevgenii Meshcheriakov2024-01-311-1/+0
| | | | | | | | This signal was removed in Qt 6. Fixes: QTBUG-97943 Change-Id: I46d14c19c3e562f6056cb508a1aea60b0db5f56d Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
* neard: Start polling in Initiator modeIevgenii Meshcheriakov2024-01-311-1/+1
| | | | | | | | | | The ACR122U device used for testing does not work in "Dual" mode. Task-number: QTBUG-97943 Change-Id: Ib36e403d426aa8f9187765810eab7f5d5c86bb04 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Andreas Hartmetz <ahartmetz@gmail.com>
* Improve wording in QNearFieldManager documentationAndreas Hartmetz2024-01-311-15/+17
| | | | | | Task-number: QTBUG-97943 Change-Id: I7887daf6105ee51bc9b7dd7e57ec4db016554245 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Revert "Remove support of Linux in Qt NFC"Andreas Hartmetz2024-01-3115-3/+961
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 4282160a843a01457d71c995d870ab447ada655d. Adapt to changes in QtNfc: - omit .pri and .pro files from the qmake build system - add re-added source files to CMake build system - omit documentation about message handlers (no place for it) - adjust documentation elsewhere to match current practices - remove autogenerated DBus interfaces, generate them at compile time instead - remove unused neard DBus interface XML files - adjust code to current QtNfc API - add the "we mean it" comment to just re-added private headers - replace old license headers with equivalent SPDX license headers If the PCSClite dependencies are found, the PCSClite backend needs to be explicitly disabled to allow enabling the neard backend. That means that the status quo regarding which backends are built is largely maintained. Compiling, not to mention runtime selection or simultaneous use, of more than one backend continues to be unsupported, as it has always been. It seems like neard is ~only used on embedded systems, where a custom Qt build is par for the course. Debian last shipped neard in Buster, currently oldoldstable. Ubuntu last shipped it... at a time that is not covered anymore in its package search. Most other large distributions do package neard, though. I found the following that do: Suse, Fedora, Arch, Gentoo, Yocto. Task-number: QTBUG-97943 Change-Id: I1b4541c49bb5855800fd949bdc20e200967e58b5 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Remove qmake -> CMake porting debris from CMakeLists.txtAndreas Hartmetz2024-01-181-7/+0
| | | | | Change-Id: Ifb633a1910e73e3819b0289e430fef8de5b32e12 Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
* Remove the use of GENERATE_PRIVATE_CPP_EXPORTSAlexey Edelev2024-01-121-1/+0
| | | | | | | Task-number: QTBUG-117983 Change-Id: Ieaa116a12604bc5e660f96b873f8354f70b7a7c6 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Remove the use of Q_BLUETOOTH_PRIVATE_EXPORTAlexey Edelev2024-01-122-2/+2
| | | | | | Task-number: QTBUG-117983 Change-Id: Id155b4277dd7a40d5d0c9ecf96288de91871d37b Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Doc: Use proper Qt Bluetooth linkKai Köhne2024-01-091-1/+1
| | | | | | Pick-to: 6.7 Change-Id: I5805c3b8acd59826b5b3e8dc304d1b57f1b72df6 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Bluetooth Windows: fix segfault in COM de-initIvan Solovev2023-12-151-4/+11
| | | | | | | | | | | | | | | | | | | | | | While doing COM initialization/deinitialization, we always implicitly assumed that QCoreApplication instance is available. However, if the Bluetooth objects are re-parented to the main application, the QCoreApplication instance will already be removed by the time we want to delete the Bluetooth object (and call COM de-init). Fix it by caching the main application's thread, and using it instead of QCoreApplication::instance()->thread() in the mainThreadCoUninit() helper method. This commit still assumes that all Bluetooth objects are created *after* the main QCoreApplication instance. Amends 340b84a5578f78d7a399e369e900ac991d9e0da2. Fixes: QTBUG-119063 Pick-to: 6.7 6.6 6.5 6.2 Change-Id: I450e4e14039ca27fcfd1f3f131789b049e1edb03 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Windows Bluetooth: gracefully handle device disconnect during detailed ↵Ivan Solovev2023-12-151-0/+4
| | | | | | | | | | | | | | | | | | | service discovery Discovering service details in an asynchronous process, which means that the user may actually disconnect from the device while the discovery is still in progress. This means that we could end up in a situation when the discoverServiceDetailsHelper() is called with an empty serviceList. In this case, requesting for a specific service from the serviceList returns a nullptr, which may later lead to a crash. Add a nullptr check to gracefully handle such situations. Fixes: QTBUG-119060 Pick-to: 6.7 6.6 6.5 Change-Id: Iebdff67a12e6550979535ae5bac659ddae57b010 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* Don't use staticAssertTypeMismatch to inform about an unsupported valueVolker Hilsheimer2023-12-141-1/+1
| | | | | | | | | The assert-helper will go away soon, so replace it with the proper solution. Pick-to: 6.7 Change-Id: I6b38ed0189b316d6091144dd0a96b6ec77078af1 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* PCSC: Make polling interval adjustable via environmentIevgenii Meshcheriakov2023-11-232-2/+17
| | | | | | | | | | | | | | | | | | | | Allow overriding the default polling interval using QT_NFC_POLL_INTERVAL_MS environment variable. Reduce the default polling interval to 100 ms to make the library more useful with readers that produce beeps when new tags are detected. Long polling intervals may lead to users removing tags from the reader before QtNfc is able to read them. [ChangeLog][QtNfc][PCSCLite backend] The polling interval is now configurable using QT_NFC_POLL_INTERVAL_MS environment variable. The default polling interval was reduced to 100ms. Fixes: QTBUG-105526 Change-Id: I74c3f3bb88dafa5e389536d88b3837910e91d345 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Doc: Fix template information for QNdefRecord::isRecordTypeLuca Di Sera2023-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When QDoc parses a project, it parses the source code to extract the user-provided documentation and perform sanity checkings based on the code itself on it. When QDoc parses an "\fn" command as part of this process, it tries to understand, based on its intermediate representation built on the information extracted from the code-base, which "documentable element" the "\fn" refers to. When QDoc performs this "matching" process, it takes into consideration only a certain amount of information. For example, no checking is performed over the template declaration of a callable. Due to some upcoming documentation, where two callables are indistinguishable to the current process, as they differ only in their template declaration, QDoc will start to take into consideration the template declaration of a callable when matching. This implies that an "\fn" command should now provide information parity, with regards to template declaration for callables, with the code-base so that QDoc can perform the match correctly. The documentation for `QNdefRecord::isRecordType` is not in sync with the intended target template declaration. Hence, add the missing information to the relevant "\fn" command. Task-number: QTBUG-118080 Change-Id: I86ff66d085db8f6c1600c7f807d995e348407219 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Silence expected java exceptionsJulian Greilich2023-11-151-2/+2
| | | | | | | | | | | | | Since we expect the calls to "connect" and "close" in checkIsTargetLost() to fail with IOException when the target was lost, we dont need to print the exceptions as log warning. This restores the behavior like it was before the port to the new Qt 6 Android APIs (7d2c6ae66fd61be56b35ae0c59354b695a02d6c7). Pick-to: 6.6 6.5 Change-Id: Ic9e14a58827f8b24865202012708644b903d5d70 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* BlueZ: treat AuthenticationCanceled as a PairingErrorIvan Solovev2023-11-102-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ... when it is not triggered from our side. The linked Jira ticket, as well as some searches over the internet, show that some devices report org.bluez.Error.AuthenticationCanceled error when the authentication fails, not when it is canceled. At the same time, it is also possible to get this error code by trying to pair with the device, and then immideately cancelling the pairing, like this: QBluetoothLocalDevice dev; dev.requestPairing(address, QBluetoothLocalDevice::Paired); dev.requestPairing(address, QBluetoothLocalDevice::Unpaired); The pre-existing code was only considering the latter usecase, and so was not reporting AuthenticationCanceled as a PairingError. This patch introduces an extra flag to check if the pairing was canceled from our side. If that's the case - the old behavior is preserved, and we do not report an error. In other cases, a PairingError is reported. Fixes: QTBUG-118895 Pick-to: 6.6 6.5 Change-Id: I1fe246eb8a0da6efb62eddc9a843de7be0f7b2c5 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Reset status of isSessionScheduled when starting a iOS NFC sessionJens Trillmann2023-11-071-0/+1
| | | | | | | | | | | If a user cancels the NFC popup and then starts a new session immediately after then isSessionScheduled gets set to true. This value has to be reset when the session gets started as isSessionScheduled==true leads to the QTimer always triggering a new NFC session. Pick-to: 6.6 6.5 Change-Id: I53d71d5c9b419d334ac6a229cff3e32aa81e9230 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Android Bluetooth: Change static string cache to use QStringJuha Vuolle2023-11-015-42/+54
| | | | | | | | | | | | | | | | | | Relates to change 944200b5a9705a7617f82cdaf5caf8932380aba4 which effectively terminates the application with a warning if QJniObjects are accessed from different thread they were created in. QJniObjects are not inherently thread-safe, as it is not easily possible to synchronize the access with Java-side threads. This change makes the internal string cache to use QStrings instead of QJniObjects. The strings that are cached are constants as per Android documentation, and don't change at runtime. The runtime query and related caching of these strings is more of a measure to protect against changes between eg. Android releases. Change-Id: I76fa607ab6062da504071f3bb0161a30c27361e8 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Android: don't rely on implicit cast of declared QtJniTypes to jobjectVolker Hilsheimer2023-10-271-3/+3
| | | | | | | | | The operator jobject() should be removed from declared QtJniTypes in qtbase, as it's dangerous. Prepare for that by calling object(), which returns the wrapped jobject as well. Change-Id: Ic067532abf4c539e026560577504124eac6050bd Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Add thread protection to Android static string cacheJuha Vuolle2023-10-191-0/+2
| | | | | | | | | | | | | | | The string cache is accessed in the Qt Android main activity thread, as wells as in JNI callbacks which execute in arbitrary Java threads. For clarity: the usage in code looks like this: "valueForStaticField<QtJniTypes::XYZ" There is a small chance that the cache is accessed concurrently. Pick-to: 6.6 6.5 Change-Id: I34c26e22347f65614b18a000b5d61f0737e3b49e Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Include what you need: <QPointer>Marc Mutz2023-10-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | All these TUs relied on transitive includes of qpointer.h, maybe to a large extent via qevent.h, though, given that qevent.h is more or less the only public QtBase header that includes qpointer.h, something else seems to be at play here. Said qevent.h actually needs QPointer in-name-only, so a forward declaration would suffice. Prepare for qevent.h dropping the include. The algorithm I used was: If the TU mentions 'passiveGrabbers', the name of the QEvent function that returns QPointers, and the TU doesn't have qpointer.h included explicitly, include it. That may produce False Positives, but better safe than sorry. Otherwise, in src/, add an include to all source and header files which mention QPointer. Exception: if foo.h of a foo.cpp already includes it, don't include again. As a drive-by, insert some empty lines as include block separators. Task-number: QTBUG-117670 Change-Id: If58fbfe87e750969acbbe7f0b9eb4784bdfcad47 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* JNI: port to changes of JNI traits in qtbaseVolker Hilsheimer2023-09-277-65/+65
| | | | | | | | | Specialize and call the signature/className functions from the new Traits template class. Change-Id: Ibe09d4b5282f8c5488ea3ecb50af4078edec335b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Adapt to renaming of QtJniTypes::String to CTStringVolker Hilsheimer2023-09-261-16/+16
| | | | | Change-Id: Id0459a5935f3cf75066a02e81faf01df7e8195a5 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Doc: Extend list of highlighted Connectivity examplesKai Köhne2023-09-262-2/+7
| | | | | | | Pick-to: 6.5 6.6 6.6.0 Task-number: QTBUG-117221 Change-Id: Idc1d7793c02bc1009f5cc43d30e3208b923ab0ee Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Add explicit include for qjnitypes.hJuha Vuolle2023-09-221-0/+1
| | | | | | | | Apparently the related JNI changes in qtbase necessitate this (won't compile without anymore). Change-Id: I96681186c7a8b29a0407a6910b72d80545f4471a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Clear any pendingJob of BT LE controller in case of disconnectJuha Vuolle2023-09-211-1/+11
| | | | | | | | | | | | | | | | | | | When using QLowEnergyController in Client role and the remote peripheral disconnects, we clear any current resources. However it seems we didn't clear the pendingJob variable. If the pendingJob variable remains non-null, then the next time we use the controller, the "performNextIO()" function will return early as it waits for the previous job to complete. However in this case, as it is a remnant from a previous run, it never completes, and the application's QLowEnergyService::discoverServiceDetails() will silently do nothing (the new job is put into job queue, but never attended, because of this pendingJob not completing). Pick-to: 6.6 6.5 Fixes: QTBUG-115370 Change-Id: Idd14efcc1469c155ac46c6a35336e04fc5bd6aa9 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* JNI: replace TYPE declarations with CLASS declarationsVolker Hilsheimer2023-09-202-14/+14
| | | | | | | | | | | That we have two macros to declare a C++ type to represent a Java class is confusing. The TYPE macro as of now allows us to declare array types, but with QJniArray we won't need that anymore, and can just use Class[] as the type instead. Changing that will be a follow-up commit; for now, get rid of TYPE-usages to declare regular classes. Change-Id: I34ff462d4cf449873e0d0d51343c0475adde37b5 Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
* Allow to set user information after detection started for non NDEF tagsJan Moeller2023-09-121-3/+5
| | | | | | | | | | | | | | Prior to the NDEF implementation one could change the user information after the target detection started. The limitation seems to only effect NDEF tags, so all other tags should still be able to set the information at a later time. This allows to inform the user about the current progress of the process or inform about errors. Fixes: QTBUG-116563 Pick-to: 6.5 6.6 Change-Id: If82ea8c2056eb4c425626b06dac98462e3f0070c Reviewed-by: Lars Schmertmann <lars.schmertmann@governikus.de> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Doc: All overviews list categorizationJaishree Vyas2023-09-071-1/+1
| | | | | | | | | | | | The \generate list names are added for each categorized section with some explanation. Here, calling the overviews as explanations-(name of the section). The idea is to give general terms instead of specific phrases like 'core' etc, for better understanding. Task-number: QTBUG-115347 Pick-to: 6.5 6.6 Change-Id: Ie7ab2df16d61f672a27fb75bd7aea1782a5d59e6 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Doc: Fix parameter type in QBluetoothAddress::qHash()Topi Reinio2023-09-053-1/+7
| | | | | | | | | | | | Fixes documentation warning: clang couldn't find function when parsing \fn QBluetoothAddress::qHash(QBluetoothAddress key, size_t seed) Mark qtconnectivity documentation modules free of warnings. Pick-to: 6.6 Change-Id: Ia7966803bafd0eaac434462a18c704a944e8f527 Reviewed-by: Alex Blasche <alexander.blasche@qt.io> Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Consider protocols that derive NFCNDEFTag in isNdefTag()Jan Moeller2023-08-301-1/+10
| | | | | | | | | | | | NFCMiFareTag, NFCFeliCaTag, NFCISO15693Tag, NFCISO7816Tag all derive NFCNDEFTag. Therefor, the current implementation of isNdefTag() will return true for all of these, as they satisfy [conformsToProtocol:@protocol(NFCNDEFTag)]. Pick-to: 6.5 6.6 Fixes: QTBUG-116563 Change-Id: I816cb84b2c06f1f9401fccb3867ab78d3ee075b7 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Make BlueZ DBus peripheral the default backend on LinuxJuha Vuolle2023-08-232-14/+16
| | | | | | | | | | | | | | | | | The DBus backend was introduced in Qt 6.5, and is intended as the eventual successor of the kernel backend. Users can opt-out and use the older kernel backend by setting the QT_BLUETOOTH_USE_KERNEL_PERIPHERAL environment variable. [ChangeLog][QtBluetooth] The default Linux peripheral implementation was changed from the kernel interface to the BlueZ DBus interface. The old implementation remains available by defining QT_BLUETOOTH_USE_KERNEL_PERIPHERAL as environment variable. Fixes: QTBUG-115925 Change-Id: I27d60e410c02d0435c7dce81e5c06448a89bcc65 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Bluetooth: remove custom implementations of qbswap(QUuid::Id128Bytes)Ivan Solovev2023-08-232-18/+0
| | | | | | | | | | | | Starting from qtbase/470b2b8ad9f28eaf24518dfa3f48cc13fcdc421f qbswap() is provided as a hidden friend for this type, so the custom implementations for Windows and Android backends in Qt Bluetooth are no longer required. Fixes: QTBUG-116341 Pick-to: 6.6 Change-Id: I451de4249a082331f75c1db93ad420cf96d0e3cc Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Fix translation context of QBluetoothUuid::WeightScaleFeatureFriedemann Kleint2023-08-211-1/+1
| | | | | | | | Amends 439e818f7843b6a117e1bfe755e313022e14aafa. Pick-to: 6.6 6.5 6.2 5.15 Change-Id: If08fc84a495d493b463cc71de43237b1cc950a5b Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* QBluetoothUuid: magic_numbers -= 50Marc Mutz2023-08-181-5/+5
| | | | | | | | | | | | | | | | | | Prevent code readers from having to compare the long lists of magic numbers in the various bluetooth-specific UUID constructors; they're all the same as the ones used in the quint32 ctor, so use C++11 ctor delegation to make all ctors call the quint32 one. This calls into question the need of the quint16 ctor, seeing as the quint32 ctor could just do the former's job with an implicit conversion. But removing it would allow users to pass any integral type to the QBluetoothUuid ctor, which is not the case atm, because the two integral ctors make each other ambiguous unless the arguments match either parameter types exactly. So leave it in. Pick-to: 6.6 Change-Id: I40ddc47149cbb0526ad6488f32cc7f203e70a6b3 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* QBluetoothUuid: inherit all ctors from QUuidMarc Mutz2023-08-183-15/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QBluetoothUuid clearly is-a QUuid, so it should have the same constructors, though it may add its own on top. Three Qt releases (6.3-6.6) of QUuid changes have, however, not been properly reflected in QBluetoothUuid, so fix it once and for all by adding using QUuid::QUuid; to QBluetoothUuid, thereby inheriting all the QUuid ctors (except SMFs) that QBluethoothUuid doesn't supply itself. This fixes or simplifies: - The Id128Bytes ctor, which we don't need to supply at all now. - The QString ctor, which was replaced by a QAnyStringView overload in QUuid a long time ago (6.3). - Anything else that we have missed in the past (GUID, e.g.). The superfluous constructors still have to be retained in the ABI, because QBluetoothUuid is unfortunately exported wholesale. This affects only the QString ctor. The other one was not in 6.5, and we don't provide BC with pre-releases of Qt. Add some variance to the fromString() tests now that we have QAnyStringView instead of just QString. Found in API-review. [ChangeLog][QtBluetooth] QBluetoothUuid now provides all the constructors that QUuid also provides (incl. from GUID and QAnyStringView). Pick-to: 6.6 Change-Id: I2cb76a9a9cbc47f2fd4e637bdb41233d1ffc6972 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QBluetoothUuid: inline the (quint128, Endian) ctorMarc Mutz2023-08-182-20/+4
| | | | | | | | | | | | | | | | We can actually write a body that works for both unsigned __int128 as well as the legacy struct quint128, using QUuid::fromBytes(), so do that. This removes the need to keep a complex implementation behind the ABI boundary, and thus allows to remove the function from the ABI so we don't run into even more BiC problems once MSVC starts supporting __int128, possibly with just a newer /std flag which, as per current rules, isn't supposed to change the ABI. Pick-to: 6.6 Change-Id: I1975cf68bc5f5421bf90f81a691ddf68bfa928dd Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QBluetoothUuid: inline converting ctor from QUuidMarc Mutz2023-08-172-5/+12
| | | | | | | | | | | | | | | | It really shouldn't be out-of-line. We should allow the compiler to see it as the no-op that it is. As a drive-by, pre-program the signature to pass by value come Qt 7, fixing a Clazy warning. We could already do it now, but since T and const T& don't overload, we'd have to take out the QT6_NEW_OVERLOAD bazooka, and it's not really worth it. When the code is inline, the compiler can see through the pass-by-reference overhead and avoid allocating the argument on the stack. Pick-to: 6.6 Change-Id: Ic708bb9b2cacd4df22313b704de557dbda4d28fa Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* QBluetoothUuid: cut out the streamingOperator() middle-manMarc Mutz2023-08-153-5/+12
| | | | | | | | | | | | | | | | | | | | | | | The split into an inline friend op<< and an out-of-line streamingOperator() just causes the QDebug object to be copied once more than otherwise necessary. Relegate the streamingOperator() middle-man to QT_REMOVED_SINCE status and make op<< the real thing. We can't make the named function call op<<, because Thiago says there are situations in which the op<<(QDebug, QBluetoothUuid) call in removed_api.cpp, if we were to use it, would get resolved to an exported version of the old op<< in a user library compiled without -fvisibility-hidden, creating a cycle. Fortunately, the implementation is simple enough to make a DRY violation acceptable. Problem exists in 6.5, too, but let's get as many removed_api.cpp tasks done for 6.6, because the QT_NO_INT128 in removed_api.cpp will make a QT_REMOVED_SINCE(6, 7) in this header file that much harder. Pick-to: 6.6 Change-Id: I10b42cfc1565db8d9a6924cee0af8fb6623c9000 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* QBluetoothUuid: provide Endian overloads for quint128 functionsMarc Mutz2023-08-153-31/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This mimicks the new APIs of the same name in QUuid. For QBluetoothUuid, this is wonderful news, because the old overloads that lack the Endian parameter are now _always_ referring to the old struct quint128, and are, as usual, defined in removed_api.cpp¹ ¹ with the caveat that QT_NO_INT128 is defined there globally, which may create problems for potential QT_REMOVED_SINCE(6, 7)s. A solution would be to move this stuff out into a compat/old_int128_api.cpp, but let's first get the 6.6 part done. The new overloads are now either `unsigned __int128` (#ifdef QT_SUPPORTS_INT128) or `struct quint128` (otherwise), never both, so we don't need a second TU to do the overloading at the ABI level. This leaves removed_api.cpp with its traditional role of dealing with QT_REMOVED_SINCE (with the caveat mentioned above) and the QT_SUPPORTS_INT128 handling is in qbluetoothuuid.{h,cpp}, where it belongs. This greatly simplifies the #ifdef'ery in all three files and allows to do away with the "normal" vs. "not typical" QT_REMOVED_SINCE(6, 6) section split. Amends 5d90296f312f72ffa6a5322df7b565c3e5521684. As a drive-by, fix missing Q_QDOC handling. Pick-to: 6.6 Change-Id: I4ead4ee39533967a78c145ef222d9991fdf4cd98 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* QBluetoothUuid: remove default case labels and fix the falloutMarc Mutz2023-08-121-8/+4
| | | | | | | | | | | | | | Learn to love -Wswitch and avoid default case labels even at the cost of having a few enumerator cases "too many". They help catch mistakes, like, in this case, the missing handling of QBluetoothUuid::CharacteristicType::WeightScaleFeature. [ChangeLog][QtBluethooth][QBluetoothUuid] Fixed missing result of characteristicToString(CharacteristicType::WeightScaleFeature). Pick-to: 6.6 6.5 6.2 5.15 Change-Id: I04b7cf9ee058ef5a8d202fff01fb347d315562f6 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* QBluetoothUuid: remove unused equals() method declarationMarc Mutz2023-08-121-3/+0
| | | | | | | | | | This was never used, nor even defined, ever since the declaration was added in 9c59558afc71f36a82a1cab9ca0841119892e26a, so it doesn't need QT_REMOVED_SINCE(). It just was whitespace. Pick-to: 6.6 6.5 6.2 Change-Id: I6a56cbe346455818c13cefb66c65887edbfcb0e9 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* QBluetoothUuid: insulate against potentially-disappearing QUuid(quint128) ctorMarc Mutz2023-08-121-1/+1
| | | | | | | | | | | | | | | | | | We're considering remove the QUuid(quint12*) ctor in favor of the "named" fromUInt128() ctor, so isolate the code against that by going via the Id128Bytes ctor, which always exists. This particular way of writing the code requires C++20/C99 designated initializer support enabled in the compiler. It just so happens that the only compiler that doesn't support __int128 (MSVC) also is the only compiler that doesn't allow the use of designated initializers in C++17 builds (because MSVC never implemented C99), only in C++20+ ones, so for the moment we're ok. If this becomes a problem, we can rewrite the code. Pick-to: 6.6 Change-Id: Ic4424ddad1a8a703e00b2ff3d9b45b07bb321fd0 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QBluetoothUuid: add missing Endian argument to Id128Bytes ctorMarc Mutz2023-08-112-4/+5
| | | | | | | | | | | | | | | The base class has it, so QBluetoothUuid also has to have it, too, for API symmetry. Adapt the docs to be more like QUuid's for the same function, even though those may still be improved in qtbase (in which case we shouldn't forget to re-sync them here). Found in API-review. Pick-to: 6.6 Change-Id: If13df1e7551235e2c9f57ba0e8729d7f2a6d494c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Mark the module free of Q_FOREACH ... againMarc Mutz2023-08-042-2/+0
| | | | | | | | | | | This restores the QT_NO_FOREACH macro originally added in acd6e18a145fba25b85a2f025a03f1ab2f3e4a1e and then lost in the cmake port. Luckily, no new uses have crept in in the meantime. Change-Id: I19be444b48595b2c7ab73d828f9fbae8a9b90c2b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QBluetoothUuid: keep custom quint128 and related methods when 128-bit ints ↵Ivan Solovev2023-08-033-12/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | are not supported ... to retain SC with prior Qt versions. For QBluetoothUuid::toUInt128() this is done by introducing an extra condition to the method declaration and definition. If the 128-bit ints are not supported, we shouldn't hide the method under QT_BLUETOOTH_REMOVED_SINCE. The QBluetoothUuid(quint128) c-tor is a bit more tricky, because we need to provide a forwarding c-tor to be able to use QUuid(quint128) c-tor. And at the same time, we need to keep BC by keeping the constructor that takes custom struct quint128. This is achieved by having an unconstrained c-tor declaration and two implementations: * an implementation in qbluetoothuuid.cpp is only available when Qt supports 128-bit ints. It just forwards to the QUuid c-tor. * an implementation in removed_api.cpp serves as a backup implementation to keep BC for the case when Qt supports 128-bit ints. And at the same time it serves as a main implementation when 128-bit ints are not supported. Also extend the unit-tests to explicitly check that both APIs are available on all platforms. The test additionally makes sure that QUuid::toUInt128() and QBluetoothUuid::toUInt128() provide the result which is similar to QUuid::toBytes(). This guarantees compatibility between platforms. This commit amends 1e903be81f43da4e31385bb7866bb4d3f07e5eba. Pick-to: 6.6 Change-Id: I6ba3ff6278e6db11a372b46f001429f4466520a0 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Build with QT_NO_CONTEXTLESS_CONNECTAhmad Samir2023-07-205-4/+8
| | | | | | | | | | | | This disables the 3-arg QObject::connect() overload: QObject::connect(sender, signal, functor) For details see: https://lists.qt-project.org/pipermail/development/2023-July/044141.html Change-Id: I9a70ce75d7aa67b9a077c0db4ab908b54526db23 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 22:56:34 +0000