62cb5589b3
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> |
||
|---|---|---|
| .. | ||
| auto | ||
| baseline | ||
| benchmarks | ||
| global | ||
| libfuzzer | ||
| manual | ||
| shared | ||
| testserver | ||
| CMakeLists.txt | ||
| README | ||
This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.
Linux X11:
* The user must be logged in to an active desktop; you can't run the
autotests without a valid DISPLAY that allows X11 connections.
* The tests are run against a KDE3 or KDE4 desktop.
* Window manager uses "click to focus", and not "focus follows mouse". Many
tests move the mouse cursor around and expect this to not affect focus
and activation.
* Disable "click to activate", i.e., when a window is opened, the window
manager should automatically activate it (give it input focus) and not
wait for the user to click the window.