| LICENSE.QEVENTDISPATCHER_CF.txt |
|
1501 |
- |
| qabstracteventdispatcher.cpp |
!
\class QAbstractEventDispatcher
\inmodule QtCore
\brief The QAbstractEventDispatcher class provides an interface to manage Qt's event queue.
\ingroup events
An event dispatcher receives events from the window system and other
sources. It then sends them to the QCoreApplication or QApplication
instance for processing and delivery. QAbstractEventDispatcher provides
fine-grained control over event delivery.
For simple control of event processing use
QCoreApplication::processEvents().
For finer control of the application's event loop, call
instance() and call functions on the QAbstractEventDispatcher
object that is returned. If you want to use your own instance of
QAbstractEventDispatcher or of a QAbstractEventDispatcher
subclass, you must install it with QCoreApplication::setEventDispatcher()
or QThread::setEventDispatcher() \e before a default event dispatcher has
been installed.
The main event loop is started by calling
QCoreApplication::exec(), and stopped by calling
QCoreApplication::exit(). Local event loops can be created using
QEventLoop.
Programs that perform long operations can call processEvents()
with a bitwise OR combination of various QEventLoop::ProcessEventsFlag
values to control which events should be delivered.
QAbstractEventDispatcher also allows the integration of an
external event loop with the Qt event loop.
\sa QEventLoop, QCoreApplication, QThread
|
23230 |
- |
| qabstracteventdispatcher.h |
|
4923 |
- |
| qabstracteventdispatcher_p.h |
|
1497 |
- |
| qabstractnativeeventfilter.cpp |
!
\class QAbstractNativeEventFilter
\inmodule QtCore
\since 5.0
\brief The QAbstractNativeEventFilter class provides an interface for receiving native
events, such as MSG or XCB event structs.
|
3149 |
- |
| qabstractnativeeventfilter.h |
QABSTRACTNATIVEEVENTFILTER_H |
906 |
- |
| qapplicationstatic.h |
|
3484 |
- |
| qapplicationstatic.qdoc |
|
5428 |
- |
| qassociativeiterable.cpp |
!
\class QAssociativeIterator
\internal
|
10060 |
- |
| qassociativeiterable.h |
|
6661 |
- |
| qbasictimer.cpp |
!
\class QBasicTimer
\inmodule QtCore
\brief The QBasicTimer class provides timer events for objects.
\ingroup events
This is a fast, lightweight, and low-level class used by Qt
internally. We recommend using the higher-level QTimer class
rather than this class if you want to use timers in your
applications. Note that this timer is a repeating timer that
will send subsequent timer events unless the stop() function is called.
To use this class, create a QBasicTimer, and call its start()
function with a timeout interval and with a pointer to a QObject
subclass. When the timer times out it will send a timer event to
the QObject subclass. The timer can be stopped at any time using
stop(). isActive() returns \c true for a timer that is running;
i.e. it has been started, has not reached the timeout time, and
has not been stopped. The timer's ID can be retrieved using
timerId().
Objects of this class cannot be copied, but can be moved, so you
can maintain a list of basic timers by holding them in container
that supports move-only types, e.g. std::vector.
\sa QTimer, QChronoTimer, QTimerEvent, QObject::timerEvent(),
Timers, {Affine Transformations}
|
6289 |
- |
| qbasictimer.h |
|
2161 |
- |
| qbindingstorage.h |
|
3033 |
- |
| qcfsocketnotifier.cpp |
Socket Notifiers
*********************************************************************** |
11298 |
- |
| qcfsocketnotifier_p.h |
|
2517 |
- |
| qchronotimer.cpp |
!
\class QChronoTimer
\inmodule QtCore
\since 6.8
\ingroup events
\brief The QChronoTimer class provides repetitive and single-shot timers.
The QChronoTimer class provides a high-level programming interface for
timers. To use it, create a QChronoTimer, either passing the interval to the
constructor, or setting it after construction using setInterval(), connect
its timeout() signal to the appropriate slots, and call start(). From then
on, it will emit the timeout() signal at constant intervals. For example:
\snippet timers/timers.cpp qchronotimer-interval-in-ctor
\snippet timers/timers.cpp qchronotimer-setinterval
You can set a timer to time out only once by calling setSingleShot(true).
\note QChronoTimer has no singleShot() static methods, as the ones on
QTimer already work with chrono types and nanoseconds resolution.
In multithreaded applications, you can use QChronoTimer in any thread
that has an event loop. To start an event loop from a non-GUI
thread, use QThread::exec(). Qt uses the timer's
\l{QObject::thread()}{thread affinity} to determine which thread
will emit the \l{QChronoTimer::}{timeout()} signal. Because of this, you
must start and stop the timer in its thread; it is not possible to
start a timer from another thread.
As a special case, a QChronoTimer with a timeout of \c 0ns will time out
as soon as possible, though the ordering between zero timers and other
sources of events is unspecified. Zero timers can be used to do some
work while still providing a responsive user interface:
\snippet timers/timers.cpp zero-timer
From then on, \c processOneThing() will be called repeatedly. It should
be written in such a way that it always returns quickly (for example,
after processing one data item) so that Qt can deliver events to the user
interface and stop the timer as soon as it has done all its work. This
is the traditional way of implementing heavy work in GUI applications,
but as multithreading is becoming available on more platforms, a modern
alternative is doing the heavy work in a thread other than the GUI (main)
thread. Qt has the QThread class, which can be used to achieve that.
\section1 Accuracy and Timer Resolution
The accuracy of timers depends on the underlying operating system and
hardware. Most platforms support requesting nano-second precision for
timers (for example, libc's \c nanosleep), though the accuracy of the
timer will not equal this resolution in many real-world situations.
You can set the \l{Qt::TimerType}{timer type} to tell QChronoTimer which
precision to request from the system.
For Qt::PreciseTimer, QChronoTimer will try to keep the precision at
\c 1ns. Precise timers will never time out earlier than expected.
For Qt::CoarseTimer and Qt::VeryCoarseTimer types, QChronoTimer may wake
up earlier than expected, within the margins for those types:
\list
\li 5% of the interval for Qt::CoarseTimer
\li \c 500ms for Qt::VeryCoarseTimer
\endlist
All timer types may time out later than expected if the system is busy or
unable to provide the requested accuracy. In such a case of timeout
overrun, Qt will emit timeout() only once, even if multiple timeouts have
expired, and then will resume the original interval.
\section1 Alternatives to QChronoTimer
QChronoTimer provides nanosecond resolution and a ±292 years range
(less chances of integer overflow if the interval is longer than \c
std::numeric_limits<int>::max()). If you only need millisecond resolution
and ±24 days range, you can continue to use the classical QTimer class
\include timers-common.qdocinc q-chrono-timer-alternatives
Some operating systems limit the number of timers that may be used;
Qt does its best to work around these limitations.
\sa QBasicTimer, QTimerEvent, QObject::timerEvent(), Timers,
{Analog Clock}
|
11133 |
- |
| qchronotimer.h |
|
3113 |
- |
| qcore_foundation.mm |
!
\fn QByteArray QByteArray::fromCFData(CFDataRef data)
Constructs a new QByteArray containing a copy of the CFData \a data.
\since 5.3
\ingroup platform-type-conversions
\sa fromRawCFData(), fromRawData(), toRawCFData(), toCFData()
|
16007 |
- |
| qcore_mac.mm |
|
29376 |
- |
| qcore_mac_p.h |
Helper class that automates reference counting for CFtypes.
After constructing the QCFType object, it can be copied like a
value-based type.
Note that you must own the object you are wrapping.
This is typically the case if you get the object from a Core
Foundation function with the word "Create" or "Copy" in it. If
you got the object from a "Get" function, either retain it or use
constructFromGet(). One exception to this rule is the
HIThemeGet*Shape functions, which in reality are "Copy" functions.
|
15937 |
- |
| qcore_ohos.cpp |
|
9103 |
- |
| qcore_ohos_p.h |
|
17431 |
- |
| qcore_unix.cpp |
!
\internal
Behaves as close to POSIX poll(2) as practical but may be implemented
using select(2) where necessary. In that case, returns -1 and sets errno
to EINVAL if passed any descriptor greater than or equal to FD_SETSIZE.
|
4278 |
- |
| qcore_unix_p.h |
|
9678 |
- |
| qcore_wasm.cpp |
!
Converts the DOMRect (https://www.w3.org/TR/geometry-1/) \a domRect to QRectF. The behavior is
undefined if the provided parameter is not a DOMRect.
\since 6.5
\ingroup platform-type-conversions
\sa toDOMRect()
|
3435 |
- |
| qcoreapplication.cpp |
!
\internal
This function is a Qt 6 thread-safe (no data races) version of:
\code
QCoreApplication::instance() != nullptr
\endcode
We may remove it in Qt 7.0 because the above will be thread-safe.
|
116892 |
- |
| qcoreapplication.h |
|
10280 |
- |
| qcoreapplication_mac.cpp |
QCoreApplication utility functions
*************************************************************************** |
984 |
- |
| qcoreapplication_p.h |
|
5151 |
- |
| qcoreapplication_platform.h |
|
3974 |
- |
| qcoreapplication_win.cpp |
GetModuleFileName() returns the length of the module name, when it has
space to store it and 0-terminate; this return is necessarily smaller than
the buffer size, as it doesn't include the terminator. When it lacks
space, the function returns the full size of the buffer and fills the
buffer, truncating the full path to make it fit. We have reports that
GetModuleFileName sometimes doesn't set the error number to
ERROR_INSUFFICIENT_BUFFER, as claimed by the MSDN documentation; so we
only trust the answer when the return is actually less than the buffer
size we pass in. (When truncating, except on XP, it does so by enough to
still have space to 0-terminate; in either case, it fills the claimed
space and returns the size of the space. While XP might thus give us the
full name, without a 0 terminator, and return its actual length, we can
never be sure that's what's happened until a later call with bigger buffer
confirms it by returning less than its buffer size.)
|
33520 |
- |
| qcoreevent.cpp |
!
\class QEvent
\inmodule QtCore
\brief The QEvent class is the base class of all
event classes. Event objects contain event parameters.
\ingroup events
Qt's main event loop (QCoreApplication::exec()) fetches native
window system events from the event queue, translates them into
QEvents, and sends the translated events to \l{QObject}s.
In general, events come from the underlying window system
(spontaneous() returns \c true), but it is also possible to manually
send events using QCoreApplication::sendEvent() and
QCoreApplication::postEvent() (spontaneous() returns \c false).
\l {QObject}{QObjects} receive events by having their QObject::event() function
called. The function can be reimplemented in subclasses to
customize event handling and add additional event types;
QWidget::event() is a notable example. By default, events are
dispatched to event handlers like QObject::timerEvent() and
QWidget::mouseMoveEvent(). QObject::installEventFilter() allows an
object to intercept events destined for another object.
The basic QEvent contains only an event type parameter and an
"accept" flag. The accept flag set with accept(), and cleared
with ignore(). It is set by default, but don't rely on this as
subclasses may choose to clear it in their constructor.
Subclasses of QEvent contain additional parameters that describe
the particular event.
\sa QObject::event(), QObject::installEventFilter(),
QCoreApplication::sendEvent(),
QCoreApplication::postEvent(), QCoreApplication::processEvents()
|
30523 |
- |
| qcoreevent.h |
check that covariant return is safe to add |
16955 |
- |
| qcoreevent_p.h |
|
1186 |
- |
| qdeadlinetimer.cpp |
!
\class QDeadlineTimer
\inmodule QtCore
\brief The QDeadlineTimer class marks a deadline in the future.
\since 5.8
\reentrant
\ingroup tools
\compares strong
The QDeadlineTimer class is usually used to calculate future deadlines and
verify whether the deadline has expired. QDeadlineTimer can also be used
for deadlines without expiration ("forever"). It forms a counterpart to
QElapsedTimer, which calculates how much time has elapsed since
QElapsedTimer::start() was called.
QDeadlineTimer provides a more convenient API compared to
QElapsedTimer::hasExpired().
The typical use-case for the class is to create a QDeadlineTimer before the
operation in question is started, and then use remainingTime() or
hasExpired() to determine whether to continue trying the operation.
QDeadlineTimer objects can be passed to functions being called to execute
this operation so they know how long to still operate.
\snippet code/src_corelib_kernel_qdeadlinetimer.cpp 0
Many QDeadlineTimer functions deal with time out values, which all are
measured in milliseconds. There are two special values, the same as many
other Qt functions named \c{waitFor} or similar:
\list
\li 0: no time left, expired
\li -1: infinite time left, timer never expires
\endlist
\section1 Reference Clocks
QDeadlineTimer will use the same clock as QElapsedTimer (see
QElapsedTimer::clockType() and QElapsedTimer::isMonotonic()).
\section1 Timer types
Like QTimer and QChronoTimer, QDeadlineTimer can select among
different levels of coarseness on the timers. You can select
precise timing by passing Qt::PreciseTimer to the functions that
set of change the timer, or you can select coarse timing by passing
Qt::CoarseTimer. Qt::VeryCoarseTimer is currently interpreted the same
way as Qt::CoarseTimer.
This feature is dependent on support from the operating system: if the OS
does not support a coarse timer functionality, then QDeadlineTimer will
behave like Qt::PreciseTimer was passed.
QDeadlineTimer defaults to Qt::CoarseTimer because on operating systems
that do support coarse timing, making timing calls to that clock source is
often much more efficient. The level of coarseness depends on the
operating system, but should be in the order of a couple of milliseconds.
\section1 \c{std::chrono} Compatibility
QDeadlineTimer is compatible with the \c{std::chrono} API from C++11 and
can be constructed from or compared to both \c{std::chrono::duration} and
\c{std::chrono::time_point} objects. In addition, it is fully compatible
with the \l{chrono_literals Symbol Index}{time literals
from C++14}, which allow one to write code such as:
\snippet code/src_corelib_kernel_qdeadlinetimer.cpp 1
As can be seen in the example above, QDeadlineTimer offers a templated
version of remainingTime() and deadline() that can be used to return
\c{std::chrono} objects.
Note that comparing to \c{time_point} is not as efficient as comparing to
\c{duration}, since QDeadlineTimer may need to convert from its own
internal clock source to the clock source used by the \c{time_point} object.
Also note that, due to this conversion, the deadlines will not be precise,
so the following code is not expected to compare equally:
\snippet code/src_corelib_kernel_qdeadlinetimer.cpp 2
\sa QTime, QChronoTimer, QElapsedTimer, Qt::TimerType
|
28101 |
- |
| qdeadlinetimer.h |
|
7171 |
- |
| qelapsedtimer.cpp |
!
\class QElapsedTimer
\inmodule QtCore
\brief The QElapsedTimer class provides a fast way to calculate elapsed times.
\since 4.7
\reentrant
\ingroup tools
\compares strong
The QElapsedTimer class is usually used to quickly calculate how much
time has elapsed between two events. Its API is similar to that of QTime,
so code that was using that can be ported quickly to the new class.
However, unlike QTime, QElapsedTimer tries to use monotonic clocks if
possible. This means it's not possible to convert QElapsedTimer objects
to a human-readable time.
The typical use-case for the class is to determine how much time was
spent in a slow operation. The simplest example of such a case is for
debugging purposes, as in the following example:
\snippet qelapsedtimer/main.cpp 0
In this example, the timer is started by a call to start() and the
elapsed time is calculated by the elapsed() function.
The time elapsed can also be used to recalculate the time available for
another operation, after the first one is complete. This is useful when
the execution must complete within a certain time period, but several
steps are needed. The \tt{waitFor}-type functions in QIODevice and its
subclasses are good examples of such need. In that case, the code could
be as follows:
\snippet qelapsedtimer/main.cpp 1
Another use-case is to execute a certain operation for a specific
timeslice. For this, QElapsedTimer provides the hasExpired() convenience
function, which can be used to determine if a certain number of
milliseconds has already elapsed:
\snippet qelapsedtimer/main.cpp 2
It is often more convenient to use \l{QDeadlineTimer} in this case, which
counts towards a timeout in the future instead of tracking elapsed time.
\section1 Reference Clocks
QElapsedTimer will use the platform's monotonic reference clock in all
platforms that support it (see QElapsedTimer::isMonotonic()). This has
the added benefit that QElapsedTimer is immune to time adjustments, such
as the user correcting the time. Also unlike QTime, QElapsedTimer is
immune to changes in the timezone settings, such as daylight-saving
periods.
On the other hand, this means QElapsedTimer values can only be compared
with other values that use the same reference. This is especially true if
the time since the reference is extracted from the QElapsedTimer object
(QElapsedTimer::msecsSinceReference()) and serialised. These values
should never be exchanged across the network or saved to disk, since
there's no telling whether the computer node receiving the data is the
same as the one originating it or if it has rebooted since.
It is, however, possible to exchange the value with other processes
running on the same machine, provided that they also use the same
reference clock. QElapsedTimer will always use the same clock, so it's
safe to compare with the value coming from another process in the same
machine. If comparing to values produced by other APIs, you should check
that the clock used is the same as QElapsedTimer (see
QElapsedTimer::clockType()).
\sa QTime, QChronoTimer, QDeadlineTimer
|
14885 |
- |
| qelapsedtimer.h |
|
2873 |
- |
| qeventdispatcher_cf.mm |
During scroll view panning, and possibly other gestures, UIKit will
request a switch to UITrackingRunLoopMode via GSEventPushRunLoopMode,
which records the new runloop mode and stops the current runloop.
Unfortunately the runloop mode is just stored on an internal stack, used
when UIKit itself is running the runloop, and is not available through e.g.
CFRunLoopCopyCurrentMode, which only knows about the current running
runloop mode, not the requested future runloop mode.
To ensure that we pick up this new runloop mode and use it when calling
CFRunLoopRunInMode from processEvents, we listen for the notification
emitted by [UIApplication pushRunLoopMode:requester:].
Without this workaround we end up always running in the default runloop
mode, resulting in missing momentum-phases in UIScrollViews such as the
emoji keyboard.
|
23498 |
- |
| qeventdispatcher_cf_p.h |
|
6962 |
- |
| qeventdispatcher_glib.cpp |
|
18158 |
- |
| qeventdispatcher_glib_p.h |
|
2467 |
- |
| qeventdispatcher_unix.cpp |
maxMsg |
15439 |
- |
| qeventdispatcher_unix_p.h |
|
3784 |
- |
| qeventdispatcher_wasm.cpp |
|
19413 |
- |
| qeventdispatcher_wasm_p.h |
|
4147 |
- |
| qeventdispatcher_win.cpp |
reserved |
30564 |
- |
| qeventdispatcher_win_p.h |
|
4291 |
- |
| qeventloop.cpp |
!
\class QEventLoop
\inmodule QtCore
\brief The QEventLoop class provides a means of entering and leaving an event loop.
At any time, you can create a QEventLoop object and call exec()
on it to start a local event loop. From within the event loop,
calling exit() will force exec() to return.
\sa QAbstractEventDispatcher
|
13954 |
- |
| qeventloop.h |
|
2808 |
- |
| qeventloop_p.h |
|
1194 |
- |
| qfunctions_p.h |
|
532 |
- |
| qfunctions_win.cpp |
!
\internal
Make sure the COM library is is initialized on current thread.
Initializes COM as a single-threaded apartment on this thread and
ensures that CoUninitialize will be called on the same thread when
the thread exits. Note that the last call to CoUninitialize on the
main thread will always be made during destruction of static
variables at process exit.
|
2240 |
- |
| qfunctions_win_p.h |
|
1269 |
- |
| qfunctions_winrt_p.h |
|
5011 |
- |
| qiterable.cpp |
!
\class QBaseIterator
\inmodule QtCore
QBaseIterator\<Container\> forms the common base class for all iterators
operating on subclasses of QIterable, where \a Container is the meta-type
descriptor.
|
21800 |
- |
| qiterable.h |
|
17558 |
- |
| qiterable_impl.h |
|
718 |
- |
| qjniarray.h |
|
42629 |
- |
| qjniarray.qdoc |
|
16910 |
- |
| qjnienvironment.cpp |
!
\class QJniEnvironment
\inmodule QtCore
\since 6.1
\brief The QJniEnvironment class provides access to the JNI Environment (JNIEnv).
When using JNI, the \l {JNI tips: JavaVM and JNIEnv}{JNIEnv} class is a pointer to a function
table and a member function for each JNI function that indirects through the table. \c JNIEnv
provides most of the JNI functions. Every C++ native function receives a \c JNIEnv as the first
argument. The JNI environment cannot be shared between threads.
Since \c JNIEnv doesn't do much error checking, such as exception checking and clearing,
QJniEnvironment allows you to do that easily.
For more information about JNIEnv, see \l {Java: Interface Function Table}.
\note This API has been designed and tested for use with Android.
It has not been tested for other platforms.
|
19285 |
- |
| qjnienvironment.h |
|
3778 |
- |
| qjnihelpers.cpp |
|
15561 |
- |
| qjnihelpers_p.h |
|
5941 |
- |
| qjniobject.cpp |
|
59317 |
- |
| qjniobject.h |
|
39306 |
- |
| qjnitypes.h |
|
12970 |
- |
| qjnitypes_impl.h |
|
14660 |
- |
| qmath.cpp |
|
8613 |
- |
| qmath.h |
|
7509 |
- |
| qmath.qdoc |
|
8533 |
- |
| qmetaassociation.cpp |
!
\class QMetaAssociation
\inmodule QtCore
\since 6.0
\brief The QMetaAssociation class allows type erased access to associative containers.
\ingroup objectmodel
\compares equality
The class provides a number of primitive container operations, using void*
as operands. This way, you can manipulate a generic container retrieved from
a Variant without knowing its type.
QMetaAssociation covers both, containers with mapped values such as QMap or
QHash, and containers that only hold keys such as QSet.
The void* arguments to the various methods are typically created by using
a \l QVariant of the respective container or value type, and calling
its \l QVariant::data() or \l QVariant::constData() methods. However, you
can also pass plain pointers to objects of the container or value type.
Iterator invalidation follows the rules given by the underlying containers
and is not expressed in the API. Therefore, for a truly generic container,
any iterators should be considered invalid after any write operation.
\sa QMetaContainer, QMetaSequence, QIterable, QIterator
|
16144 |
- |
| qmetaassociation.h |
|
9285 |
- |
| qmetacontainer.cpp |
!
\class QMetaContainer
\inmodule QtCore
\since 6.0
\brief The QMetaContainer class provides common functionality for sequential
and associative containers.
QMetaContainer is part of Qt's meta-type system that allows type-erased access
to container-like types at runtime.
It serves as a common base for accessing properties of containers in a generic
way, such as size, iteration, and clearing operations, without knowing the actual
container type.
Derived classes, such as QMetaSequence, provide specialized interfaces for
sequential containers.
\ingroup objectmodel
\compares equality
|
11685 |
- |
| qmetacontainer.h |
|
48279 |
- |
| qmetaobject.cpp |
!
\class QMetaObject
\inmodule QtCore
\brief The QMetaObject class contains meta-information about Qt
objects.
\ingroup objectmodel
The Qt \l{Meta-Object System} in Qt is responsible for the
signals and slots inter-object communication mechanism, runtime
type information, and the Qt property system. A single
QMetaObject instance is created for each QObject subclass that is
used in an application, and this instance stores all the
meta-information for the QObject subclass. This object is
available as QObject::metaObject().
This class is not normally required for application programming,
but it is useful if you write meta-applications, such as scripting
engines or GUI builders.
The functions you are most likely to find useful are these:
\list
\li className() returns the name of a class.
\li superClass() returns the superclass's meta-object.
\li method() and methodCount() provide information
about a class's meta-methods (signals, slots and other
\l{Q_INVOKABLE}{invokable} member functions).
\li enumerator() and enumeratorCount() and provide information about
a class's enumerators.
\li propertyCount() and property() provide information about a
class's properties.
\li constructor() and constructorCount() provide information
about a class's meta-constructors.
\endlist
The index functions indexOfConstructor(), indexOfMethod(),
indexOfEnumerator(), and indexOfProperty() map names of constructors,
member functions, enumerators, or properties to indexes in the
meta-object. For example, Qt uses indexOfMethod() internally when you
connect a signal to a slot.
Classes can also have a list of \e{name}--\e{value} pairs of
additional class information, stored in QMetaClassInfo objects.
The number of pairs is returned by classInfoCount(), single pairs
are returned by classInfo(), and you can search for pairs with
indexOfClassInfo().
\note Operations that use the meta object system are generally thread-
safe, as QMetaObjects are typically static read-only instances
generated at compile time. However, if meta objects are dynamically
modified by the application (for instance, when using QQmlPropertyMap),
then the application has to explicitly synchronize access to the
respective meta object.
\sa QMetaClassInfo, QMetaEnum, QMetaMethod, QMetaProperty, QMetaType,
{Meta-Object System}
|
152954 |
- |
| qmetaobject.h |
|
16958 |
- |
| qmetaobject_moc_p.h |
|
1400 |
- |
| qmetaobject_p.h |
|
8548 |
- |
| qmetaobjectbuilder.cpp |
!
\class QMetaObjectBuilder
\inmodule QtCore
\internal
\brief The QMetaObjectBuilder class supports building QMetaObject objects at runtime.
|
79157 |
- |
| qmetaobjectbuilder_p.h |
|
9646 |
- |
| qmetasequence.cpp |
!
\class QMetaSequence
\inmodule QtCore
\since 6.0
\brief The QMetaSequence class allows type erased access to sequential containers.
\ingroup objectmodel
\compares equality
The class provides a number of primitive container operations, using void*
as operands. This way, you can manipulate a generic container retrieved from
a Variant without knowing its type.
The void* arguments to the various methods are typically created by using
a \l QVariant of the respective container or value type, and calling
its \l QVariant::data() or \l QVariant::constData() methods. However, you
can also pass plain pointers to objects of the container or value type.
Iterator invalidation follows the rules given by the underlying containers
and is not expressed in the API. Therefore, for a truly generic container,
any iterators should be considered invalid after any write operation.
|
18857 |
- |
| qmetasequence.h |
|
9732 |
- |
| qmetatype.cpp |
qfloat16 was neither a builtin, nor unconditionally registered
in QtCore in Qt <= 6.2.
Inserting it as an alias ensures that a QMetaType::id call
will get the correct built-in type-id (the interface pointers
might still not match, but we already deal with that case.
|
122061 |
- |
| qmetatype.h |
|
96703 |
- |
| qmetatype_p.h |
can never get here |
8770 |
- |
| qmimedata.cpp |
|
20592 |
- |
| qmimedata.h |
|
1468 |
- |
| qnapi_p.h |
|
47838 |
- |
| qobject.cpp |
\internal
mutex to be locked when accessing the connection lists or the senders list
|
222084 |
- |
| qobject.h |
|
22341 |
- |
| qobject_impl.h |
Logic to statically generate the array of qMetaTypeId
ConnectionTypes<FunctionPointer<Signal>::Arguments>::types() returns an array
of int that is suitable for the types arguments of the connection functions.
The array only exist if all the types are valid for QMetaType, detected
using qTryMetaTypeInterfaceForType(). If any type is not valid at this
point (non-const references and forward-declared types), the function
returns nullptr. If the issue is a forward-declared type, the function
can be used in a queued connection if the type is registered elsewhere
before the signal is emitted. If the type is a non-const reference, it
cannot be use in queued connections at all.
|
1985 |
- |
| qobject_p.h |
for Qt Test |
20219 |
- |
| qobject_p_p.h |
|
8877 |
- |
| qobjectcleanuphandler.cpp |
!
\class QObjectCleanupHandler
\inmodule QtCore
\brief The QObjectCleanupHandler class watches the lifetime of multiple QObjects.
\ingroup objectmodel
A QObjectCleanupHandler is useful whenever you need to know when a
number of \l{QObject}s that are owned by someone else have been
deleted. This is important, for example, when referencing memory
in an application that has been allocated in a shared library.
To keep track of some \l{QObject}s, create a
QObjectCleanupHandler, and add() the objects you are interested
in. If you are no longer interested in tracking a particular
object, use remove() to remove it from the cleanup handler. If an
object being tracked by the cleanup handler gets deleted by
someone else it will automatically be removed from the cleanup
handler. You can delete all the objects in the cleanup handler
with clear(), or by destroying the cleanup handler. isEmpty()
returns \c true if the QObjectCleanupHandler has no objects to keep
track of.
\sa QPointer
|
3007 |
- |
| qobjectcleanuphandler.h |
|
747 |
- |
| qobjectdefs.h |
|
32351 |
- |
| qobjectdefs_impl.h |
The following List classes are used to help to handle the list of arguments.
It follow the same principles as the lisp lists.
List_Left<L,N> take a list and a number as a parameter and returns (via the Value typedef,
the list composed of the first N element of the list
|
29462 |
- |
| qpermissions.cpp |
|
23904 |
- |
| qpermissions.h |
end |
5633 |
- |
| qpermissions_android.cpp |
|
8588 |
- |
| qpermissions_harmony.cpp |
|
5148 |
- |
| qpermissions_p.h |
|
1500 |
- |
| qpermissions_plugin.cpp |
|
3018 |
- |
| qpermissions_wasm.cpp |
|
10368 |
- |
| qpointer.h |
non-constexpr |
3863 |
- |
| qpointer.qdoc |
|
9754 |
- |
| qpoll.cpp |
|
5205 |
- |
| qpoll_p.h |
|
1015 |
- |
| qproperty.cpp |
!
\internal
QPropertyDelayedNotifications is used to manage delayed notifications in grouped property updates.
It acts as a pool allocator for QPropertyProxyBindingData, and has methods to manage delayed
notifications.
\sa beginPropertyUpdateGroup, endPropertyUpdateGroup
|
97050 |
- |
| qproperty.h |
MSVC runs into an issue with constexpr with source location (error C7595)
so use the factory function as a workaround |
53547 |
- |
| qproperty_p.h |
!
\internal
Similar to \c QPropertyBindingPrivatePtr, but stores a
\c QPropertyObserver * linking to the QPropertyBindingPrivate*
instead of the QPropertyBindingPrivate* itself
|
39525 |
- |
| qpropertyprivate.h |
The two members below store the original binding data and property
data pointer of the property which gets proxied.
They are set in QPropertyDelayedNotifications::addProperty
|
13547 |
- |
| qsequentialiterable.cpp |
!
\class QSequentialIterable
\deprecated [6.15] Use QMetaSequence::Iterable instead.
\since 5.2
\inmodule QtCore
\brief The QSequentialIterable class is an iterable interface for a container in a QVariant.
This class allows several methods of accessing the values of a container held within
a QVariant. An instance of QSequentialIterable can be extracted from a QVariant if it can
be converted to a QVariantList.
The container itself is not copied before iterating over it.
\sa QVariant
|
6721 |
- |
| qsequentialiterable.h |
|
6047 |
- |
| qsignalmapper.cpp |
!
\class QSignalMapper
\inmodule QtCore
\brief The QSignalMapper class bundles signals from identifiable senders.
\ingroup objectmodel
This class collects a set of parameterless signals, and re-emits
them with integer, string or widget parameters corresponding to
the object that sent the signal. Note that in most cases you can
use lambdas for passing custom parameters to slots. This is less
costly and will simplify the code.
The class supports the mapping of particular strings, integers,
objects and widgets with particular objects using setMapping().
The objects' signals can then be connected to the map() slot which
will emit a signal (it could be mappedInt(), mappedString()
and mappedObject()) with a value associated with
the original signalling object. Mappings can be removed later using
removeMappings().
Example: Suppose we want to create a custom widget that contains
a group of buttons (like a tool palette). One approach is to
connect each button's \c clicked() signal to its own custom slot;
but in this example we want to connect all the buttons to a
single slot and parameterize the slot by the button that was
clicked.
Here's the definition of a simple custom widget that has a single
signal, \c clicked(), which is emitted with the text of the button
that was clicked:
\snippet qsignalmapper/buttonwidget.h 0
\snippet qsignalmapper/buttonwidget.h 1
The only function that we need to implement is the constructor:
\snippet qsignalmapper/buttonwidget.cpp OpenCtor
\snippet qsignalmapper/buttonwidget.cpp OldNotation
\snippet qsignalmapper/buttonwidget.cpp CloseBrackets
A list of texts is passed to the constructor. A signal mapper is
constructed and for each text in the list a QPushButton is
created. We connect each button's \c clicked() signal to the
signal mapper's map() slot, and create a mapping in the signal
mapper from each button to the button's text. Finally we connect
the signal mapper's mappedString() signal to the custom widget's
\c clicked() signal. When the user clicks a button, the custom
widget will emit a single \c clicked() signal whose argument is
the text of the button the user clicked.
This class was mostly useful before lambda functions could be used as
slots. The example above can be rewritten simpler without QSignalMapper
by connecting to a lambda function.
\snippet qsignalmapper/buttonwidget.cpp OpenCtor
\snippet qsignalmapper/buttonwidget.cpp ModernNotation
\snippet qsignalmapper/buttonwidget.cpp CloseBrackets
\sa QObject, QButtonGroup, QActionGroup
|
7387 |
- |
| qsignalmapper.h |
|
1109 |
- |
| qsingleshottimer.cpp |
Move the timer, and the dispatching and handling of the timer event, into
the same thread as where it will be handled, so that it fires reliably even
if the thread that set up the timer is busy.
|
3317 |
- |
| qsingleshottimer_p.h |
|
1973 |
- |
| qsocketnotifier.cpp |
!
\class QSocketNotifier
\inmodule QtCore
\brief The QSocketNotifier class provides support for monitoring
activity on a file descriptor.
\ingroup network
\ingroup io
The QSocketNotifier makes it possible to integrate Qt's event
loop with other event loops based on file descriptors. File
descriptor action is detected in Qt's main event
loop (QCoreApplication::exec()).
\target write notifiers
Once you have opened a device using a low-level (usually
platform-specific) API, you can create a socket notifier to
monitor the file descriptor. If the descriptor is passed to the
notifier's constructor, the socket notifier is enabled by default,
i.e. it emits the activated() signal whenever a socket event
corresponding to its type occurs. Connect the activated() signal
to the slot you want to be called when an event corresponding to
your socket notifier's type occurs.
You can create a socket notifier with no descriptor assigned. In
this case, you should call the setSocket() function after the
descriptor has been obtained.
There are three types of socket notifiers: read, write, and
exception. The type is described by the \l Type enum, and must be
specified when constructing the socket notifier. After
construction it can be determined using the type() function. Note
that if you need to monitor both reads and writes for the same
file descriptor, you must create two socket notifiers. Note also
that it is not possible to install two socket notifiers of the
same type (\l Read, \l Write, \l Exception) on the same socket.
The setEnabled() function allows you to disable as well as enable
the socket notifier. It is generally advisable to explicitly
enable or disable the socket notifier, especially for write
notifiers. A disabled notifier ignores socket events (the same
effect as not creating the socket notifier). Use the isEnabled()
function to determine the notifier's current status.
Finally, you can use the socket() function to retrieve the
socket identifier. Although the class is called QSocketNotifier,
it is normally used for other types of devices than sockets.
QTcpSocket and QUdpSocket provide notification through signals, so
there is normally no need to use a QSocketNotifier on them.
\sa QFile, QProcess, QTcpSocket, QUdpSocket
|
11114 |
- |
| qsocketnotifier.h |
|
3524 |
- |
| qsystemerror.cpp |
|
4812 |
- |
| qsystemerror_p.h |
|
1798 |
- |
| qt_attribution.json |
|
564 |
- |
| qtestsupport_core.cpp |
!
\variable QTest::defaultTryTimeout
\since 6.11
This global variable stores the default timeout used by the \c {QTRY_*}
functions and \l qWait.
The most typical use case for this variable is to modify the timeout
for an entire test:
\snippet code/src_qtestlib_qtestcase.cpp set defaultTryTimeout
However, you can also set it for a specific scope, using
\l QAtomicScopedValueRollback:
\snippet code/src_qtestlib_qtestcase.cpp rollback defaultTryTimeout
To access the value, call \c load():
\snippet code/src_qtestlib_qtestcase.cpp get defaultTryTimeout
It can also be set for a single run with the \c -trytimeout command-line
option.
|
5523 |
- |
| qtestsupport_core.h |
|
2895 |
- |
| qtimer.cpp |
!
\class QTimer
\inmodule QtCore
\brief The QTimer class provides repetitive and single-shot timers.
\ingroup events
The QTimer class provides a high-level programming interface for
timers. To use it, create a QTimer, connect its timeout() signal
to the appropriate slots, and call start(). From then on, it will
emit the timeout() signal at constant intervals.
Example for a one second (1000 millisecond) timer (from the
\l{widgets/analogclock}{Analog Clock} example):
\snippet ../widgets/widgets/analogclock/analogclock.cpp 4
\snippet ../widgets/widgets/analogclock/analogclock.cpp 5
\snippet ../widgets/widgets/analogclock/analogclock.cpp 6
From then on, the \c update() slot is called every second.
You can set a timer to time out only once by calling
setSingleShot(true). You can also use the static
QTimer::singleShot() function to call a slot after a specified
interval:
\snippet timers/timers.cpp 3
In multithreaded applications, you can use QTimer in any thread
that has an event loop. To start an event loop from a non-GUI
thread, use QThread::exec(). Qt uses the timer's
\l{QObject::thread()}{thread affinity} to determine which thread
will emit the \l{QTimer::}{timeout()} signal. Because of this, you
must start and stop the timer in its thread; it is not possible to
start a timer from another thread.
As a special case, a QTimer with a timeout of 0 will time out as soon as
possible, though the ordering between zero timers and other sources of
events is unspecified. Zero timers can be used to do some work while still
providing a snappy user interface:
\snippet timers/timers.cpp 4
\snippet timers/timers.cpp 5
\snippet timers/timers.cpp 6
From then on, \c processOneThing() will be called repeatedly. It
should be written in such a way that it always returns quickly
(typically after processing one data item) so that Qt can deliver
events to the user interface and stop the timer as soon as it has done all
its work. This is the traditional way of implementing heavy work
in GUI applications, but as multithreading is nowadays becoming available on
more and more platforms, we expect that zero-millisecond
QTimer objects will gradually be replaced by \l{QThread}s.
\section1 Accuracy and Timer Resolution
The accuracy of timers depends on the underlying operating system
and hardware. Most platforms support a resolution of 1 millisecond,
though the accuracy of the timer will not equal this resolution
in many real-world situations.
The accuracy also depends on the \l{Qt::TimerType}{timer type}. For
Qt::PreciseTimer, QTimer will try to keep the accuracy at 1 millisecond.
Precise timers will also never time out earlier than expected.
For Qt::CoarseTimer and Qt::VeryCoarseTimer types, QTimer may wake up
earlier than expected, within the margins for those types: 5% of the
interval for Qt::CoarseTimer and 500 ms for Qt::VeryCoarseTimer.
All timer types may time out later than expected if the system is busy or
unable to provide the requested accuracy. In such a case of timeout
overrun, Qt will emit timeout() only once, even if multiple timeouts have
expired, and then will resume the original interval.
\section1 Alternatives to QTimer
Qt 6.8 introduced QChronoTimer. The main difference between the two
classes, is that QChronoTimer supports a larger interval range and a
higher precision (\c std::chrono::nanoseconds). For QTimer the maximum
supported interval is ±24 days, whereas for QChronoTimer it is ±292
years (less chances of interger overflow with intervals longer than
\c std::numeric_limits<int>::max()). If you only need millisecond
resolution and ±24 days range, you can continue to use QTimer.
\include timers-common.qdocinc q-chrono-timer-alternatives
Some operating systems limit the number of timers that may be
used; Qt tries to work around these limitations.
\sa QBasicTimer, QTimerEvent, QObject::timerEvent(), Timers,
{Analog Clock}
|
23342 |
- |
| qtimer.h |
|
7688 |
- |
| qtimer_p.h |
|
2302 |
- |
| qtimerinfo_unix.cpp |
Internal functions for manipulating timer data structures. The
timerBitVec array is used for keeping track of timer identifiers.
|
14597 |
- |
| qtimerinfo_unix_p.h |
|
2787 |
- |
| qtmetamacros.h |
|
7715 |
- |
| qtmocconstants.h |
|
3143 |
- |
| qtmochelpers.h |
|
22027 |
- |
| qtranslator.cpp |
$ mcookie
3cb86418caef9c95cd211cbf60a1bddd
$
|
35157 |
- |
| qtranslator.h |
|
1641 |
- |
| qtranslator_p.h |
|
1025 |
- |
| qvariant.cpp |
|
101936 |
- |
| qvariant.h |
|
40009 |
- |
| qvariant_p.h |
|
3792 |
- |
| qvarianthash.h |
|
436 |
- |
| qvariantlist.h |
|
410 |
- |
| qvariantmap.h |
|
432 |
- |
| qwin32ticks_p.h |
|
884 |
- |
| qwineventnotifier.cpp |
!
\class QWinEventNotifier
\inmodule QtCore
\since 5.0
\brief The QWinEventNotifier class provides support for the Windows Wait functions.
The QWinEventNotifier class makes it possible to use the wait
functions on windows in a asynchronous manner. With this class,
you can register a HANDLE to an event and get notification when
that event becomes signalled. The state of the event is not modified
in the process so if it is a manual reset event you will need to
reset it after the notification.
Once you have created a event object using Windows API such as
CreateEvent() or OpenEvent(), you can create an event notifier to
monitor the event handle. If the event notifier is enabled, it will
emit the activated() signal whenever the corresponding event object
is signalled.
The setEnabled() function allows you to disable as well as enable the
event notifier. It is generally advisable to explicitly enable or
disable the event notifier. A disabled notifier does nothing when the
event object is signalled (the same effect as not creating the
event notifier). Use the isEnabled() function to determine the
notifier's current status.
Finally, you can use the setHandle() function to register a new event
object, and the handle() function to retrieve the event handle.
\b{Further information:}
Although the class is called QWinEventNotifier, it can be used for
certain other objects which are so-called synchronization
objects, such as Processes, Threads, Waitable timers.
\warning This class is only available on Windows.
|
8030 |
- |
| qwineventnotifier.h |
|
1009 |
- |
| qwineventnotifier_p.h |
|
1325 |
- |
| qwinregistry.cpp |
|
8171 |
- |
| qwinregistry_p.h |
|
3341 |
- |
| timers-common.qdocinc |
|
1551 |
- |