This base class implementation for COM objects provides IUnknown
interface implementation with reference counting which will allow to
keep all this functionality and implementation in the same place.
Pick-to 6.6 6.5
Change-Id: I8ec597b1040ac33295317e06338ffdcb61b78f85
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Makes it easier to get an idea of what went wrong
Change-Id: Idace20ecf008fa906780881b62ed44ac36751123
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It was weird that they were missing. Now that C++23 added them to
std::span, add them to QSpan, too.
Pick-to: 6.6
Change-Id: I4a9b1fdeda66bc7b133c8f7b3b269656e5faffa3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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.
Task-number: QTBUG-117670
Change-Id: I3321cccdb41ce0ba6d8a709cea92427aba398254
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This changes takes Qt for Android Java code away from the Delegate
classes that uses heavily Java reflection to invoke Activity/Service
calls and overrides. So instead of that, now, we have a QtActivityBase
and a QtServiceBase classes which handle the override logic needed for
Qt directly without reflection.
These Base classes extend Android's Activity and Service directly, and
are inside the internal Qt android package (under Qt6Android.jar).
For example, to handle onConfigurationChanged, instead of the current
way where we need this in QtActivityDelegate:
public void onConfigurationChanged(Configuration configuration)
{
try {
m_super_onConfigurationChanged.invoke(m_activity, configuration);
} catch (Exception e) {
e.printStackTrace();
}
handleUiModeChange(configuration.uiMode &
Configuration.UI_MODE_NIGHT_MASK);
}
And then this in QtActivity:
@Override
public void onConfigurationChanged(Configuration newConfig)
{
if (!QtLoader.invokeDelegate(newConfig).invoked)
super.onConfigurationChanged(newConfig);
}
public void super_onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
}
And having to keep it's Method handles around and then use Java
reflection
to call the override behavior done by Qt and the superclass methods.
instead of that, we can do it now in QtActivityBase like:
@Override
public void onConfigurationChanged(Configuration newConfig)
{
super.onConfigurationChanged(newConfig);
handleUiModeChange(newConfig.uiMode &
Configuration.UI_MODE_NIGHT_MASK);
}
Then, we would still have our user facing QtActivity class which extends
QtActivityBase and benefit from the same implementation of Qt logic done
in the base class.
An additional benefit to this approach is that now QtActivity will be
very lightweight and doesn't need to have all the boilerplate code as
before.
[ChangeLog][Android] Simplify Qt for Android public bindings
(QActivity, QtService and QtApplication) by implementing base
classes which use the delegate implementions directly and avoid
reflection.
Task-number: QTBUG-115014
Task-number: QTBUG-114593
Change-Id: Ie1eca74f989627be4468786a27e30b16209fc521
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
The loops are iterating over local const containers, so use ranged-for.
Remove '#undef QT_NO_FOREACH'.
Task-number: QTBUG-115839
Change-Id: I252f048e3c469bf9bb34cb0756ccbd57571fd886
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
GestureWidget::ignoredGestures QSet:
- elements are inserted in the container in a top-level test function,
then a CustomEvent is constructed and sendCustomGesture() is called,
which sends the events, invoking the GestureWidget::event() overload,
the latter iterates over the container, thus the container isn't
changed while it's being iterated over, because the code can't recurse
into the top-level test function and that's where the container is
modified later on (by inserting or by calling widget.reset() which
clears the container)
- the loop body doesn't change the container
So use ranged-for and std::as_const.
The same logic applies to the GestureItem::ignoredGestures QSet.
Task-number: QTBUG-115839
Change-Id: Icf95e90a8af5aa7e947035704121557494afc326
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It noted that an unspecified function claimed the offset it was
checking should be +1, while testing it against that or -1. The
function turns out to be QDateTime::addDays(), whose doc did indeed,
misleadingly, say that it lands after a gap it would have hit. It in
fact overshoots the gap in the direction of its change. Amend its
docs, likewise those of addMonths() and addYears(), to reflect the
true behavior.
Amend the test to look at the direction of the step its taking and
anticipate that the adjustment will be in the same direction; then
compare the actual adjustment to that.
Change-Id: I9ab918fac0ab2195ef014983f37fccc435bf0498
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The implementation previously worked for non-short date-times, where
the offset has been remembered since construction. This included the
case of zoned times (and local times more than 2^55 msec away from the
start of 1970) that hit a spring-forward's gap; but excluded local
times that did the same (within 2^55 msec of the epoch).
This precluded an offset check in a spring-forward test, now added.
We can in fact determine the offset whenever we got a valid date and
time (we do so in the course of initializing the object, and when
asked for toMSecsSinceEpoch(), even when invalid), and we should not
use the value of the recorded offset if we didn't get a valid date and
time, so amend to always return 0 if we didn't get valid date and time
and always report the correct offset otherwise.
In the process, amend offsetFromUtc()'s computation to directly
resolve the date-time, rather than doing so via toMSecsSinceEpoch(),
which has to repeat decision-making offsetFromUtc() has already done
by the time it calls it. Also amend toMSecsSinceEpoch() to return 0 if
we didn't have a valid date and time to begin with, so it only
attempts to produce a useful result in the case where construction
attempted to resolve the date-time.
Change-Id: I6574e362275ccc4fbd8de6f0fa875d2e50f3bffe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The resolution selects a point in time outside the gap, which will be
represented by toMSecsSinceEpoch()'s return, despite the QDT object's
isValid() returning false. Previously we retained the
originally-calculated msecs, so as to keep date() and time() matching
what was asked for. However, this required adjusting offset, which was
not remembered for local times within 2^55 milliseconds of the start
of 1970. This lead to an inconsistency between the offset from UTC
reported for the resolution for a local time further from the epoch,
or for a time-zone, and the actual offset from UTC at the time
indicated by the return from toMSecsSinceEpoch().
Instead, retain the actually calculated offset (even if we aren't
going to remember it) and adjust the msecs to the value that ensures
toMSecsSinceEpoch() will get the selected resolution. This
incidentally means that, when toMSecsSinceEpoch() has to re-resolve
(for a local time within 2^55 msecs of the epoch), it avoids
revisiting the complications of hitting the gap.
In passing, change internal stateAtMillis() to take the QTimeZone it
is passed by const reference, to save a copy (noticed during debug).
Also tweak a comment in a test to be explicit about a default value.
[ChangeLog][QtCore][Possibly Significant Behavior Change] When
QDateTime is instantiated for a combination of date and time that was
skipped, by local time or a time-zone, for example during a
spring-forward DST transition, the invalid result's time() - and, in
rare cases, date() - no longer match what was asked for. Instead,
these values and offsetFromUtc() now match the point in time
identified by toMSecsSinceEpoch().
Change-Id: Id61c4274b365750f56442a4a598be5c14cfca689
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
If a QShortcut is registered with a QWindow as its parent, but QApplication
is used, we end up in QApplicationPrivate::createShortcutPrivate(), and
create a QtWidgetsShortcutPrivate that implements shortcut context matching
via qWidgetShortcutContextMatcher.
The problem is that qWidgetShortcutContextMatcher expects the windows
to be QWidgetWindows, which meant that plain QWindow based shortcuts
would always fail.
This can happen for example if a QApplication is used in Qt Quick
to provide dialog fallbacks, but QShortcuts are otherwise used
with plain QWindows, or QQuickWindows e.g.
We now defer the check of whether there's an active (widget) window,
and fall back to QtGui's simpleContextMatcher in case we don't find
a QWidget, QAction, or QGraphicsWidget shortcut owner to handle
the matching for.
Note: We don't support shortcut matching for QAction in QtGui,
but this is left for another day. There is also a discrepancy
between how QtGui and QtWidgets handles Qt::ApplicationShortcut.
The former will treat it as a match even if there is no active
QWindow, while the latter requires that there's an active widget
window.
Fixes: QTBUG-116221
Change-Id: I487995f2e660a40f6556828b84a521d81a58f1b6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
After d9bb8c0a17 we call inputDirection()
on the platform input context to initialize the direction at startup.
The test can't assume there are no other callers to the functions
in the QPlatformInputContext layer.
Change-Id: Ic1cecd608b2759e703a17838fcf24b4ff53ad07e
Reviewed-by: Liang Qi <liang.qi@qt.io>
It's very hard to test on Android otherwise: Creator isn't cooperating
well enough with Android Studio / SDK manager with where stuff is
installed, qmake doesn't build an apk, and qt-cmake-standalone-test
doesn't work wth Android either.
Renamed the executable to tablet_device_info so it's a bit less
confusing on device launcher UIs.
Task-number: QTBUG-86297
Change-Id: I3bb7f816e43f8df4183be1c0866e228befa9e8d9
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Since it hides QFile's overloads this was not supported for
QTemporaryFile.
[ChangeLog][QtCore][QTemporaryFile] Added support for passing
std::filesystem::path to rename and createNativeFile.
Change-Id: I909ff1d5b9c586824c9901d7dad278dfad09ffc3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We were already doing this for a key combination without modifiers,
but now we do the same for e.g. Control+Unknown. This matches the
behavior we have for QKeySequencePrivate::decodeString(), where
we return Qt::Key_Unknown if we can't resolve the key, even if
we have resolved some valid modifiers, e.g. "Meta+Trolls" as in
the tst_QKeySequence::parseString() test.
Change-Id: I238e29276e6ce356ae60c67585739587fa388f07
Reviewed-by: Liang Qi <liang.qi@qt.io>
Added moveToTrashDuplicateName() to see what happens if you attempt to
trash two files with the same exact full path. Both files should get
independently moved to the trash bin and not clobber each other.
Added moveToTrashXdgSafety() to test that QFileSystemEngine will
properly skip over an unsafe $root/.Trash directory, as required by the
XDG specification. I think the specification should also make security
requirements on $root/.Trash-$uid too, but that's for another change.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd1786cd60e4244c7c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
qnativesocketengine_win.cpp: don't check if timeout is < 0, because
remainingTimeAsDuration() doesn't return negative values.
All the changes done in one go, not function by function, as that causes
the least churn. You can think of them as a couple of very similar
changes repeated various times.
Drive-by change: replace `forever {` with `for (;;)`
Task-number: QTBUG-113518
Change-Id: Ie9f20031bf0d4ff19e5b2da5034822ba61f9cbc3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When a dock widget is closed while floating, it still reports being
floating even though the QWidget::windowHandle()->isVisible() returns
false. This is documented behavior and will not be changed.
c153066baa relied on the isFloating() to
return false, if the dock widget is closed. When the window title was
changed by setWindowTitle(), the change was overridden by reading the
old value from the window handle.
=> Amend the patch and add a windowHandle()->isVisible() as a condition.
In c153066baa, an autotest for the title
propagation (QTBUG-113591) was added to floatingTabs().
=> Harden the setWindowTitle() test function. Move the tests related to
QTBUG-113591 and QTBUG-117764 to this function.
Fixes: QTBUG-117764
Pick-to: 6.6 6.5
Change-Id: Id37a9a22d4d13abad4ea55c74ea4e834bdb2bfab
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
By fixing how many requests we are expecting to _finish_.
Since the nRequests variable is only decreased once a
request is finished, we only actually expect 1. No matter
how many times it gets redirected.
This was the slowest test-function in the test, clocking in at
10 seconds. Now it's sub 500ms.
Pick-to: 6.6 6.5
Change-Id: I544360f0928466c1bc0fbc6806952ccec588d131
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Otherwise characters in right to left languages like Hebrew might
mess up the output.
Change-Id: I8753e7e672159ed515dc6152c3629adf91cfd4a9
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
QItemDelegate was superseded since Qt4 by QStyledItemDelegate but it
took until Qt6.7 to remove the last occurrences in qtbase.
- remove unused includes / replace with qabstractitemdelegate.h
- replace references in the documentation with QStyledItemDelegate
- adjust the examples and tests to use QStyledItemDelegate
Pick-to: 6.5 6.6
Change-Id: I246755004ce2d01192a726ca0972106c237df0cc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
On some xcb platforms the xcb_configure_notify_event_t is sent after the
window is fully exposed which leads to a wrong position for
QWidget::mapToGlobal() which makes the test fail.
Fix it by waiting for a move event with a position != 0,0 before
starting the drag'n'drop operation.
Fixes: QTBUG-94250
Change-Id: If91a15815205ba9dcea36248d9de03ed0a7e5822
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
and add QChar overload to reduce allocations
Also port tests from char* literals to char16_t literals
Change-Id: I99381a2da08d9d35e6135c48bd92bd8d72533065
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Construction from nullptr wasn't, before, because it was using the
QPointer(T*) constructor, which cannot be constexpr. Add a constexpr
QPointer(std::nullptr_t) constructor to enable this use-case.
This requires to mark the (T*) constructor as Q_WEAK_OVERLOAD,
otherwise legacy construction from a literal 0 would be ambiguous.
No documentation changes needed, as the set of valid expressions
(apart from constinit'ing) has not changed. Mention the nullptr ctor,
though, without \since.
Add a test to confirm that contruction from derived still works.
Change-Id: If9d5281f6eca0c408a69f03fecba64a70a0c9cf0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Ignore expected warning messages when looking up classes, methods, or
field that don't exist. Make the test implicitly fail for any other
warning messages.
Change-Id: I79ec799102b1ab9424aa39c5255413931b8ad152
Reviewed-by: Petri Virkkunen <petri.virkkunen@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
In non-static builds, of course.
Change-Id: Ifbf974a4d10745b099b1fffd1777ac97c0921759
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The whole Q_DECLARE_METATYPE part is superfluous in these two examples,
as QVariant works with any type as long as it is copy-constructible.
And QVariant will call the equivalent of qRegisterMetaType, so that
doesn't need to happen, either.
Showing how to integrate the type with qDebug is fine in theory, but
also a repetition of content that can be found in other places.
Given that there isn't much else being shown in these two examples, it's
better to remove them from examples and move them to manual tests.
Some parts of "Custom Type Example" were used as snippets in other
documentations under qtbase/src/corelib. So, they were added in
customtypeexample.cpp file in the snippets folder.
Fixes: QTBUG-117001
Pick-to: 6.6 6.5
Change-Id: I45b16338912e3f7394cbb5169642bd31af32d5e1
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
A Qt::ApplicationShortcut shortcut is not tied to a specific window.
We do however document that the shortcut "is active when one of the
applications windows are active", which seems like a strange limitation,
but for now we honor it in our test as well by making another window
active.
Change-Id: I235230ff69df29ee43d356d3efaeedb20071faf3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Construction from nullptr isn't, because it's using the QPointer(T*)
constructor, which cannot be constexpr.
Pick-to: 6.6 6.5
Change-Id: I19129a0fca5873e83d20351a909a7994399bfcce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add a testcase to make sure the signals for moveing rows are properly
connected from the model to the corresponding QHeaderView slots.
Task-number: QTBUG-117698
Pick-to: 6.6 6.5
Change-Id: I354f8836d3de58a8bf51da7a8c0859a673ec9339
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Named instances of variable application fonts are exposed
automatically through CTFontManagerCreateFontDescriptorsFromData()
(and also for the URL equivalent).
The main change here is just to call this instead of the overload
which only returns the first font.
Note that this also updates the test: This is because the conversion
from CoreText normalized weight values to TTF values is not 100%.
In the CoreText code, we map Heavy (0.56) to ExtraBold, but ExtraBold
gets converted to 0.6, which is closer to the CoreText value for Black
(0.62).
To avoid hitting this inconsistency, the QtExtraBold has been changed
to Black weight instead, which resolves to the same on all platforms.
Task-number: QTBUG-108624
Change-Id: Ied6d42e9e3e1ba8b7102936c5be3d285b3d9e07f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There's no need for the manual sendKeyEvent, as QTest already
has the ability to send synthetic clicks, and we don't need
a colored window to test shortcut activation.
Pick-to: 6.6
Change-Id: I8409888664e2316bec4ea64f21dbb8b6915091f4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
- Initialize QStringList with an initializer_list instead of old style
operator <<()
- Use Qt::StringLiterals more, better readability
- Test CaseSensitivity
Change-Id: If7dde14333d54b8c2f682036634ad94d5f9f9c74
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For GDI, there doesn't seem to be any way to do this, so it depends
on selecting the DirectWrite font database explicitly.
This moves the supportsVariableApplicationFonts() check into the
QPlatformFontDatabase instead of the font engine, since that's
where it belongs.
[ChangeLog][Fonts] Added support for selecting named instances in
variable application fonts when using the DirectWrite backend.
Task-number: QTBUG-108624
Change-Id: I51e0fedd7a9616088a06453a1d17f48bd18fa5a7
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Fix runtime warnings about testdata with the same name.
Pick-to: 6.6 6.5
Change-Id: I5d4927cc53be3e08a524498db42a8a08396ced8e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The jbyte type is a signed char, which also promotes to int in variadic
argument functions.
Extend the test case to make sure that we don't get any warnings for
the most relevant parameter types.
Change-Id: I7811e1eebdbc989ab5989eb1a2c502acd0540bc7
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Zoltan Gera <zoltan.gera@qt.io>
When changing the selected index in a combo box,
also update the current index in the item view's
selection model right away, and don't delay this
until when the combobox popup gets shown in
QComboBox::showPopup.
This is needed to make sure that the selection
is properly exposed to the accessibility layer.
On the accessibility layer, QAccessibleComboBox,
the a11y implementation for the combobox, exposes
the entries in its list child
(s. QAccessibleComboBox::child) and Orca queries
the selected item when the combobox gets focus,
which didn't return the proper results earlier,
resulting in no or the wrong entry getting
announced.
Extend the existing combobox a11y tests
accordingly.
Pick-to: 6.6 6.5
Fixes: QTBUG-117644
Change-Id: Ia26de5eafd229f7686745a2fbe03fc1eb6a713f8
Reviewed-by: Liang Qi <liang.qi@qt.io>
Implement the missing overload to handle UTF-8 specific data types,
including char8_t (C++20), char, uchar and signed char.
Introduce the helper function 'assign_helper_char8' which handles the
non-contiguous_iterator case. The contiguous_iterator case is already
handled by the QAnyStringView overload.
Include 'qstringconverter.h' at the end of the file, since it can't
be included at the top due to diamond dependency conflicts.
QStringDecoder is an implementation detail we don't want users to
depend on when using assign(it, it). It would be unnatural to not
be able to use a function just because we didn't include an
apparently unrelated header.
[ChangeLog][QtCore][QString] Enabled assign() for UTF-8 data types.
Fixes: QTBUG-114208
Change-Id: Ia39bbb70ca105a6bbf1a131b2533f29a919ff66d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This change can be described in the following 2 categories:
1. Support 3 ways to escape identifiers mentioned in SQLite Keywords
In SQLite Keywords (https://sqlite.org/lang_keywords.html), it shows
that there are 3 ways to escape identifiers, i.e., "", [], ``. So, I
have overridden "bool isIdentifierEscaped(const QString &,
IdentifierType)" to support it. In addition, there was a bug of
_q_escapeIdentifier. If there is a field name called length [cm],
which uses square brackets to show units, _q_escapeIdentifier will
not escape it to "length [cm]".
2. Identify identifiers correctly if identifiers have been escaped
There is a bug of QSQLiteDriver::record and
QSQLiteDriver::primaryIndex.
If we input escaped identifiers with separator, let's say
"databaseName"."tableName", both will change the input into
databaseName"."tableName, which is incorrect and causes
qGetTableInfo cannot get the right results. In addition, I overrode
stripDelimiters to strip "databaseName"."tableName" correctly.
There are still some assumptions for isIdentifierEscaped,
escapeIdentifier, and stripDelimiters, but I think this change it better
than what we have now.
1. For isIdentifierEscaped, if identifiers have a dot and the dot is a
separator, it is the users' responsibility to escape the pair of
schema and table name correctly. For example,
"aSchemaName"."aTableName", not "aSchemaName".a"TableName". That's
because we don't know whether the dot is just a dot of the name or a
separator.
2. For escapeIdentifier, if identifiers have a dot and the parts before
and after the dot are not escaped, escapeIdentifier will treat the
dot as part of the table name or field name. The same as the item
above, it is users' responsibility to do it right.
3. For stripDelimiters, the same as above, it is users' responsibility
to do escape if users want to use format schemaName.tableName or
tableName.fieldName.
Change-Id: I9d036a2a96180f8542436188f75a220a0fe58257
Reviewed-by: Po-Hao Su <supohaosu@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
We want to test the traits even on nonsensical types.
Change-Id: I63ed022c9529d9de9d336157e6f025937321ca16
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Now that QtJniTypes::Objects are no longer primitive types that are the
same as a jobject, using those types in registered native functions
breaks. JNI will call those function with a jobject on the function
pointer, and lacking any type safety, the call to the registered
function will proceed with a wrong type of object on the stack.
To fix that, register the native function via a proxy that is a variadic
argument function, and unpack the variadic arguments into a list of
typed arguments, using the types we know the user-code function wants.
Then call the function with a tuple of those types using std::apply,
which gives us type safety and implicit conversion for free.
Add a test that exercises this.
Change-Id: I9f980e55d3d13f8fc16c410dc0d17dbdc200cb47
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Instead of having a type that doesn't behave like a QJniObject, which
includes not holding a proper reference on the Java object, make the
QtJniTypes::Object type a QJniObject subclass that can be specialized
via CRTP to provide type-specific constructor and static functions.
QJniObject doesn't have a virtual destructor, but we subclass it only to
add a typed interface, without adding any additional data members.
Add versions of the static functions from QJniObjects to the
QtJniTypes::Object so that they can be called without explicitly
specifying the type or class name. This includes a constructor and named
constructors.
Constructing such objects means constructing a Java object of the class
the object type represents, as per the Q_DECLARE_JNI_CLASS declaration.
This is not without ambiguity, as constructing a type with a jobject
parameter can mean that a type wrapping an existing jobject should be
created, or that a Java object should be created with the provided
jobject as the parameter to the constructor (e.g. a copy constructor).
This ambiguity is for now inevitable; we need to be able to implicitly
convert jobject to such types. However, named constructors are provided
so that client code can avoid the ambiguity.
To prevent unnecessary default constructed QJniObjects that are then
replaced immediately with a properly constructed object, add a protected
QJniObject constructor that creates an uninitialized object (e.g. with
the d-pointer being nullptr), which we can then assign the constructed
jobject to using the available assignment operator. Add the special
copy and move constructor and assignment operators as explicit members
for clarity, even though the can all be defaulted.
Such QJniObject subclasses can then be transparently passed as arguments
into JNI call functions that expect a jobject representation, with the
QtJniTypes::Traits specialization from the type declaration providing the
correct signature.
QJniObject's API includes a lot of legacy overloads: with variadic
arguments, a explicit signature string, and jclass/jmethodID parameters
that are completely unused within Qt itself. In addition the explicit
"Object" member functions to explicitly call the version that returns a
jobject (and then a QJniObject). All this call-side complexity is taken
care of by the compile-time signature generation, implicit class type,
and template argument deduction. Overloads taking a jclass or jmethod
are not used anywhere in Qt, which is perhaps an indicator that they,
while nice to have, are too hard to use even for ourselves.
For the modern QtJniTypes class instantiations, remove all the overhead
and reduce the API to the small set of functions that are used all over
the place, and that don't require an explicit signature, or class/method
lookup.
This is a source incompatible change, as now QJniTypes::Object is no
longer a primitive type, and no longer binary equivalent to jobject.
However, this is acceptable as the API has so far been undocumented,
and is only used internally in Qt (and changes to adapt are largely
already merged).
Change-Id: I6d14c09c8165652095f30511f04dc17217245bf5
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
If we construct the QJniObject from a jobject, then we know the jclass,
but not the class's name. If className is called while the stored name
is empty, get the name of the jclass and updated the stored value.
Change-Id: Ic3332a6da2dac1eb6842f90da1b9264398a43155
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
currentCompatProperty should point to the compat property that's
currently being evaluated. As soon as we start evaluating a new compat
property, it's invalid by definition. Temporarily disable it then.
Pick-to: 6.6 6.5 6.2
Fixes: QTBUG-109465
Change-Id: I7baba9350ebf488370a63a71f0f8dbd7516bf578
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
To be used in QWeakPointer.
Change-Id: I5ee9dd0862a0b23d316aaadf5d68bef1ce609e8b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
